Re: New elements vs. Trident

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.

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

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


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

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.

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

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

(BTW I forgot to add a final item which is "fallback to completely  
separate alternate markup").

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

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

Regards,
Maciej

Received on Monday, 17 September 2007 10:36:19 UTC