13610 2011-08-03 15:34:39 +0000 [DOM Core] Remove HTMLElement.id 2011-09-30 20:01:20 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#global-attributes P3 normal --- 1 contributor ian annevk ayg cam hsivonen ian mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 52184 0 contributor 2011-08-03 15:34:39 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html Multipage: http://www.whatwg.org/C#global-attributes Complete: http://www.whatwg.org/c#global-attributes Comment: [DOM Core] Remove HTMLElement.{id,className,classList} Posted from: 91.181.50.33 User agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/534.35 (KHTML, like Gecko) Chrome/13.0.761.0 Safari/534.35 53469 1 mike 2011-08-04 05:14:10 +0000 mass-move component to LC1 54923 2 ian 2011-08-14 06:23:06 +0000 That's gonna be interesting, since I presume the content attributes remain in the HTML spec. 54945 3 annevk 2011-08-14 08:31:49 +0000 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. 55006 4 ayg 2011-08-14 23:29:57 +0000 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? 55017 5 ian 2011-08-15 03:58:54 +0000 I'm not really convinced this is a good idea. What problem is it solving? 55055 6 annevk 2011-08-15 08:10:46 +0000 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. 55128 7 ayg 2011-08-15 18:53:38 +0000 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. 55130 8 annevk 2011-08-15 19:06:48 +0000 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. 55645 9 ian 2011-08-23 00:15:13 +0000 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. 55647 10 cam 2011-08-23 00:34:34 +0000 (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. 57364 11 ian 2011-09-26 19:56:25 +0000 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. 57395 12 hsivonen 2011-09-27 07:36:25 +0000 (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. 57510 13 annevk 2011-09-29 14:55:01 +0000 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. 57568 14 ian 2011-09-30 17:47:31 +0000 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. 57569 15 contributor 2011-09-30 17:48:00 +0000 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