[whatwg] Attribute for holding private data for scripting

[Maciej Stachowiak]

On Apr 11, 2007, at 6:04 AM, Sam Ruby wrote:

> Anne van Kesteren wrote:
>> I think I'd rather have something simple such as prefix_name for  
>> extensions made by ECMAScript libraries, etc. (As opposed to an in  
>> scope xmlns:prefix="http://..." with prefix:name extensions which  
>> work differently in XML.) That would also work better for element  
>> extensions. Not any of this should be allowed, but there seems to  
>> be some desire to have an ability to introduce "conforming"  
>> extension elements / attributes which are implemented using a  
>> script library.
>
> This leads into lots of tangents.
>
> 1) re: "prefix_name" - how are prefixes registered?  Henri is free  
> to correct me if I am wrong, but I gathered that the requirement  
> was for a bit of decentralized extensibility, i.e., the notion that  
> anybody for any reason could defined an extension for holding  
> private data; and furthermore could do so without undo fear of  
> collision.

If these are meant for script-private data, I think the same ad-hoc  
collision avoidance that works for the script libraries themselves  
might work.

> 2) I assert that the existing DOM standard already defines a  
> mechanism for decentralized extensibility.  Most relevant to the  
> discussion at hand is the getAttributeNS method.  It may not be  
> defined as clearly as it could be, but there does seem to be some  
> clues which suggest what the original intent was, and the  
> beginnings of an agreement that if more browsers were to conform to  
> that intent, that would be a GOOD THING(TM).

getAttributeNS is definitely not a good choice for HTML, because no  
current HTML implementation will recognize namespace declarations in  
HTML and allow use of the relevant namespace URI with getAttributeNS.

Passing a QName to getAttribute might be workable but would require a  
change to at least some XHTML implementations so that scripts can  
work the same in HTML and XHTML. However, this ends up giving  
semantic weight to the namespace prefix, not the namespace URI, and  
so has no better collision avoidance in practice than an ad-hoc  
prefixing mechanism.

I will also add that the details XML namespaces can be quite  
difficult to understand, even for experts, so I would be hesitant to  
spread their use to HTML.

Regards,
Maciej