This has come up with https://bugs.webkit.org/show_bug.cgi?id=80269#c33
According to the spec http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#associating-names-with-items (220.127.116.11), microdata item should add the first element that matches the id specified in the itemref attribute. Currently we add we add all elements that match the id.
We should fix that (with a test). In addition, that means we can just use TreeScope::getElementById instead of traversing the entire tree scope.
Lets take an small example:
<p itemprop="foo" id="a"></p>
<section itemscope itemref="id2 id1">
<p itemprop="foo" id="b"></p>
<p itemprop="foo" id="c"></p>
Here <section> has itemscope attribute, its a microdata item.
item.properties.namedItem(foo) must return a PropertyNodeList object containing three <p> elements with id- a, b, c respectively. it should be in the tree order.
With itemref attribute we can add additional properties. These itemref id may appear in random order. But we have to make sure that properties added with itemref must be in treeorder while adding in itemRefElement list.
If we find the itemref elements using TreeScope::getElementById, then we need to sort them in tree order. We have already discussed the same in https://bugs.webkit.org/show_bug.cgi?id=80490
As per the discussion sorting is not recommended as its an expensive operation. So we have decided to traverse the DOM and collect the elements with the itemref ids in the document order.
I think its better to traverse the entire document and collect itemref elements in the document order instead of sorting as sorting is very inefficient.
Also please note that currently we add the first element only that matches the id specified in the itemref attribute. We do not add all the elements that matches the ref id. We have a test to ensure the same : fast/dom/MicroData/itemref-refers-first-element-with-given-id.html
So this bug is invalid?
(In reply to comment #2)
> So this bug is invalid?
Yes, this is an invalid bug.