[whatwg] Attribute for holding private data for scripting

[Ian Hickson]

On Sun, 8 Apr 2007, Henri Sivonen wrote:
>
> At http://www.quirksmode.org/blog/archives/2007/04/html_5.html PPK 
> suggests having an attribute for storing private data for scripts.
> 
> Currently, one can invent an attribute and it will work for scripts. 
> However, it will look ugly for conformance checking. Since this is 
> essentially a conformance definition issue as browsers would not be 
> required to implement anything new (assuming a new reflecting attribute 
> on HTMLElement is deemed unnecessary), adding an attribute for 
> script-private data would be rather easy.
> 
> I think it would be worthwhile to add an attribute for script-private 
> data to common attributes, so that scripters who need one and want to be 
> conforming don't need to abuse e.g. title.

On Wed, 6 Dec 2006, Mike Schinkel wrote:
> 
> Here's at least one good use-case where expanding the number of 
> available attributes on HTML elements would be helped, as I request and 
> as you asked for use-case. Maybe even beyond the attribute names I 
> suggested in order to give some better semantics for alternate use cases 
> like Elias'.  Maybe also add "property" and "attribute" attributes to 
> all HTML elements.  Elias, do you have any suggestions?

The new custom-* attributes are an attempt to address these requests.


On Tue, 10 Apr 2007, Anne van Kesteren wrote:
> 
> 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...

On Tue, 10 Apr 2007, Sam Ruby wrote:
> 
> 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?

On Tue, 10 Apr 2007, Anne van Kesteren wrote:
> 
> Whether or not trailing slashes are allowed doesn't affect parsers in 
> existing browsers or any other parsers compatible with the web for that 
> matter. They merely affect conformance. This contrary to what you're 
> suggesting here (again).

The biggest problem for attributes with colons would be that scripts for 
legacy UAs (all of them today) would need to use getAttribute() with the 
colon (and the prefix would thus need to be hardcoded in the scripts, 
defeating the point of declaring namespaces), while scripts for new UAs 
would need to use getAttributeNS().

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'