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

[whatwg] Attribute for holding private data for scripting

From: Simon Pieters <zcorpan@gmail.com>
Date: Tue, 10 Apr 2007 20:07:34 +0200
Message-ID: <op.tqkvuydj7a8kvn@hp-a0a83fcd39d2.mdh.se>
On Mon, 09 Apr 2007 21:37:31 +0200, Jon Barnett <jonbarnett at gmail.com>  
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="foo"><param name="answer" value="42">Some 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="42">Some 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
Received on Tuesday, 10 April 2007 11:07:34 UTC

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