[whatwg] Microdata

On Mon, 24 Aug 2009, Philip J?genstedt wrote:
> 
> 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>

As specced now, having itemprop="" and item="" on the same element implies 
that the value of the property is an item rooted at this element.

Not supporting the above was intentional, to keep the mental model of the 
markup very simple, rather than having shortcuts. (RDFa has lots of 
shortcuts and it ended up being very difficult to keep the mental model 
straight.)


> 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.

Fair points.


> 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".

Ok...


> 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.

That sounds kinda confusing...


> If the parent-item (com.example.blog) doesn't know what the child-items 
> are, it would simply use itemprop="item".

I don't understand this at all.


> 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 don't understand what this maps to at all.


> 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

We can't disallow nesting items as values of properties, there are a whole 
bunch of use cases that depend on it.

Could you show how your syntax proposals would look when marking up the 
following data?

// JSON DESCRIPTION OF MARKED UP DATA
// document URL: http://www.example.org/sample/test.html
{
  "items": [
    {
      "type": "com.example.product",
      "properties": {
        "about": [ "http://example.com/products/bt200x" ],
        "image": [ "http://www.example.org/sample/bt200x.jpeg" ] // please keep this one outside the item in the DOM
        "name": [ "GPS Receiver BT 200X" ],
        "reldate": [ "2009-01-22" ],
        "review": [
          {
            "type": "",
            "properties": {
              "reviewer": [ "http://ln.hixie.ch/" ],
              "text": [ "Lots of memory, not much battery, very little accuracy." ]
            }
          }
        ],
      }
    },
    {
      "type": "work",
      "properties": {
        "about": [ "http://www.example.org/sample/image.jpeg" ],
        "license": [ "http://www.opensource.org/licenses/mit-license.php" ]
        "title": [ "My Pond" ],
      }
    }
  ]
}


Here's how it would be marked up today:

<section id="bt200x" item=com.example.product>
 <link itemprop=about href="http://example.com/products/bt200x">
 <h1 itemprop=name>GPS Receiver BT 200X</h1>
 <p>Rating: &#x22C6;&#x22C6;&#x22C6;&#x2729;&#x2729; <meta itemprop=rating content="2"></p>
 <p>Release Date: <time itemprop="reldate" datetime="2009-01-22">January 22</time></p>
 <p itemprop=review item><a itemprop=reviewer href="http://ln.hixie.ch/">Ian</a>:
 "<span itemprop=text>Lots of memory, not much battery, very little accuracy.</span>"</p>
</section>
<figure item=work>
 <img itemprop=about src="image.jpeg">
 <legend>
  <p><cite itemprop="title">My Pond</cite></p>
  <p><small>Licensed under the <a itemprop="license"
  href="http://www.opensource.org/licenses/mit-license.php">MIT
  license</a>.</small>
 </legend>
</figure>
<p><img subject="bt200x" itemprop="image" src="bt200x.jpeg" alt="..."></p>


-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 24 August 2009 15:29:06 UTC