[whatwg] Microdata

[Philip Jägenstedt]

On Sat, 22 Aug 2009 23:51:48 +0200, Ian Hickson <ian at hixie.ch> wrote:

>
> Based on some of the feedback on Microdata recently, e.g.:
>
>    http://www.jenitennison.com/blog/node/124
>
> ...and a number of e-mails sent to this list and the W3C lists, I am  
> going
> to try some tweaks to the Microdata syntax. Google has kindly offered to
> provide usability testing resources so that we can try a variety of
> different syntaxes and see which one is easiest for authors to  
> understand.
> If anyone has any concrete syntax ideas that they would like me to
> consider, please let me know. There's a (pretty low) limit to how many
> syntaxes we can perform usability tests on, though, so I won't be able to
> test every idea.
>

I've found two related things that are a bit problematic. First, because  
itemprops are only associated with ancestor item elements or via the  
subject attribute, it's always necessary to find or create a separate  
element for the item. This leads to more convoluted markup for small  
items, so it would be nice if the first item and itemprop could be on the  
same element when it makes sense:

<p item="vevent" itemprop="description">
   Concert at <span itemprop="dtstart">19:00</span> at <span  
itemprop="location">the beach</span>.
</p>

rather than

<p item="vevent">
   <span itemprop="description">
     Concert at <span itemprop="dtstart">19:00</span> at <span  
itemprop="location">the beach</span>.
   </span>
</p>

Second, because composite items can only be made by adding item and  
itemprop to the same element, the embedded item has to know that it has a  
parent and what itemprop it should use to describe itself. James gave the  
example of "something like planet where each article could be a  
com.example.blog item and within each article there could be any arbitrary  
author-supplied microdata" [1]. I also feel that the item+itemprop syntax  
for composite items is one of the least intuitive parts of the current  
spec. It's easy to get confused about what the type of the item vs the  
itemprop should be and which item the itemprop actually belongs to.

Given that flat items like vcard/vevent are likely to be the most common  
use case I think we should optimize for that. Child items can be created  
by using a predefined item property: itemprop="com.example.childtype  
item". The value of that property would then be the first item in  
tree-order (or all items in the subtree, not sure). This way, items would  
have better copy-paste resilience as the whole item element could be made  
into a top-level item simply by moving it, without meddling with the  
itemprop. If the parent-item (com.example.blog) doesn't know what the  
child-items are, it would simply use itemprop="item".

Example:

<p item="vcard" itemprop="n item">
   My name is <span itemprop="given-name">Philip</span>
   <span itemprop="family-name">Jägenstedt</span>.
</p>

I'll admit that my examples are a bit simple, but the main point in my  
opinion is to make item+itemprop less confusing. There are basically only  
3 options:

1. for compositing items (like now)
2. as shorthand on the top-level item (my suggestion)
3. disallow

I'd primarily like for 1 and 2 to be tested, but 3 is a real option too.

[1] http://krijnhoetmer.nl/irc-logs/whatwg/20090824#l-375

-- 
Philip Jägenstedt
Opera Software