Re: New elements vs. Trident

Hi Maciej,

On Sep 17, 2007, at 4:29 AM, Maciej Stachowiak wrote:

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

I think for new elements then we should just drop it as an example of  
graceful degradation. Asking authors who may have no need to use  
scripting to use scripting to implement HTML5 will be a recipe for  
disaster. 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.

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

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

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

Well that's for scripting. I don't think that standard should be  
applied to new elements.

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

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?

> 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 09:46:56 UTC