W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2011

[whatwg] Embedding custom hierarchical data

From: Henri Sivonen <hsivonen@iki.fi>
Date: Wed, 23 Mar 2011 11:22:30 +0200
Message-ID: <1300872150.2500.350.camel@shuttle>
On Tue, 2011-03-15 at 21:06 +0100, Hay (Husky) wrote:
> 3) 'Data blocks' in a <script> element, as described in the spec. You
> can, for example, use a <script> element with an 'application/xml' or
> 'application/json' type, which will not be processed by a browser, and
> use Javascript to do the parsing.
> 
> Data blocks seem to be the current most usable solution, but i get the
> feeling that it's not quite expressive enough. <script> tags should
> contain scripts, and XML and JSON are not scripting languages.

The spec disagrees with your "should". :-) Don't get too focused on the
element names.

> Something like a <data> tag, with a required 'type' attribute that can
> contain a mime type that could indicate to browsers what type of
> content follows might be an interesting solution, but i'm not sure
> what the implications might be.

It wouldn't be backwards compatible the way <script type=not/js> is.
http://hsivonen.iki.fi/test/moz/xml-data-block.html works in the latest
versions of all the top browsers, so there's really no point in
introducing something new that doesn't work yet.

> It would be cool if you do a <data
> type="application/json"> and get an automatic Javascript object when
> getting the element with document.getElementById.

Since the data will be processed by a script anyway, it's quite
reasonable to ask the script to trigger XML or JSON parsing instead of
making it implicit. This way, there is no need to elevate XML or JSON to
some kind of special status as far as the data container is concerned.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/
Received on Wednesday, 23 March 2011 02:22:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:02 GMT