mass-move component to LC1

That's gonna be interesting, since I presume the content attributes remain in the HTML spec.

The idea is that DOM defines the behavior, including of the content attributes, but does not actually define their semantics (if any) and whether they are conforming.

Does that mean that the definition of an IDL attribute reflecting a DOM attribute has to be moved from HTML to DOM for the sake of three attributes?

I'm not really convinced this is a good idea. What problem is it solving?

It simplifies the platform, primarily. And gives some forward compatibility. Implementors seem interested in doing it, but maybe we should not update HTML until it is actually adopted.

Hopefully it doesn't give us forward compatibility, because hopefully any new features we're going to add will be in the HTML namespace.  The simplification seems a bit marginal.

Not having to coordinate id/className/classList among three specifications and not having to check the namespace when doing ID or class matching is a quite significant simplification. Enough so that implementors have wanted to make it for ages.

But we're still going to have to do pre-namespace stuff here unless SVG drops its animation of className, no? The simplification really seems minimal to me.

(In reply to comment #9)
> But we're still going to have to do pre-namespace stuff here unless SVG drops
> its animation of className, no? The simplification really seems minimal to me.

The className conflict is a good point.  Not sure how we might resolve that yet.

Let's split the ID and class issues up here, and use this bug just for the ID side. Once the class complications are resolved, if it still requires changes to the HTML spec, file a new bug.

As far as ID goes, the DOM Core spec currently has the following issues:

 - it doesn't allow for multiple IDs per element. While I'm sure we all think that allowing that is problematic, and we're working to make it impossible, the truth of the matter is that we have so far had at least 4 ways to set IDs (id="", xml:id="", IDness in DTD, and the old DOM APIs), and I see no reason to believe that we'll prevent people from making up new ones in the future. So we should at least admit the possibility.

 - no special handling is defined for when the id="" attribute's value is the empty string.

Once these are resolved I can remove the relevant sentences from the HTML spec.

(In reply to comment #11)
> I see no reason to
> believe that we'll prevent people from making up new ones in the future. So we
> should at least admit the possibility.

An alternative is to make attempts to introduce more IDs in the future so full of FAIL that it's obvious that people shouldn't try. Maybe even say in the spec that spec writers MUST NOT attempt to introduce new IDs.

By making IDs a concept of the DOM multiple identifiers are out of the window. I added a note to that effect. I also clarified when an element has an ID, including that it does not have one when there is an id attribute whose value is the empty string.

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 below
Rationale: Ok, sounds good.

Checked in as WHATWG revision r6605.
Check-in comment: move .id and ID processing to DOM Core.
http://html5.org/tools/web-apps-tracker?from=6604&to=6605