W3C home > Mailing lists > Public > public-html@w3.org > October 2009

Re: Microdata: The Itemref element

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 19 Oct 2009 11:11:14 -0500
Message-ID: <dd0fbad0910190911n706dc493y41e80afac27e8cb1@mail.gmail.com>
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Cc: Olivier GENDRIN <olivier.gendrin@gmail.com>, Philip J├Ągenstedt <philipj@opera.com>, Nicholas Stimpson <nicholas.stimpson@ntlworld.com>, public-html@w3.org
On Mon, Oct 19, 2009 at 10:55 AM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> Despite the error, what Olivier pointed out is that Microdata has a problem
> similar to what has been claimed about RDFa. For RDFa, the table example was
> made a lot of fuzz about by Jon and others: did the algorithm take into
> account where things landed in the DOM or not? Fortunately, though, RDFa
> only operates with attributes. And so, as long as you take account of the
> DOM - which is quite simple, you should be safe. Whereas for Microdata, it
> seems one must think much more about the DOM all the time and use
> workarounds. (We can't sit with the Live DOM Viewer all the time ...)

Yeah, I agree.  Having to workaround this stuff is pretty annoying.
The only real problem with making itemref an attribute on the
@itemscope element is that it prevents chained itemrefs, as brought up
previously (where the main microdata blob has an itemref to another
element, which contains some itemprops and another itemref to a third

This doesn't prevent you from expressing anything, as you can always
just write all the referred-to ids directly in the @itemref attribute,
but it might be annoying in some cases.  If it's not a big deal,
though, then it's probably not a problem to change.

Received on Monday, 19 October 2009 16:12:09 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:53 UTC