W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2007

[whatwg] Attribute for holding private data for scripting

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 10 Apr 2007 23:08:56 -0700
Message-ID: <1E307031-5107-4AE6-9C13-A4E293A25866@apple.com>

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.

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.

Regards,
Maciej
Received on Tuesday, 10 April 2007 23:08:56 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:54 UTC