Summary: | [Microdata] A microdata item should add the first element that matches the id specified in the itemref attribute. | ||
---|---|---|---|
Product: | WebKit | Reporter: | Arko Saha <arko> |
Component: | DOM | Assignee: | Arko Saha <arko> |
Status: | RESOLVED INVALID | ||
Severity: | Normal | CC: | rniwa |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified |
Description
Arko Saha
2012-07-13 08:25:20 PDT
Lets take an small example: <div id="id1"> <p itemprop="foo" id="a"></p> </div> <section itemscope itemref="id2 id1"> <p itemprop="foo" id="b"></p> </section> <div id="id2"> <p itemprop="foo" id="c"></p> </div> 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. |