[whatwg] Attribute for holding private data for scripting

[Sam Ruby]

Maciej Stachowiak wrote:
> 
> On Apr 10, 2007, at 8:12 PM, Sam Ruby wrote:
> 
>> Maciej Stachowiak wrote:
>>> On Apr 10, 2007, at 2:14 PM, Sam Ruby wrote:
>>>> Anne van Kesteren wrote:
>>>>> On Tue, 10 Apr 2007 22:41:12 +0200, Sam Ruby 
>>>>> <rubys at intertwingly.net> wrote:
>>>>>> How so?
>>>>> I missed the part where you wanted to change existing HTML parsers. 
>>>>> I thought Hixie pointed out earlier (by means of examples) why we 
>>>>> can't have namespace parsing in HTML. I suppose we can discuss it 
>>>>> again...
>>>>
>>>> It is a recurring pattern.  The first instance was "we can't allow 
>>>> trailing slashes in tags", which was followed up by a carefully 
>>>> crafted and narrow set of exceptions, which was met with "that 
>>>> works" and was adopted.
>>>>
>>>> So... while it is clearly true the full extent of XML namespames 
>>>> will never be supported in HTML5 (and for good reason), namespace 
>>>> qualified attributes allow extensibility in ways that prevent 
>>>> collisions.
>>>>
>>>> One of the first questions that would need to be answered: are there 
>>>> any existing documents on the web which would be broken if the name 
>>>> placed into the DOM for attributes with names containing a colon, 
>>>> with an apparent prefix, and one that matched an enclosing xmlns: 
>>>> declaration were to be changed?
>>> I think the problem here isn't compatibility with existing content, 
>>> but rather ability to use the feature in new web content while still 
>>> gracefully handling existing user agents. We wrote up some design 
>>> principles for the HTML WG based on the WHATWG's working assumptions 
>>> which might make this point more clear: 
>>> <http://esw.w3.org/topic/HTML/ProposedDesignPrinciples>. While "Don't 
>>> Break The Web" is a goal, so is "Degrade Gracefully".
>>> To give a specific example: say I make my own "mjsml" prefix with 
>>> namespace "http://example.org/mjsml". In HTML4 UAs, to look up an 
>>> "mjsml:extension" attribute using getAttribute("mjsml:extension"). In 
>>> HTML5 UAs, I'd have to use getAttributeNS("http://example.org/mjsml", 
>>> "extension"). And neither technique would work on both (at least as I 
>>> understand your proposal).
>>
>> Here's a page I constructed, and tested on Firefox:
>>
>> http://intertwingly.net/stories/2007/04/10/test.html
>>
>> This page is meant to be served as application/xhtml+xml.
>>
>> Can you test it and see what results you get?  Then lets discuss further.
> 
> In Safari 2.0.4: Processed as HTML, it says "data" and then "". 
> Processed as XHTML, it says "null" and then "data".
> In Opera 9.00: Processed as HTML, it says "data" and then "null". 
> Processed as XHTML, it says "null" and then "data".
> In Firefox 2.0.0.3: Processed as HTML, it says "data" and then "". 
> Processed as XHTML, it says "data" and then "data".
> In IE/Mac 5.2: Processed as HTML, it says "data" and the second alert 
> does not appear. Processed as XHTML, neither alert appears.
> 
> It looks like Firefox's XHTML implementation already has the 
> getAttribute extension I suggested of handling QNames.

Cool!

The first thing that is apparent to me is that, when processed as HTML, 
element.getAttribute('mjsml:extension') works everywhere.  So it is 
probably fair to say that allowing it does not run afoul of either the 
"Don't Break the Web" or "Degrade Gracefully" design principles.

Per HTML5 section 8.1.2.3, however, such an attribute name would not be 
considered conformant.  Despite this, later in document, in the 
description of "Attribute name state", no parse error is produced for 
this condition.  Nor does the current html5lib parser produce a parse 
error with this data.

I'd suggest that the first order of business is to reconcile 8.1.2.3 
with the description of "Attribute name state".  My suggestion is that 
"Anything else" emits a parse error (but nevertheless continues 
on/recovers), and that a rule for handling latin small letter a through 
z, hyphen-minus, and colon be added.

> By the way, the fact that no two of the browsers I tested treat this the 
> same is a pretty clear indicator that DOM Core needs the HTML5 treatment.

+1.  But this begs a larger issue.  Much of the differences that you 
found were in how XHTML was handled, and the WhatWG document currently 
states:

     The rules for parsing XML documents (and thus XHTML documents)
     into DOM trees are covered by the XML and Namespaces in XML
     specifications, and are out of scope of this specification.
     [XML] [XMLNS]

> Regards,
> Maciej

- Sam Ruby