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

[whatwg] Attribute for holding private data for scripting

From: Sam Ruby <rubys@intertwingly.net>
Date: Wed, 11 Apr 2007 09:04:45 -0400
Message-ID: <461CDCED.7060104@intertwingly.net>
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.

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

3) There already is spec text which indicates how html5 defined elements 
are to be handled with respect to getElementsByTagNameNS.  Perhaps it 
would again be a GOOD THING(TM) if this was also codified for 
attributes.  I believe that this is consistent with what Maciej is 
calling for.

4) One thing that needs to be mentioned is that compliance to the DOM 
standard varies widely.  In the long term, perhaps browser vendors could 
do a better job of this, and perhaps the HTML5 effort can help put a 
focus on this need.  In the short term, however, this can be dealt with 
via JavaScript.  Encapsulating and dealing with browser 
incompatibilities is an all too common use case for JavaScript.

5) I'm not sure where you draw the conclusion that prefix:name 
extensions would work differently than in XML.  While Python's minidom 
does not appear to produce the desired results when I call 
getElementById, it otherwise seems to handle the document identically to 
the way Firefox does:

http://intertwingly.net/stories/2007/04/10/test.py

- Sam Ruby
Received on Wednesday, 11 April 2007 06:04:45 UTC

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