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.

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.

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"?

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.)

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?

(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.

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?

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

(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?

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.