in Technical 337 Words

HTML5 Microdata Fantasy

I haven’t been tracking HTML5 design efforts lately but what’s being proposed for microdata (see posts by Sam Ruby and Shelly Powers) yucked me sufficiently to revisit an old fantasy of mine about HTML (man, what a boring life I have). My fantasy was to add general element/structure definition facility to HTML. It should easily extended to support microdata as well.

The way I envisioned it being used is like this:

<address>
<street>123 ABC St.</street>
<city>Foobar</city>
<state>CA</state><zip>94065</zip>
</address>

which sure is preferable to:

<div item>
<span itemtype="street">123 ABC St.</span>
<span itemtype="city">Foobar</span>
<span itemtype="state">CA</span>
<span itemtype="zip">94065</span>
</div>

As to how a semantic structures and syntactic sugars can be defined, one very arbitrary way could be:

<head>
<def name="address" package="http://test.com/1/mapking"
    params="{{street city state zip}}">
  <div>
    <span>{{street}}</span>
    <span>{{city}}</span>
    <span>{{zip}}</span>
    <span>{{zip}}</span>
  </div>
</def>
</head>

I don’t have any illusions that this fantasy has even a tiny chance of coming true though. Besides, it’s like a beggar asking for caviar when any kind of microdata support will satiate our hunger.

Boss! Boss! The Plane. The Plane!

update:

Here is a more elaborate version of the def element for the bored:

<def name="name" package="http://ting.ly/name"
  attrs="$$first last$$">
  <span>$$first$$ $$middle$$ $$last$$</span>
</def>

which could be used like this:

<name first="Don" last="Park"/>

There are lots of wholes in this sketch which is why it’s a fantasy.

7 thoughts on “HTML5 Microdata Fantasy”

  1. You can’t stop a stampede my man. The general html semantics has too much momentum to change direction too much, besides we’re just now starting to get browsers that act somewhat similar. In the end it is all just XML nodes, but try telling that to IE.

  2. Yeah, I know. I was there when IE core guys explained how the IE worked during a W3C DOM WG meeting. If I could, I would bury W3C in the sand then build an out house over it.

  3. How would your idea differ from simply defining all the data in a separate machine-readable XML file and then using XSLT (or some other templating language) to construct the HTML from it?

  4. If it’s done on client-side, only that I think this is easier to learn than XSLT. If XSLT transform is server-side, this is easier to use as well. I find XSLT learning curve rather steep for average HTML jockey.

  5. If you were to put city state, zip and street elements in a namespace and use CSS3 selectors then you wouldn’t need any syntax transformation in the page, or anywhere else.

    Once the elements are in a namespace and the markup is valid XML getting to RDF (via GRDLL) or unmarshalling objects (XPath, JAX-B) is easy – everyone is happy. Most intelligent people are able to grok XML namespaces given a few days of exposure to them.

    Given CSS3 rather than a def element there is very little missing from standards and tools, so this is not especially fantastic.

  7. “There are lots of wholes in this sketch which is why it’s a fantasy.”
    I first read that as “There are lots of whores in this sketch which is why it’s a fantasy.”

    Which didn’t make sense in the context (but makes sense otherwise). I then realised you meant “There are lots of holes in this sketch which is why it’s a fantasy.”

    Curse that double-you!

Comments are closed.