Re: Responses to assorted ponts (was Re: New elements vs. Trident)

Hi Maciej,

On Sep 17, 2007, at 9:41 AM, Maciej Stachowiak wrote:

>
>
> Retitling thread, since this no longer seems to have much to do  
> with the original topic of this thread.
>
> On Sep 17, 2007, at 6:15 AM, Robert Burns wrote:
>
>>
>> On Sep 17, 2007, at 5:36 AM, Maciej Stachowiak wrote:
>>
>>> It's not cited as an example in the Design Principles. I started  
>>> this email thread and the similar ones about unknown block-level  
>>> elements in Firefox and unknown elements generally in IE because  
>>> while looking for examples I realized the story for many of the  
>>> new elements is somewhat problematic.
>>
>> To say the least. My point is that the story is so problematic  
>> that including any new element as part of a degrades gracefully  
>> example stretches the meaning of degrades gracefully so far that  
>> it no longer has any meaning. I would be very opposed to such  
>> examples.
>
> Your opposition is noted. However, I do not think the majority of  
> the group would agree that the Design Principles should rule out  
> adding new elements. That seems like an unreasonable constraint.

I don't understand why you feel the need to spin everything when you  
post to the list. We're all here volunteering our time to discuss  
HTML. There's no need to score points. As you know, I'm not  
suggesting and never have suggested that the design principles should  
rule out new elements. What I suggested was that searching for a good  
example of graceful degradation in the new elements is not going to  
work. To  select one of these examples basically empties the graceful  
degradation principle of all of its meaning. For the design  
principles document it would be better to select an example that  
illustrated graceful degradation.

>>>> Asking authors who may have no need to use scripting to use  
>>>> scripting to implement HTML5 will be a recipe for disaster.
>>>
>>> It's quite likely that reusable compatibility scripts for IE (and  
>>> other browsers if necessary) will be created, as well as  
>>> compatibility stylesheets.
>>
>> What's the difference between creating reusable compatibility  
>> scripts for IE or creating reusable      compatibility scripts to  
>> work around interoperability issues? They both seem equally  
>> convoluted enough to be excluded as examples of degrades  
>> gracefully. The difference is that the interoperability issues  
>> only hit authors that need to do specific DOM manipulation of  
>> those elements which much of what I see in HTML5 is meant to avoid  
>> the need for that.
>
> It's pretty easy to write a script that reparents the siblings of a  
> <figure> void element inside it up until the matching </figure>  
> element. It has been done in the past for the <abbr> element so we  
> know it is doable.

Try using that fix in a browser without javascript though.

> It's pretty hard to write a single script that will treat elements  
> named "html:figure" as if they were named "figure" under all  
> circumstances in non-IE browsers. I would venture to say it is  
> impossible. For example, I can't think of a way to make tagName  
> return "FIGURE" in Safari for all "html:figure" elements.

If its a canonical prefix its very simple to transform a string  
tagname into another string without the "html:" prefix. It is not  
impossible.

> It's also  possible to do different script-based fallback for non- 
> IE user agents, by replacing all "html:figure" elements in the DOM  
> with "figure" elements. However, there are many existing user  
> agents and other tools that would support "figure" just fine, but  
> which don't do scripting at all. Whereas IE is the only user agent  
> I know of that can't properly handle parsing of unknown elements.  
> So it makes more sense to do the compatibility hack for the one  
> exception rather than for the common case.

Again, you're just spinning this. IE is a browser many authors need  
to target. You can count up the number of UAs, but it still doesn't  
change the fact that IE is the majority of all UAs most users have in  
most authoring situations.

>>> The disadvantage to such an approach is that it isn't a "fire and  
>>> forget" hack that you apply once per document. You'd have to be  
>>> aware of it in any script you write. And nearly all existing  
>>> JavaScript libraries would have to be modified, too. Differing  
>>> behavior between browsers is a much more serious problem than one- 
>>> time script inclusion.
>>
>> Or you would solve once in your library and call a function in the  
>> library.
>
> as stated above, I think a complete solution for this is impossible  
> and even a partial solution would be quite complicated.

It's not impossible. It's not even quite complicated. They both have  
complications.

>>> 1) It's not the case that everything can be implemented purely  
>>> with script.
>>
>> I've yet to see an example of something proposed that couldn't be  
>> implemented with scripting today (with perhaps the exception of  
>> the networking chapter that hasn't been discussed at all yet).
>
> <canvas> is one obvious example. <video> would be another.

What about video could not be implemented with scripting. As for  
<canvas>, we've discussed SVG already, and though that discussion  
revealed some differences between SVG and canvas, its hard to imagine  
how a site using SVG and scripting today couldn't accomplish much, if  
not all, of what canvas offers.

>>> 2) Having to include a single script to work in IE is annoying,  
>>> but it seems like the best option currently available for adding  
>>> new elements. It's certainly not as bad as having to include a  
>>> script for any UA whatsoever, since that would break non- 
>>> scripting UAs.
>>
>> The point is that its enough of an effort and enough of annoyance  
>> that it makes a horrible example of degrades gracefully.
>
> No one's using it as an example. That being said, it's been done  
> before for other elements and has proven not to be a big problem.

I thought the main thrust of this thread was in finding examples of  
graceful degradation for the design principles document.

>>> The interoperability issues all stem from the fact that the tag  
>>> name would be "figure" in some browsers and "html:figure" in  
>>> others. Besides the already cited getElementsByTagName example,  
>>> it would also break existing JS libraries for querying by CSS  
>>> selector.
>>
>> Yes there are many issues. That doesn't make it an unworkable  
>> solution. We also need to weigh how many sites will be hit by each  
>> issue. If there is only a very small fraction of sites that would  
>> ever face problems with this interoperability issue versus the  
>> number of sites using these elements that would need to target IE,  
>> then that's an important issue to consider. You seem to be making  
>> this into an issue that well if it works in Safari and Opera, then  
>> we'll work out the kinks for those few other minor browsers.
>
> Using new elements with their plain names is an approach that works  
> with no fixup needed in Safari, Opera, Firefox, Konqueror, or one  
> of the many browsers and other applications sharing their engines.  
> Simple script-based fixup makes it also work in IE and browsers  
> that share its engine. I'm looking for the simplest solution to  
> serving content with new elements to the current generation of  
> browsers and other user agents. I haven't heard a simpler one so far.

Again, you're counting browsers or rendering engines, but that's only  
part of the issue. The other part being swept under the rug is that  
IEs by far the majority browser that's going to effect many users and  
authors.

>>> You are welcome to your opinion. I'm not sure others would draw  
>>> the same arbitrary line. I'd also add that you're proposing to  
>>> replace a case of the third item with the fifth.
>>
>> No, I'm not. There's nothing convoluted in the markup I proposed.
>
> Writing <html:figure> ... </html:figure> is not a natural way to  
> write HTML. It's not even a natural way to write XHTML, where a  
> default namespace declaration is most commonly used.

I didn't know writing HTML was a natural thing. Adding a four-letter  
prefix does not make the markup convoluted.  Adding a xmlns binding  
is also not convoluted. We might as well just say anything that's not  
plain text is convoluted.

> It requires the author to go out of their way every time they use a  
> new element in the markup. That's the kind of convolution I mean. I  
> think limited script-based fixup is preferrable to writing markup  
> in an unnatural way.

Script-based fixup might be preferable. It's just not a good example  
of graceful degradation.

>
>>> (BTW I forgot to add a final item which is "fallback to  
>>> completely separate alternate markup").
>>
>> How can an element have fallback content if its a sibling void  
>> element next to the fallback content?
>
> The sibling void elements can safely be ignored in most such cases.  
> If you nest <object> inside <video>, it doesn't matter much if the  
> fallback in older browsers puts it inside or next to the video  
> element.


>
>>
>>
>>>>> I don't see how this can be done. The following document would  
>>>>> have different results in old and new UAs:
>>>>>
>>>>> ----
>>>>> <b />X
>>>>> ----
>>>>
>>>> Do you have some citations for that document. In other words  
>>>> does a document like that exist in reality? How many document  
>>>> exist like that in reality? How many would break severely if the  
>>>> self-closing tag interpretation was implied?
>>>
>>> Your questions are not relevant to whether the construct degrades  
>>> gracefully. See my quoted comments below which explain why and  
>>> which you agreed with.
>>
>> When did this become the HTML5 degrades gracefully WG?
>
> You're the one who cited this as an example of graceful  
> degradation. Quoting from your earlier message:
>
> 'Just to throw out an example: what would happen if we added the  
> self-closing syntax to text/html and actually made it meaningful.  
> Presumably this would degrade gracefully since existing content  
> would not end their opening element tags with a "/>".  Just a  
> thought for another example.'
>
> If you retract that claim then I'm not sure what your point is.

My point is that discussing the issue of changing parsing for HTML5  
should not be off-limits for this WG. You dismissed my arguments  
about this because it wasn't about degrading gracefully. Its fine if  
you don't want to respond to issues that aren't about degrades  
gracefully, but don't dismiss them because they're off -limits.

>> This issue is very relevant since the current draft proposes to  
>> continue the insanity with unknown elements and if instead we  
>> change to allowing non-void elements in head and body and even  
>> support  like self-closing elements (even if just for everything  
>> but the current elements) and that already was supported now (or  
>> for those writing HTML6) the degrades gracefully principle would  
>> be more attainable.
>
> I'd be happy to hear a complete proposal for how to handle unknown  
> elements in <head>. I'm not sure what you are proposing.

I'm suggesting that the way Safari (and I think Opera) handle unknown  
elements in the body should be the way all HTML5 UAs handle unknown  
elements in both the body and the head.  Could you say what problems  
you think would arise from this approach. Are there sites that put  
unknown elements in the head and count on them being moved to the  
body? Is that something HTML5 needs to cater to?

Take care,
Rob

Received on Monday, 17 September 2007 15:11:29 UTC