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

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.

>>> 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.

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.

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.

>> 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.

>> 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.

>> 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.

>> 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.

>> 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. 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.

>> (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.

> 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.

Regards,
Maciej

Received on Monday, 17 September 2007 14:41:31 UTC