On Sat, 22 Aug 2009 23:51:48 +0200, Ian Hickson <i...@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
