14039 2011-09-06 07:23:03 +0000 The algorithm for finding properties of an item doesn't check for element namespace 2011-10-28 23:06:17 +0000 1 1 1 Unclassified HTML WG HTML Microdata (editor: Ian Hickson) unspecified PC Linux RESOLVED FIXED P2 normal --- 1 hsivonen ian ian jackalmage jeni kennyluck mike philipj public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 56365 0 hsivonen 2011-09-06 07:23:03 +0000 http://www.whatwg.org/specs/web-apps/current-work/#the-properties-of-an-item Hixie says the attributes should only be considered on HTML elements. I ask why not on SVG and MathML elements, too. 56385 1 jackalmage 2011-09-06 15:14:39 +0000 Because it's only defined on HTML. We've been minimally invasive to the other two languages. I assume the addition of the Microdata attributes to SVG and MathML should be brought up with those language bodies. 56459 2 philipj 2011-09-07 07:54:02 +0000 AFAICT for looking at the code and no testing, Opera's implementation only considers the item* attributes in the HTML namespace. If we support Microdata in SVG or MathML, then we really should have a different set of element-specific rules for itemValue as well. 58387 3 ian 2011-10-18 22:38:18 +0000 Yeah this was intentionally not written to "pollute" other namespaces. If those namespaces are interested in supporting the microdata DOM interfaces and content attributes, and being handled in the various processing models for microdata, then we can certainly do that. However, I would suggest we wait until there's a real need for it. So far, it's not 100% clear that there's a clear need for microdata at all; the only large-scale consumed use of it that I'm aware of is schema.org. Any objection to marking this "LATER"? 58539 4 hsivonen 2011-10-20 12:16:09 +0000 I think it would be better to be explicit about namespaces (even if that meant only considering the HTML namespace) than to mark anything LATER. (REMIND and LATER don't really help people like me who review patches that implement this stuff.) 58560 5 ian 2011-10-20 20:12:29 +0000 In what sense are we not explicit already? I don't understand what the problem is. I thought this was just an RFE for adding microdata to SVG and MathML, for which LATER seems like the appropriate next step. I'm happy to fix a problem if there is one. Can you elaborate? 58755 6 hsivonen 2011-10-24 16:09:18 +0000 (In reply to comment #5) > In what sense are we not explicit already? The properties of an item algorithm doesn't say that only HTML elements are considered. 58941 7 ian 2011-10-25 19:22:56 +0000 It says that only elements with an itemprop="" are considered (where "itemprop" is a hyperlink to the definition of the HTML attribute), and only HTML elements can have it. This is the same as how when the spec refers to elements with the contenteditable="" attribute it is only referring to HTML elements. There's no way I can sanely make this explicit all over the spec. It would make it completely unreadable. Almost every mention of an HTML-specific global attribute (tabindex, hidden, title, dir, dropzone...) would need to be qualified as only applying to HTML. I've added a section that calls this out, and then added another section calling it out again for microdata specifically. Hopefully that's sufficient? 58942 8 contributor 2011-10-25 19:23:22 +0000 Checked in as WHATWG revision r6754. Check-in comment: Try to clarify that global HTML attributes aren't global across other namespaces without having to litter '...and is an HTML element' all over the spec. http://html5.org/tools/web-apps-tracker?from=6753&to=6754 58973 9 hsivonen 2011-10-26 06:27:31 +0000 (In reply to comment #7) > Hopefully that's sufficient? It is, though not as good for spec random access as "and is an HTML element" all over the place. Did you intend to mark this FIXED? 59162 10 ian 2011-10-28 23:06:17 +0000 I left it open so I would see your response. :-) I agree that for people jumping into specific parts of the spec, it's more discoverable for this to be repeated at each point. Unfortunately, it also makes the spec really quite hard to read in general if you're not looking for this particular point. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given above Rationale: see comments above Please don't hesitate to reopen if you can think of a better way to fix this that is more discoverable without being exceedingly verbose.