12844 2011-06-01 14:57:33 +0000 Remove the label attribute from subclasses of HTMLElement 2011-09-14 12:57:11 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified All All RESOLVED FIXED a11ytf P3 blocker --- 12845 1 Ms2ger ian bugs bzbarsky cam ian jan.varga jonas lwatson mike mjs mounir public-html-admin public-html-wg-issue-tracking rubys public-html-bugzilla oldest_to_newest 49014 0 Ms2ger 2011-06-01 14:57:33 +0000 Assuming the shadowed attribute always returns the same thing as the one on HTMLElement, there's really no point in having both. (Otherwise, the spec is doubly broken.) 49554 1 ian 2011-06-14 04:29:24 +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: Rejected Change Description: no spec change Rationale: It doesn't always return the same thing, intentionally. 49556 2 jan.varga 2011-06-14 04:50:36 +0000 What do you mean by "It doesn't always return the same thing, intentionally." ? Do you mean that there are different definitions of .label for elements that define commands (4.11.5.1 - 4.11.5.8) ? Could you actually explain what a shadowed attribute is ? Thanks 49584 3 jan.varga 2011-06-14 16:46:54 +0000 never mind, I was not aware of bug 12845 49758 4 bzbarsky 2011-06-17 02:56:05 +0000 I think the original bug report is right that having "label" on HTMLElement mean one thing but "label" on some particular HTMLElements mean something totally different is pretty broken.... 49909 5 mjs 2011-06-20 09:47:13 +0000 (In reply to comment #4) > I think the original bug report is right that having "label" on HTMLElement > mean one thing but "label" on some particular HTMLElements mean something > totally different is pretty broken.... Not only that, but even if this behavior is desired, redeclaring a "label" property in the IDL has no material effect. The right way to do this is to simply define the behavior of the attribute differently for different elements. There is no need to duplicate it in the IDL to achieve that. 49911 6 cam 2011-06-20 10:37:48 +0000 (In reply to comment #5) > Not only that, but even if this behavior is desired, redeclaring a "label" > property in the IDL has no material effect. It does have the effect of requiring both HTMLElement.prototype.label and HTMLMoreSpecificElement.prototype.label to exist. 49935 7 rubys 2011-06-20 19:26:51 +0000 From the EDITOR'S RESPONSE "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" Does anybody want to propose title and text for the tracker issue? Or to create the tracker issue themselves? 50100 8 mjs 2011-06-22 02:02:17 +0000 (In reply to comment #7) > From the EDITOR'S RESPONSE "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" > > Does anybody want to propose title and text for the tracker issue? Or to > create the tracker issue themselves? Please provide a title and text for the tracker issue (including at least a brief technical description of the issue) by midnight Eastern time on Friday, June 25th, 2011, or the Chairs will remove the TrackerRequest keyword. Anyone adding it back after that point should provide the information required. 50115 9 bzbarsky 2011-06-22 20:34:03 +0000 Title: The "label" attribute on HTMLElement should be renamed. Text: Right now the "label" attribute on HTMLElement has completely different behavior from "label" attributes on some of the interfaces that inherit from HTMLElement. This is pretty confusing to authors. It would be better to call the HTMLElement attribute "commandLabel". 50234 10 rubys 2011-06-24 12:38:38 +0000 (In reply to comment #9) > Title: The "label" attribute on HTMLElement should be renamed. > > Text: Right now the "label" attribute on HTMLElement has completely different > behavior from "label" attributes on some of the interfaces that inherit from > HTMLElement. This is pretty confusing to authors. It would be better to call > the HTMLElement attribute "commandLabel". http://www.w3.org/html/wg/tracker/issues/169 50264 11 ian 2011-06-24 18:34:40 +0000 .label doesn't mean a different thing on HTMLElement and HTMLLabelElement. It means the same thing: it's the label of the command as used in a menu. Renaming the attributes makes no sense given the command API. I'm fine with changing how this is specced, though. It's quite possible that the current mechanism doesn't make much sense. The main reason I did this using shadowing is that there doesn't seem to be a good way to make an attribute readonly on most elements but not all. 50267 12 bzbarsky 2011-06-24 18:45:15 +0000 > there doesn't seem to be a good way to make an attribute readonly on most > elements but not all I agree that we absolutely need a way to do this in webidl. That's come up in some of the other shadowing-related bugs... 50269 13 bzbarsky 2011-06-24 18:46:09 +0000 Upon some further thought, I'd like to retract the escalation request and reopen the bug instead. 50512 14 ian 2011-06-30 18:34:03 +0000 Based on the discussion in bug 12845, it's not clear to me exactly what the problem is here. Is it that a command created with accesskey="" is never disabled, but <textarea>'s "disabled" attribute can be set to true even if the element has an accesskey=""? Is it that there are a number of elements on which one can set accesskey="" and thus cause those elements to become commands, on which the command API attributes are used for other purposes? Or is it something else? (The two above are the two cases that I mentioned in bug 12845 for which I suggested filing bugs if they were considered real problems.) 50524 15 bzbarsky 2011-06-30 21:33:44 +0000 I think at this point the suggestion would be to make use of heycam's new "just declare a setter" feature here. 50930 16 ian 2011-07-11 21:04:55 +0000 After trying to do that for a while I decided you were right after all, and am renaming the command API members so they no longer use the same names as the element members. It's not quite as conceptually neat, but in practice it was going to end up being a massive source of bugs because there were so many edge cases. 50931 17 ian 2011-07-11 21:22:19 +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: http://html5.org/tools/web-apps-tracker?from=6285&to=6286 Rationale: The other model, while probably nicer for authors in theory, had too many edge cases to make it reasonable. 50935 18 bzbarsky 2011-07-12 01:49:48 +0000 Thanks! 50936 19 jan.varga 2011-07-12 05:22:33 +0000 btw, what do you think about moving all those .command* attributes to an object and then add a new attribute .commandState (or some better name) ? 50971 20 ian 2011-07-13 18:25:59 +0000 What problem does it solve? (I've been generally avoiding having "helper objects" that have a 1:1 mapping with some other object unless they're a list.) 50972 21 ian 2011-07-13 18:26:29 +0000 (Please file a separate bug for it if you want to discuss that further; I don't see comments added to closed bugs.) 53459 22 mike 2011-08-04 05:14:03 +0000 mass-move component to LC1