Re: [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.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Attribute for holding private data for scripting

[Michael A. Puls II]

On 4/12/07, Henri Sivonen <[EMAIL PROTECTED]> wrote:

On Apr 12, 2007, at 01:45, Michael A. Puls II wrote:

> On 4/11/07, Henri Sivonen <[EMAIL PROTECTED]> wrote:
>> I was thinking of
>> establishing an attribute such as "script-private" where authors
>> would be free to stick anything for retrieval by scripts.
>
> What would happen with ? Would the
> data be passed to the plug-in as a script-private param or would
> script-private be reserved; causing any plug-in using script-param not
> to get the data? (A prefix could possible avoid this.)

In old browsers at least, the script-private="something" would be
passed to the plug-in. Is it a problem?


Potentially. If the plug-in requires a script-private param for
something, that'd mean you might  not be able to use script-private on
the embed element for what you want. In that case, you would use a
different attribute name that doesn't conflict, which is O.K. because
you can use use some odd attribute on embed and still validate.

It's not a big concern, but IF there's a way to avoid that potential
conflict, it'd be cool.

--
Michael

Re: [whatwg] Attribute for holding private data for scripting

[Henri Sivonen]

On Apr 12, 2007, at 01:45, Michael A. Puls II wrote:


On 4/11/07, Henri Sivonen <[EMAIL PROTECTED]> wrote:

I was thinking of
establishing an attribute such as "script-private" where authors
would be free to stick anything for retrieval by scripts.


What would happen with ? Would the
data be passed to the plug-in as a script-private param or would
script-private be reserved; causing any plug-in using script-param not
to get the data? (A prefix could possible avoid this.)


In old browsers at least, the script-private="something" would be  
passed to the plug-in. Is it a problem?


--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

Re: [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

Re: [whatwg] Attribute for holding private data for scripting

[Michael A. Puls II]

On 4/11/07, Henri Sivonen <[EMAIL PROTECTED]> wrote:

I was thinking of
establishing an attribute such as "script-private" where authors
would be free to stick anything for retrieval by scripts.


What would happen with ? Would the
data be passed to the plug-in as a script-private param or would
script-private be reserved; causing any plug-in using script-param not
to get the data? (A prefix could possible avoid this.)

Or, would the attribute be global, but with exceptions?

If a global attribute is added, the name should be chosen carefully.

--
Michael

Re: [whatwg] Attribute for holding private data for scripting

[Henri Sivonen]

On Apr 11, 2007, at 16:04, Sam Ruby wrote:

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.


I did not have any prefixing mechanism in mind. I was thinking of  
establishing an attribute such as "script-private" where authors  
would be free to stick anything for retrieval by scripts. I was  
assuming that the usage of the attribute and the scripts running on  
the page would be tightly coupled. That is, generating the attributes  
and writing the script that consumes them would be under the control  
of the same developer/team.


--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

Re: [whatwg] Attribute for holding private data for scripting

[Kevin Marks]

On 4/11/07, Jon Barnett <[EMAIL PROTECTED]> wrote:



On 4/11/07, Kevin Marks <[EMAIL PROTECTED]> wrote:
> On 4/11/07, Jon Barnett <[EMAIL PROTECTED]> wrote:
> > > If you want structured data in this attribute, why not just use JSON?
> >
> > That's an idea that crossed my mind as well.  I dismissed it for a few
> > reasons:
> > - authors would have to entitize quotes and ampersands in their
attributes,
> > which they're not used to doing with JSON normally.
> > - evaluating it would mean:
> > var obj = eval( myelement.getAttribute("_myjson");
>
> How about defining an attribute that is the name of the js variable
> for use with that element? Then you can define the variable in a
>  tag, and use pure JSON cleanly.

I don't understand what you mean there.  It was said that we don't need to
add something new to the DOM.  If I understand, you're suggesting a single
attribute hypothetically called "params" spec'ed to be a JSON format:

with the DOM attribute named params that parses that attribute as JSON into
an object so that something like this happens in JavaScript:
...
mydiv.params.foo == 'bar'; // it is!

While that would be nice, it's not something browsers currently do, and the
goal is to spec something that today's browsers already handle and HTML5
validators will be happy with.  Granted, you can use eval() in Javascript to
get what you want in todays browsers, but is it best to actually spec it
that way?