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

[whatwg] Embedding custom hierarchical data

From: Hay <huskyr@gmail.com>
Date: Tue, 15 Mar 2011 21:06:55 +0100
Message-ID: <AANLkTi=7gmz9yHttyN52HL-8yHMOfPXoYap90goyVpuX@mail.gmail.com>
Hi everyone,
what would be the 'preferred' way to embed custom hierarchical data in
a HTML document?

Consider, for example, a list that contains custom data that needs to
be displayed using Javascript. In most cases, the data-* attributes
are a nice way to embed non-visual data to be read out later, but that
doesn't work for hierarchical structures. There are a few possible
solutions:

1) Microdata. This could work, but only if the data should be
displayed as well. If the data should be processed (and for example,
be shown in another part of the page) this doesn't work really well.
You could the hide the parent element with CSS, but that's pretty
clunky.

2) data-* attributes with JSON data. Would work, but pretty ugly and
not very expressive and readable.

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.
Semantically, 'xml islands' as used in older versions of IE seem like
an elegant solution but are not supported in other browsers.

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

-- Hay Kranen
Received on Tuesday, 15 March 2011 13:06:55 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:31 UTC