[whatwg] Microdata DOM API

Philip Jägenstedt philipj at opera.com
Thu Aug 20 15:50:51 PDT 2009


Hi,

There are already two demos of converting Microdata to other formats which  
I found quite useful [1]. I've taken a closer look at the Microdata DOM  
API and hacked up a somewhat working JavaScript implementation of it [2].  
A few issues came up in the process:

To avoid total confusion I'll use item-property and DOM-property to  
disambiguate.

The spec says that "properties can also themselves be groups of name-value  
pairs", but this isn't exposed in a very convenient way in the DOM API.  
The 'properties' DOM-property is a HTMLPropertyCollection of all  
associated elements. Discovering if the item-property value is a plain  
string or an item seems to require item.hasAttribute('item'), which seems  
out of place when everything else has been so neatly reflected. (Just  
checking item.item won't work if the item attribute is empty.) Also, the  
'contents' DOM-property is always the item-property value except in the  
case where the item-property is another item -- in that case it is  
something random like .href or .textContent depending on the element type.  
I think it would be better if the DOM-property were simply called 'value'  
(the spec does talk about name-value pairs after all) and corresponded  
more exactly to 'property value' [3]. Elements that have no 'property  
names' [4] should return null and otherwise elements with an 'item'  
attribute should return itself, although I don't think it should be  
writable in that case. One might also/otherwise consider adding a  
valueType DOM-property which could be 'string', 'item' or something  
similar.

One example [5] uses document.items[item].names but document.items isn't  
defined anywhere. I assume this is an oversight and that it is equivalent  
to document.getItems() Further, names is a member of  
HTMLPropertyCollection, so document.items[item].properties.names is  
probably intended instead of document.items[item].names. Assuming this the  
example actually produces the output it claims to.

Shouldn't namedItem [6] be namedItems? Code like .namedItem().item(0)  
would be quite confusing. Also, RadioNodeList should be PropertyNodeList.

I think many will wonder why item and itemprop can't be given on a single  
element for compactness:

<span item="org.example.fruit" itemprop="org.example.name">Apple</span>s  
and <span item="org.example.fruit"  
itemprop="org.example.name">Orange</span>s don't compare well.

Allowing this would complicate the definition of 'corresponding item' [7],  
but I think that might be acceptable. I suggest either allowing it or  
adding a note explaining why it isn't allowed and giving examples of  
alternative techniques.

[1] http://philip.html5.org/demos/microdata/demo.html
     http://james.html5.org/microdata/
[2]  
http://gitorious.org/microdatajs/microdatajs/blobs/0032bac85ceaf4fd2a6379b357a225f74c89d61f/microdata.js
[3]  
http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#concept-property-value
[4]  
http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#property-names
[5]  
http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#using-the-microdata-dom-api
[6]  
http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#dom-htmlpropertycollection-nameditem
[7]  
http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#concept-item-corresponding

-- 
Philip Jägenstedt
Doing Microdata just for fun, not for Opera Software.



More information about the whatwg mailing list