Re: New elements vs. Trident

On Sep 17, 2007, at 12:55 AM, Robert Burns wrote:

>
> On Sep 17, 2007, at 2:31 AM, Robert Burns wrote:
>
>> This works for me in Safari 3.0 beta with uppercase: i.e.,
>> "test('document.getElementsByTagName("HTML:FIGURE").length');"
>>
>> Even though we're using namespaces, the HTML rules still apply to  
>> capitalization.
>
> I don't know what I was thinking there, it's got nothing to do with  
> case. I thought I had tested it with "html5:figure", but apparently   
> I hadn't.
>
> But yes, the tagname would be treated as html5:figure in pre-HTML5  
> UAs (except for IE). That to me is an excellent example of graceful  
> degradation.

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.

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


> Converting to an XML serialization would mean removing the htmll  
> prefix from elements and altering CSS and Javascript accordingly.  
> Again, I'm not suggesting this graceful degradation should outweigh  
> all other concerns, but like any design principle this example  
> illustrates how it might be used when it does outweigh other  
> principles.
>
> Also on the issue of scripting, I thought an important part of the  
> graceful degradation design principle was to avoid scripting (and  
> even CSS, though I think that's too restrictive). Once we add  
> scripting we can accomplish pretty much anything and call it  
> graceful degradation. In other words it empties the design principle  
> of all of its meaning. That may mean the only examples of graceful  
> degradation will have to draw on new features for HTML5 that do not  
> involve new element names (new attributes or other syntax changes  
> would be useful).

The idea is to use the weakest mechanism that can reasonably be  
applied. For scripting APIs, it's clearly impossible to do any  
degradation that doesn't involve script.

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.

You could argue about the rank ordering of the last two, but including  
a script once in a document seems to be less of a burden for authors  
than jumping through hoops every time they use the markup.

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

I don't see how this can be done. The following document would have  
different results in old and new UAs:

----
<b />X
----

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.

Regards,
Maciej

Received on Monday, 17 September 2007 09:29:50 UTC