This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.)
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.
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
never mind, I was not aware of bug 12845
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....
(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.
(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.
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?
(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.
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".
(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
.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.
> 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...
Upon some further thought, I'd like to retract the escalation request and reopen the bug instead.
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.)
I think at this point the suggestion would be to make use of heycam's new "just declare a setter" feature here.
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.
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.
Thanks!
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) ?
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.)
(Please file a separate bug for it if you want to discuss that further; I don't see comments added to closed bugs.)
mass-move component to LC1