[whatwg] Possible bugs : Microdata Itemscope on <link/> and <meta/>

[Philip Jägenstedt]

On Sun, 29 Nov 2009 14:28:05 +0100, Philip Jägenstedt <philipj at opera.com>  
wrote:

> Now, back to the problem of one property, multiple items. The algorithm  
> for finding the properties of an item [2] is an attempt at optimizing  
> the search for properties starting at an item element. I think we should  
> replace this algorithm with an algorithm for finding the item of a  
> property. This was previously the case with the spec before the itemref  
> mechanism. I would suggest something along these lines:
>
> 1. let current be the element with the itemprop attribute
> 2. if current has an ID, for each element e in document order:
> 2.1. if e has an itemref attribute:
> 2.1.1. split the value of that itemref attribute on spaces. for each  
> resulting token, ID:
> 2.1.1.1. if ID equals the ID of current, return e
> 3. reaching this step indicates that the item wasn't found via itemref  
> on this element
> 4. let parent be the parent element of current
> 5. if parent is null, return null
> 6. if parent has the itemscope attribute, return parent
> 7. otherwise, let current be parent and jump to step 2.
>
> This algorithm will find the parent item of a property, if there is one.  
> itemref'ing takes precedence over "parent-child linking", so in Tim's  
> example the properties of Shanghai would be applied to only the Shanghai  
> sub-item. I'm not convinced writing markup like that is a good idea, but  
> at least this way it has sane processing. HTMLPropertiesCollection on  
> any given element would simply match all elements in the document for  
> which the the algorithm returns that very element. It should be invalid  
> for there to be any elements in the document with itemprop where this  
> algorithm returns null or the element itself.
>
> I will try implementing this algorithm in MicrodataJS [3] and see if it  
> works OK. While it may look less efficient than the current algorithm,  
> consider that a browser won't implement either algorithm as writting,  
> only act as if they did. The expensive step of going through all  
> elements with itemref attributes is actually no more expensive than e.g.  
> document.querySelector('.classname') if implemented natively.
>
> [1]  
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024095.html
> [2]  
> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#the-properties-of-an-item
> [3] http://gitorious.org/microdatajs
>

With an added check to ignore self-referencing itemrefs, my algorithm  
seems to work. The only test cases I have where the result (as seen  
through HTMLPropertiesCollection) isn't the same is one similar to Tim's  
"1 property 2 items" and one involving self-reference. Incidentally, the  
cases which caused the JSON and vCard extraction algorithm to recurse  
infinitely now terminate with sane results.

A consequence of this change is that when two elements add the same  
property by itemref, only one will get it (the first in document order).  
This means that it isn't possible to share properties between items, which  
is precisely the point to avoid loops. If there was a use case that  
required property sharing, this needs some more tinkering. I'm inclined to  
say that when such sharing is wanted, one should add a level of  
indirection, e.g. with an ID. This way the microdata model is kept  
strictly tree-like.

To make the limitations clear to authors, an element with itemprop for  
which the algorithm returns null should be invalid. For elements with  
itemref, it should be invalid for any of the referenced elements to either  
not exist or to have another item as their "owner". In short, itemref'ing  
must be consistent.

For the curious, from the (not so optimized) JavaScript implementation:

function getCorrespondingItem(node) {
   var current = node;
   while (current) {
     if (current.id) {
       var referrer = document.querySelector('*[itemref~='+current.id+']');
       if (referrer && referrer != node)
	return referrer;
     }
     current = current.parentNode;
     if (current && current.itemScope)
       return current;
   }
   return null;
}

-- 
Philip Jägenstedt