This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html Multipage: http://www.whatwg.org/C#microdata-dom-api Complete: http://www.whatwg.org/c#microdata-dom-api Comment: Definition of .properties does not match implementation reality Posted from: 71.184.125.56 by bzbarsky@mit.edu User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/15.0 Firefox/15.0a1
Specifically, this part: The properties IDL attribute on HTML elements must return an HTMLPropertiesCollection rooted at the Document node combined with the fact that all the properties are in the element's home subtree would mean that elements that are not in the document should always have an empty .properties. That doesn't seem to be terribly useful, and as far as I can tell Opera doesn't implement that. Neither does the upcoming Gecko implementation. See upcoming testcase: it would alert 0, then 2, if the spec was actually followed here. In Opera it alerts 1, then 2.
This bug was cloned to create bug 18194 as part of operation convergence.
It's intentional that .properties on elements not in a Document would be empty... not my fault y'all can't follow the spec. :-P
bz: Do you still have the aforementioned testcase, by any chance?
I don't have the testcase anymore, sorry. It was just doing basic testing of what happens in a disconnected subtree. I think the reason people didn't follow the spec as you wrote is threefold: 1) "It doesn't seem to be terribly useful". 2) The action-at-a-distance due to the implications of "rooted at" involving digging up a separate (unlinked, too) spec bit, combined with the fact that actually sharing implementations between HTMLPropertiesCollection and other HTMLCollections didn't happen at least in Gecko for various reasons, so the rooting didn't give behavior for free. 3) Whoever wrote the tests implementors used to verify their implementations didn't follow the spec either. with #3 being likely most important in practice. We could probably change Gecko to do what the spec says if you really think that's a better approach. Why is it better?
I'm not sure it's really better — I don't really know what it means to be checking for the properties of a node that's not in a Document. But I can root it at the home subtree's root element, or something? I'll have to test to see what implementations actually do.
It's worth seeing if Opera is willing to change. I'd really much rather root at the document in Gecko, for what it's worth. Speccing the other is a pain, since the home subtreee's root obviously changes over time. Of course the owner document also changes over time (see adoptNode), so things are a bit annoying no matter what.
I don't have a strong opinion, but Opera's behavior seems more useful than the spec's.
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2086 Gecko and Opera do a remarkable job of implementing what the spec doesn't say, so I guess I'll change the spec to match them... :-)
Checked in as WHATWG revision r7705. Check-in comment: Match reality. It's a bit more useful anyway, arguably. http://html5.org/tools/web-apps-tracker?from=7704&to=7705
Checked in as WHATWG revision r7706. Check-in comment: Clarify that the collection's root might change during the collection's lifetime. http://html5.org/tools/web-apps-tracker?from=7705&to=7706