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

[whatwg] Attribute for holding private data for scripting

From: Jon Barnett <jonbarnett@gmail.com>
Date: Wed, 11 Apr 2007 13:56:49 -0500
Message-ID: <bde87dd20704111156h37e23f88k4c370286c58ef43a@mail.gmail.com>
On 4/11/07, Kevin Marks <kevinmarks at gmail.com> wrote:
> On 4/11/07, Jon Barnett <jonbarnett at gmail.com> 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;bash&quot;}"></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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20070411/eb0e9b77/attachment.htm>
Received on Wednesday, 11 April 2007 11:56:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:34 UTC