Re: New elements vs. Trident

Hi Maciej,

On Sep 17, 2007, at 5:36 AM, Maciej Stachowiak wrote:

>
>
> On Sep 17, 2007, at 2:46 AM, Robert Burns wrote:
>
>> Hi Maciej,
>>
>> On Sep 17, 2007, at 4:29 AM, Maciej Stachowiak wrote:
>>
>>>
>>> That getElementsByTagName statement does *not* however work in  
>>> IE. The point is that this approach leads to scripting behavior  
>>> that is not interoperable.
>>>
>>> That makes it a very poor example of graceful degradation.  
>>> Authors would be required to write something other than the most  
>>> natural markup, and then the result doesn't actually work in most  
>>> current browsers.
>>
>> I think for new elements then we should just drop it as an example  
>> of graceful degradation.
>
> 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.

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

>> I think its less of a problem to ask authors who are already  
>> scripting to fork their scripts for different UAs to make use of  
>> HTML5. I would not call that an interoperable solution, simply a  
>> solution that has interoperability issues to be dealt with.
>
> 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.

>>>> That would mean that HTML5 would define two names for the new  
>>>> figure element: "figure" and "html5:figure" and also provide a  
>>>> canonical prefix for use in text/html serializations. Like  
>>>> "xmlns" and "xml", "html5" (or "html") would always point to the  
>>>> same namespace (even without a binding/declaration).
>>>
>>> Having two different names for every new element seems like a  
>>> huge amount of complexity. And it still doesn't fix the scripting  
>>> interoperability issue in current browsers. It still seems like  
>>> script-based fixup in IE is the best known approach to handling  
>>> new elements in existing browsers.
>>
>> I agree, but scripting is not a graceful degradation option for  
>> new elements. I'm not saying we can't add elements that don't  
>> degrade gracefully, but saying they do because scripting makes it  
>> work is a perversion of graceful degradation. Of course scripting  
>> can make it work. We might as well not even have the design  
>> principle if anything involving scripting to handle newly  
>> introduced elements is an example of graceful degradation.
>
> 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).

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

>>> I personally think that an extensibility mechanism for the HTML  
>>> serialization that aligns with XML namespaces is a worthy goal.  
>>> But I don't think it's a solution for the graceful degradation of  
>>> new elements. However, if you come up with an approach that works  
>>> interoperably in all current browsers and can be expected
>>
>> It would help for you to outline what you think the  
>> interoperability issues are. It does nothing to help the WG to  
>> just use innuendo.
>
> 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.

>>>> For new elements, attributes and content models, I would give  
>>>> approximately the following rank ordering of graceful  
>>>> degradation techniques, from most preferred to least preferred:
>>>
>>> - Nothing special needed. (<dialog> element, mostly).
>>> - Can be done with style rules only. (irrelevant attribute)
>>> - Needs scripting in a small subset of UAs.
>>> - Needs scripting in many or most UAs.
>>> - Needs convolutions in the markup every time the new construct  
>>> is used.
>>
>> For new element, once you've hit the third item, you're past  
>> graceful degradation.
>
> 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.

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

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

>>> If minimized element syntax was made to work for non-void  
>>> elements, there's almost no situation where it could safely be  
>>> used without creating differences in document processing in  
>>> current UAs. Existing content has nothing to do with it, since  
>>> the "Degrade Gracefully" principle is about new content working  
>>> in existing UAs, not vice versa.
>>
>> Agreed. Forget I  mentioned it in that context.

Take care,
Rob

Received on Monday, 17 September 2007 13:15:24 UTC