Re: [whatwg] Attribute for holding private data for scripting
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
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 embed script-private=something? 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
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. Firefox is AFAICT the one following spec here. The spec says that getAttribute in a namespaced document should return the node with the given qname. Though I thought we returned null when getAttributeNS failed, but it appears we only do that for getAttribute. / Jonas
Re: [whatwg] Attribute for holding private data for scripting
On Apr 9, 2007, at 10:27 AM, Maciej Stachowiak wrote: On Apr 8, 2007, at 11:12 AM, 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. The class attribute can already be used for script-private data. I think the time script authors go for made-up attributes is when they need a set of key-value pairs. Class is not so great for that, but I'm not sure any new attribute would be either, unless it provided some sort of built-in key-value parsing. If you want structured data in this attribute, why not just use JSON? -ryan
Re: [whatwg] Attribute for holding private data for scripting
On Apr 10, 2007, at 11:42 PM, Jonas Sicking wrote: 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. Firefox is AFAICT the one following spec here. The spec says that getAttribute in a namespaced document should return the node with the given qname. I don't think the spec is clear on this. http://www.w3.org/TR/DOM-Level-3-Core/core.html The spec for getAttribute itself just says getAttribute - retrieves an attribute value by name. It doesn't even specify that the name parameter should be the Attr.nodeName, like getAttributeNode does. Other parts of the spec do seem to imply this should be the qname, not the local name, so probably better to do it that way. Thanks for pointing this out. Regards, Maciej
Re: [whatwg] Attribute for holding private data for scripting
Maciej Stachowiak wrote:
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
[EMAIL PROTECTED] 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.
Cool!
The first thing that is apparent to me is that, when processed as HTML,
element.getAttribute('mjsml:extension') works everywhere. So it is
probably fair to say that allowing it does not run afoul of either the
Don't Break the Web or Degrade Gracefully design principles.
Per HTML5 section 8.1.2.3, however, such an attribute name would not be
considered conformant. Despite this, later in document, in the
description of Attribute name state, no parse error is produced for
this condition. Nor does the current html5lib parser produce a parse
error with this data.
I'd suggest that the first order of business is to reconcile 8.1.2.3
with the description of Attribute name state. My suggestion is that
Anything else emits a parse error (but nevertheless continues
on/recovers), and that a rule for handling latin small letter a through
z, hyphen-minus, and colon be added.
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.
+1. But this begs a larger issue. Much of the differences that you
found were in how XHTML was handled, and the WhatWG document currently
states:
The rules for parsing XML documents (and thus XHTML documents)
into DOM trees are covered by the XML and Namespaces in XML
specifications, and are out of scope of this specification.
[XML] [XMLNS]
Regards,
Maciej
- Sam Ruby
Re: [whatwg] Attribute for holding private data for scripting
On Wed, 11 Apr 2007 13:40:39 +0200, Sam Ruby [EMAIL PROTECTED] wrote: Per HTML5 section 8.1.2.3, however, such an attribute name would not be considered conformant. Yes, only attributes defined in the specification are conformant. Despite this, later in document, in the description of Attribute name state, no parse error is produced for this condition. Nor does the current html5lib parser produce a parse error with this data. Correct. We're not doing validation. Just tokenizing and building a tree. [...] -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Attribute for holding private data for scripting
On Wed, 11 Apr 2007 13:40:39 +0200, Sam Ruby [EMAIL PROTECTED] wrote: 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). By the way, the reason this is not consistent with XML is that it would be just as ok to use a different prefix. By basing this on the prefix (which is needed if you want this to be compatible with HTML, etc.) you're moving the semantics from the namespace to the prefix, which seems like a bad idea. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Attribute for holding private data for scripting
Anne van Kesteren wrote: On Wed, 11 Apr 2007 13:40:39 +0200, Sam Ruby [EMAIL PROTECTED] wrote: Per HTML5 section 8.1.2.3, however, such an attribute name would not be considered conformant. Yes, only attributes defined in the specification are conformant. I was specifically referring to section 8.1.2.3. Let me call your attention to the following text: Attribute names use characters in the range U+0061 LATIN SMALL LETTER A .. U+007A LATIN SMALL LETTER Z, or, in uppercase, U+0041 LATIN CAPITAL LETTER A .. U+005A LATIN CAPITAL LETTER Z, and U+002D HYPHEN-MINUS (-). Despite this, later in document, in the description of Attribute name state, no parse error is produced for this condition. Nor does the current html5lib parser produce a parse error with this data. Correct. We're not doing validation. Just tokenizing and building a tree. In the process, parse errors are generally emitted in cases where individual characters are encountered which do not match the lexical grammar rules. Just not in this case. - Sam Ruby
Re: [whatwg] Attribute for holding private data for scripting
On Wed, 11 Apr 2007 13:53:21 +0200, Sam Ruby [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: On Wed, 11 Apr 2007 13:40:39 +0200, Sam Ruby [EMAIL PROTECTED] wrote: Per HTML5 section 8.1.2.3, however, such an attribute name would not be considered conformant. Yes, only attributes defined in the specification are conformant. I was specifically referring to section 8.1.2.3. Let me call your attention to the following text: Attribute names use characters in the range U+0061 LATIN SMALL LETTER A .. U+007A LATIN SMALL LETTER Z, or, in uppercase, U+0041 LATIN CAPITAL LETTER A .. U+005A LATIN CAPITAL LETTER Z, and U+002D HYPHEN-MINUS (-). I think you should read the whole section. Allowing colons there wouldn't make a difference. Despite this, later in document, in the description of Attribute name state, no parse error is produced for this condition. Nor does the current html5lib parser produce a parse error with this data. Correct. We're not doing validation. Just tokenizing and building a tree. In the process, parse errors are generally emitted in cases where individual characters are encountered which do not match the lexical grammar rules. Just not in this case. The above are not the grammar rules. They are (normative) guidelines for people writing or generating HTML. As far as I can tell there's no normative grammar. Just a way to construct a conforming string and a way to interpret a random string. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Attribute for holding private data for scripting
Anne van Kesteren wrote: On Wed, 11 Apr 2007 13:40:39 +0200, Sam Ruby [EMAIL PROTECTED] wrote: 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). By the way, the reason this is not consistent with XML is that it would be just as ok to use a different prefix. By basing this on the prefix (which is needed if you want this to be compatible with HTML, etc.) you're moving the semantics from the namespace to the prefix, which seems like a bad idea. For starters, you are misattributing the quote above. I did not write those words. As to your point -- and you so colorfully put it on your weblog -- Standards Suck. And in this case, I will argue that the current HTML5 spec leads one to the conclusion that getAttribute(mjsml:extension) will work, at least for the HTML serialization of HTML5. I did not write that quote. I did not write -- or even contribute to -- that portion of the spec. - Sam Ruby
Re: [whatwg] Attribute for holding private data for scripting
Anne van Kesteren wrote: On Wed, 11 Apr 2007 13:53:21 +0200, Sam Ruby [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: On Wed, 11 Apr 2007 13:40:39 +0200, Sam Ruby [EMAIL PROTECTED] wrote: Per HTML5 section 8.1.2.3, however, such an attribute name would not be considered conformant. Yes, only attributes defined in the specification are conformant. I was specifically referring to section 8.1.2.3. Let me call your attention to the following text: Attribute names use characters in the range U+0061 LATIN SMALL LETTER A .. U+007A LATIN SMALL LETTER Z, or, in uppercase, U+0041 LATIN CAPITAL LETTER A .. U+005A LATIN CAPITAL LETTER Z, and U+002D HYPHEN-MINUS (-). I think you should read the whole section. Allowing colons there wouldn't make a difference. The document is a draft. The subject line of this thread suggests that the WG is entertaining the notion of allowing at least one attribute which is not currently defined in the specification. This suggests that the draft may need to change. Drafts are like that. Like others, I'm not convinced that the way forward is to allow a new attribute which has a micro-grammar for parsing what would be represented in the DOM essentially as a character blob. Despite this, later in document, in the description of Attribute name state, no parse error is produced for this condition. Nor does the current html5lib parser produce a parse error with this data. Correct. We're not doing validation. Just tokenizing and building a tree. In the process, parse errors are generally emitted in cases where individual characters are encountered which do not match the lexical grammar rules. Just not in this case. The above are not the grammar rules. They are (normative) guidelines for people writing or generating HTML. As far as I can tell there's no normative grammar. Just a way to construct a conforming string and a way to interpret a random string. --Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Attribute for holding private data for scripting
On Wed, 11 Apr 2007 14:15:15 +0200, Sam Ruby [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: On Wed, 11 Apr 2007 13:40:39 +0200, Sam Ruby [EMAIL PROTECTED] wrote: 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). By the way, the reason this is not consistent with XML is that it would be just as ok to use a different prefix. By basing this on the prefix (which is needed if you want this to be compatible with HTML, etc.) you're moving the semantics from the namespace to the prefix, which seems like a bad idea. For starters, you are misattributing the quote above. I did not write those words. I knew Maciej wrote it but I think your name is up there as I wrote this in a reply to your e-mail which quoted Maciej or something... Anyway, that's besides the point here. (The amount of should also indicate it's not you who wrote it, methinks.) As to your point -- and you so colorfully put it on your weblog -- Standards Suck. And in this case, I will argue that the current HTML5 spec leads one to the conclusion that getAttribute(mjsml:extension) will work, at least for the HTML serialization of HTML5. I did not write that quote. I did not write -- or even contribute to -- that portion of the spec. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Attribute for holding private data for scripting
On Wed, 11 Apr 2007 14:15:19 +0200, Sam Ruby [EMAIL PROTECTED] wrote: [...] Like others, I'm not convinced that the way forward is to allow a new attribute which has a micro-grammar for parsing what would be represented in the DOM essentially as a character blob. That's fine. I'm merely pointing out that your suggested changes don't have the impact you desire. It may be better to just state what you want (which by now is probably pretty clear) and leave the editorial work to the editor (no offense). Having said that, 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. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Attribute for holding private data for scripting
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); which I don't like because I prefer to avoid eval at all costs. - it further marries HTML with JavaScript, which is something I'd like to see evolve and change in the future - something else widely supported, like client-side Python is a personal dream. Also, whatever attribute also needs to have meaning (read: be easy to get to in the DOM) when your document is processed by something other than a browser, such as PHP or Java. You, yourself, could still format your custom data that way, but I don't think it's a great idea to spec it that way. And I guess it's already been said that changing something in the DOM a good idea for this. We just want to allow authors to continue to do something authors already do without making validators complain. The idea of allowing just any attribute that starts with _ (or x_) has the best benefit - authors already do it, it's just a matter of making validators not complain.
Re: [whatwg] Attribute for holding private data for scripting
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
Re: [whatwg] Attribute for holding private data for scripting
Kristof Zelechovski wrote: (as client side Lisp is my personal dream) http://www.cs.stevens.edu/~dlong/software/kamen/index.php -dean
Re: [whatwg] Attribute for holding private data for scripting
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 script tag, and use pure JSON cleanly. Kristof, JSON is in fact pretty much valid Python syntax too. It is a Javascript subset for decalarative structures designed to interoperate with many languages.
Re: [whatwg] Attribute for holding private data for scripting
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
script 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:
div params={foo: 'bar', bish: quot;bashquot;}/div
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?
No, what I'm suggesting is that you have, say, a 'localdata' attribute
that names the associated variable:
scriptmyparams={foo:bar,bish:bash};/script
div class=mydiv localdata=myparams
mydiv.localdata.foo ==bar; // it is
I think making this work in current browsers would be doable by having
a script that creates the DOM elements by looking for the 'localdata'
parameters.
Re: [whatwg] Attribute for holding private data for scripting
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
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
On Mon, 09 Apr 2007 21:37:31 +0200, Jon Barnett [EMAIL PROTECTED]
wrote:
I can think of two possibilities.
One would be to allow the param element as a child of any element (or any
block level element?)
http://www.whatwg.org/specs/web-apps/current-work/#param
And then make an attribute of HTMLElement called params
readonly attribute HTMLCollection params;
Where params is a collection of HTMLParamElements that are children (not
further descendants) of that element.
That would make this:
div id=fooparam name=answer value=42Some more content/div
easy to access via JavaScript:
var foo = document.getElementById(foo);
if(foo.params['answer'] == 42) {
// it is!!
}
The only other possibility I can think of would be an HTML attribute
called
params that would be a list of tokenized name value pairs, but that
sounds
even hairier to implement.
Or allow any attribute that starts with x_ or something (to prevent
clashing with future revisions of HTML), as private attributes.
div id=foo x_answer=42Some more content/div
var foo = document.getElementById(foo);
if(foo.getAttribute(x_answer) == 42) {
// it is!!
}
UAs wouldn't have to implement anything new using this proposal. The
.param attribute you proposed doesn't work in today's browsers and so
param/param= would be a lot harder to work with in practice.
(I don't feel strongly either way about allowing private attributes,
although I have to admit I have abused class/title for scripting purposes
in the past where private attributes would have been more elegant and
possibly more performant, FWIW.)
--
Simon Pieters
Re: [whatwg] Attribute for holding private data for scripting
On 4/10/07, Simon Pieters [EMAIL PROTECTED] wrote: Or allow any attribute that starts with x_ or something (to prevent clashing with future revisions of HTML), as private attributes. Instead of starts with x_, how about contains a colon? A conformance checker could ensure that there is a corresponding xmlns declaration that applies here, and possibly even do additional verification if it recognizes the namespace. An HTML5 parser would, of course, recover from references to undeclared namespaces, placing the entire attribute name (including the prefix and the colon) into the DOM in such situations.
Re: [whatwg] Attribute for holding private data for scripting
On Tue, 10 Apr 2007 20:21:27 +0200, Sam Ruby [EMAIL PROTECTED] wrote: Or allow any attribute that starts with x_ or something (to prevent clashing with future revisions of HTML), as private attributes. Instead of starts with x_, how about contains a colon? A conformance checker could ensure that there is a corresponding xmlns declaration that applies here, and possibly even do additional verification if it recognizes the namespace. An HTML5 parser would, of course, recover from references to undeclared namespaces, placing the entire attribute name (including the prefix and the colon) into the DOM in such situations. * That would be confusing to people familiar with XML; * It would hinder the ability to exchange scripts between HTML and XML; * It would create more differences between XML and HTML where less seems to be desired (trailing slash allowed, etc.). -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Attribute for holding private data for scripting
On 4/10/07, Sam Ruby [EMAIL PROTECTED] wrote: Instead of starts with x_, how about contains a colon? A conformance checker could ensure that there is a corresponding xmlns declaration that applies here, and possibly even do additional verification if it recognizes the namespace. An HTML5 parser would, of course, recover from references to undeclared namespaces, placing the entire attribute name (including the prefix and the colon) into the DOM in such situations. I like the idea of prefixed attributes for that purpose. This shouldn't be an issue for text/html parsing. http://www.whatwg.org/specs/web-apps/current-work/#attributes0 That section doesn't explicitly allow colons in attribute names. A provision would need to be made for that, but only for text/html parsing As for text/xml parsing, those prefixed attributes would need to belong to a namespace. Should there be a specific URI designated for these attributes - I suspect that allowing the author to make up his own namespace URNs whimsically is bad. Is there already a namespace URI for this purpose (e.g. urn:private)? Possibly causes more problems than it solves. What about any attribute that starts with _ as opposed to x_? I'm messing with designMode in Firefox right now, and it appears Firefox adds an attribute called _moz_dirty to certain elements for internal scripting purposes. Are there cases where other browsers do something similar? Is there already a convention in some applications similar to the -xxx- convension in CSS for this purpose?
Re: [whatwg] Attribute for holding private data for scripting
On 4/10/07, Anne van Kesteren [EMAIL PROTECTED] wrote: On Tue, 10 Apr 2007 20:21:27 +0200, Sam Ruby [EMAIL PROTECTED] wrote: Or allow any attribute that starts with x_ or something (to prevent clashing with future revisions of HTML), as private attributes. Instead of starts with x_, how about contains a colon? A conformance checker could ensure that there is a corresponding xmlns declaration that applies here, and possibly even do additional verification if it recognizes the namespace. An HTML5 parser would, of course, recover from references to undeclared namespaces, placing the entire attribute name (including the prefix and the colon) into the DOM in such situations. * That would be confusing to people familiar with XML; * It would hinder the ability to exchange scripts between HTML and XML; * It would create more differences between XML and HTML where less seems to be desired (trailing slash allowed, etc.). How so? The idea is to place these attributes into the DOM the same way as they would be when parsed with an xml parser, for the cases where the data happens to be namespace valid. And to do what you would expect in the cases where, for example, attribute values aren't quoted. And to follow the html5 credo of recover at all cost in cases where what the user entered doesn't conform. This would of course need to be spec'ed, AND compared against common usage, AND prototyped; I simply ask that it not be rejected out of hand. - Sam Ruby
Re: [whatwg] Attribute for holding private data for scripting
On Tue, 10 Apr 2007 22:41:12 +0200, Sam Ruby [EMAIL PROTECTED] 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... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Attribute for holding private data for scripting
Anne van Kesteren wrote: On Tue, 10 Apr 2007 22:41:12 +0200, Sam Ruby [EMAIL PROTECTED] 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? - Sam Ruby
Re: [whatwg] Attribute for holding private data for scripting
On Tue, 10 Apr 2007 23:14:16 +0200, Sam Ruby [EMAIL PROTECTED] 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... 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. 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). 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? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Attribute for holding private data for scripting
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 [EMAIL PROTECTED] 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). Now, we could extend getAttribute in HTML to do namespace lookup when given a name containing a colon and when namespace declarations are present, but then we would want to do it in XHTML as well. And using the short getAttribute call instead of a longer getAttributeNS with a namespace prefix might be unacceptable to XML fans. Regards, Maciej
Re: [whatwg] Attribute for holding private data for scripting
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 [EMAIL PROTECTED] 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. BTW, I intentionally don't have a completed proposal at this point. We need to explore what works and what doesn't work further. Now, we could extend getAttribute in HTML to do namespace lookup when given a name containing a colon and when namespace declarations are present, but then we would want to do it in XHTML as well. And using the short getAttribute call instead of a longer getAttributeNS with a namespace prefix might be unacceptable to XML fans. Regards, Maciej - Sam Ruby
Re: [whatwg] Attribute for holding private data for scripting
On Apr 8, 2007, at 11:12 AM, 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. The class attribute can already be used for script-private data. I think the time script authors go for made-up attributes is when they need a set of key-value pairs. Class is not so great for that, but I'm not sure any new attribute would be either, unless it provided some sort of built-in key-value parsing. Regards, Maciej
Re: [whatwg] Attribute for holding private data for scripting
Henri, thanks for the link to PPK's suggestions -- I rather like many of them. 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. I'm having a hard time seeing what you're talking about here. When PPK says This attribute [to store data for unobtrusive scripts] should be valid for all HTML elements. I'm rather sure I've lost you. Sometimes, I'll stick a long string inside an invisible textarea just so as to give JavaScript something to chew on -- then I can use string.split to pull the data apart. Is that what you mean? I rather doubt it. By private you don't really mean inaccessible to end users do you? I think I need an example to understand. regards, David
Re: [whatwg] Attribute for holding private data for scripting
I can think of two possibilities.
One would be to allow the param element as a child of any element (or any
block level element?)
http://www.whatwg.org/specs/web-apps/current-work/#param
And then make an attribute of HTMLElement called params
readonly attribute HTMLCollection params;
Where params is a collection of HTMLParamElements that are children (not
further descendants) of that element.
That would make this:
div id=fooparam name=answer value=42Some more content/div
easy to access via JavaScript:
var foo = document.getElementById(foo);
if(foo.params['answer'] == 42) {
// it is!!
}
The only other possibility I can think of would be an HTML attribute called
params that would be a list of tokenized name value pairs, but that sounds
even hairier to implement.
This would have simplified something I did last week involving the Google
Maps API, where I did, as mentioned, make up a fake attribute. There may be
better ways to do this.
On 4/9/07, ddailey [EMAIL PROTECTED] wrote:
Henri, thanks for the link to PPK's suggestions -- I rather like many of
them.
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.
I'm having a hard time seeing what you're talking about here. When PPK
says
This attribute [to store data for unobtrusive scripts] should be valid
for
all HTML elements. I'm rather sure I've lost you.
Sometimes, I'll stick a long string inside an invisible textarea just so
as
to give JavaScript something to chew on -- then I can use string.split to
pull the data apart. Is that what you mean? I rather doubt it.
By private you don't really mean inaccessible to end users do you?
I think I need an example to understand.
regards,
David
--
Jon Barnett
[whatwg] Attribute for holding private data for scripting
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. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
