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

Re: Microdata: The Itemref element

From: Philip Jägenstedt <philipj@opera.com>
Date: Mon, 19 Oct 2009 13:00:08 +0200
To: "Nicholas Stimpson" <nicholas.stimpson@ntlworld.com>, public-html@w3.org
Message-ID: <op.u11niiycatwj1d@sisko.linkoping.osa>
On Sun, 18 Oct 2009 21:18:40 +0200, Nicholas Stimpson  
<nicholas.stimpson@ntlworld.com> wrote:

> Dear HTML WG,
>
> I have been looking at the practicalities of using microdata.
>
> One issue that concerns me is the itemref element. The itemref element  
> is defined as empty, but current browsers don't recognise the element,  
> so non-IE browsers treat it as having content.
>
> Take this example from the draft:
>
> <div itemscope>
>  <itemref refid="x">
>  <p itemprop="b">test</p>
>  <p itemprop="a">2</p>
> </div>
> <div id="x">
>  <p itemprop="a">1</p>
> </div>
>
> Currently in non-IE browsers this will produce this DOM - Taken in  
> Firefox 3.5 from  
> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cbody%3E%0A%3Cdiv%20itemscope%3E%0A%20%3Citemref%20refid%3D%22x%22%3E%0A%20%3Cp%20itemprop%3D%22b%22%3Etest%3C%2Fp%3E%0A%20%3Cp%20itemprop%3D%22a%22%3E2%3C%2Fp%3E%0A%3C%2Fdiv%3E%0A%3Cdiv%20id%3D%22x%22%3E%0A%20%3Cp%20itemprop%3D%22a%22%3E1%3C%2Fp%3E%0A%3C%2Fdiv%3E%0A%0A
>
>     * DOCTYPE: |HTML|
>     * |HTML|
>           o |HEAD|
>                 + |#text|:
>           o |BODY|
>                 + |#text|:
>                 + |DIV| |itemscope|="||"
>                       # |#text|:
>                       # |ITEMREF| |refid|="|x|"
>                             * |#text|:
>                             * |P| |itemprop|="|b|"
>                                   o |#text|: test
>                             * |#text|:
>                             * |P| |itemprop|="|a|"
>                                   o |#text|: 2
>                             * |#text|:
>                 + |#text|:
>                 + |DIV| |id|="|x|"
>                       # |#text|:
>                       # |P| |itemprop|="|a|"
>                             * |#text|: 1
>                       # |#text|:
>                 + |#text|:
>
> In IE now, and presumably, at some point in the future, the other  
> browsers will be changed to treat itemref as empty, at which point, this  
> DOM will be produced.
>
>     * DOCTYPE: |HTML|
>     * |HTML|
>           o |HEAD|
>                 + |#text|:
>           o |BODY|
>                 + |#text|:
>                 + |DIV| |itemscope|="||"
>                       # |#text|:
>                       # |ITEMREF| |refid|="|x|"
>                       # |#text|:
>                       # |P| |itemprop|="|b|"
>                             * |#text|: test
>                       # |#text|:
>                       # |P| |itemprop|="|a|"
>                             * |#text|: 2
>                       # |#text|:
>                 + |#text|:
>                 + |DIV| |id|="|x|"
>                       # |#text|:
>                       # |P| |itemprop|="|a|"
>                             * |#text|: 1
>                       # |#text|:
>                 + |#text|:
>
> Clearly, for many web pages this may require different CSS selectors and  
> scripting to handle both cases, and it is likely to be a major source of  
> bugs and confusion.
>
> Is it really necessary for microdata to mint a new empty element here?
>
> Instead, would it be possible for the element with the "itemscope"  
> attribute to have an itemref attribute that was a space separated list  
> of ids?
>
>
> Or if that's not possible, could an existing empty element be overloaded  
> to replace itemref? Both "link" and "param" seem to check out in the  
> live DOM viewer as possibles, providing that one encountering them the  
> parser has already reached the parsing-the-body mode. Link is already  
> being overloaded for the itemprop attribute so extending that with an  
> itemref attribute doesn't seem a huge leap. e.g. instead of
>
> <itemref refid="x">
>
> have
>
> <link itemref="x">
>
> I don't pretend to understand what the side effects of doing something  
> like this would be, though.
>
>
> If that can't be done, then one authoring approach to solve the problem  
> would be to write
>
> <itemref refid="x"></itemref>
>
> However, that is invalid HTML5, which personally I'd live with, but  
> doesn't seem the happiest outcome. Maybe this could be made valid? (The  
> HTML shiv could be used to avoid getting the /ITEMREF tag in IE)
>
>
> If none of the above is practical, then could the draft contain advice  
> to place itemref elements at the end of the itemscope div like this?
>
> <div itemscope>
>  <p itemprop="b">test</p>
>  <p itemprop="a">2</p>
>  <itemref refid="x">
> </div>
> <div id="x">
>  <p itemprop="a">1</p>
> </div>
>
> Although the DOMs will still be different if there's more than itemref  
> element, the effect on css selectors and scripting will be minimised.
>
> - Nicholas Stimpson.
>
>

Thanks Nicholas for bringing this up. I'm also not a big fan of the  
itemref element, for two reasons. First, it's a new void element, which is  
always problematic, especially when we expect it to be sprinkled all over  
existing markup (unlike <source> which will be inside <video>).

Second, it makes HTMLPropertyCollection a more difficult to implement, see  
yesterdays bug [1] and the IRC discussion [2] for some details. Because  
<itemref> allows looped references, the algorithm for determining the  
properties of an item is complicated by keeping a list of visited nodes.  
This will be added complexity for browser implementations and external  
parsers alike.

Using an attribute avoids both of these issues. It would simplify the  
algorithm as the only possibility of loops is if there's a reference to  
the @itemscope'd element or an ancestor of it, which is much easier to  
check (just one node instead of a list of all visited nodes).

The question is if there was ever a use case for chained references which  
we would break by doing this simplification. As far as I can see, it would  
be something like:

<!-- two properties in different subtrees -->
<p>
  <span id="a" itemprop="prop-a">Property A</span>
</p>

<p>
  <span id="b" itemprop="prop-b">Property B</span>
</p>

<!-- something to collect them both -->
<div id="both">
  <itemref refid="a">
  <itemref refid="b">
</div>

<!-- reuse in two different items -->
<div itemscope>
   <itemref refid="both">
   <span itemprop="not-shared">This property isn't shared</span>
</div>

<div itemscope>
   <itemref refid="both">
</div>

Sorry, I can't come up with an example that makes sense. It seems that the  
only reason to do the above is to share properties between items while  
saving some typing. In that case itemref="a b" on both @itemscope'd  
elements would still be less typing than this.

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=7964
[2] http://krijnhoetmer.nl/irc-logs/whatwg/20091019#l-24
[2]  
http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#the-properties-of-an-item

-- 
Philip Jägenstedt
Core Developer
Opera Software
Received on Monday, 19 October 2009 11:00:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:09 UTC