This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently command.checked changes also content attribute checked. input.checked changes only the state (checkedness) and the checked content attribute sets only the initial state. The activation behavior of <command> is also incorrect, it should just match what is specified for <input> (radio and checkbox state) Is there a reason to not use the checkedness and dirty checkedness flag for command elements ? HTMLCommandElement could then contain the .defaultChecked IDL attribute.
<input>'s handling of check state is somewhat obtuse, I'm not sure we want to match it exactly. But maybe it's worth it for consistency?
yeah, (In reply to comment #1) > But maybe it's worth it for consistency? yeah, there are only two .checked IDL attributes one for <input> and one for <command>, so it makes sense to make them behave consistently activation behavior must be rewritten anyway actually it might be possible to just say that it behaves like <input> we have it all implemented and reviewed and we are waiting only for your opinion before pushing it to mozilla-central
(In reply to comment #1) > <input>'s handling of check state is somewhat obtuse, I'm not sure we want to > match it exactly. But maybe it's worth it for consistency? Exactly, for consistency. If the command.checked handling is like input.checked handling, the same scripts can be used to handle those. It would be rather weird to have another checkbox-like API, which looks like input elements API, but works in this essential case in a very different way.
I agree that consistency is important. The question is whether the win of having a consistent API outweighs the loss of having a lame API. I'll have to study the API in question more closely to work out whether it's worth it or if the existing API is just too bad to bother being consistent with it. cc'ing sicking who has in the past spoken out quite emphatically about the badness of <input>'s checkedness API.
I don't have so much of a problem with the .checked attribute (it always reflecting the actual checked state of the checkbox makes a lot of sense to me), but rather to the fact that the DOM-attribute doesn't track the state of the checkbox. However that seems too late to change at this point. I still haven't fully understood the <command> API, so I don't have a strong opinion on it. Other than that <menuitem> seems like a more intuitive name for menu items, and <button> seems like a more intuitive name for toolbar buttons.
(In reply to comment #5) > I don't have so much of a problem with the .checked attribute (it always > reflecting the actual checked state of the checkbox makes a lot of sense to > me), but rather to the fact that the DOM-attribute doesn't track the state of > the checkbox. However that seems too late to change at this point. > so, if I understood it correctly you would prefer the DOM-attribute checked to reflect the state of both elements - <input> and <command> however, if we can't change the behavior of <input> which uses the DOM attribute to set only the initial state then <command> should work the same way, right ? > I still haven't fully understood the <command> API, so I don't have a strong > opinion on it. Other than that <menuitem> seems like a more intuitive name for > menu items, and <button> seems like a more intuitive name for toolbar buttons. yeah, I think <command> could be defined only in the head and <menu> would contain only a reference to it <head> <command id="edit-command"> </head> <menu> <menuitem command="edit-command"> </menu> there's a discussion about command="" at: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-April/011048.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-July/015434.html
mass-moved component to LC1
I think it makes sense to leave <command> with just its simple checked/.checked behaviour rather than introducing .defaultChecked — in fact I'm not really sure it makes sense to have a defaultChecked for commands, since they can't be reset anyway. However, I do need to fix the activation behaviour. What is currently called the "activation behavior" needs to be changed to be the "pre-click activation steps", and new "canceled activation steps" need to be introduced to reset checked back to the previous state. The "activation behavior" then needs to be changed to be to do nothing.
defaultChecked could be there just to reflect the checked content attribute. But I don't care too much whether or not we should have it.
I agree that command.checked is wrong as it is now, but I disagree with the proposed remedy. I think the checked'ness of a command should purely be a output status thing. I.e. activating the command would not automatically flip the checkbox. It's going to be very common to have several ways of activating commands, for example through menu items, toolbar buttons and keyboard shortcuts. All three will likely want to feed into the same status-updating function in the JS code. That function will need to update the checkedness-state of the menuitem when the function comes from all non-menuitem code paths. So it might as well update it all the time, including when activated using the menuitem itself. As things stand now, the developer has to worry about cancelling the default action in case he'll be calling into a generic codepath. Especially if the codepath needs to sometimes not change the state, for example if you are only allowed to uncheck an item in certain conditions. Additionally, if the code that handles the menuitem click sometimes fails and throws an exception, for example due to exceptional circumstances like network errors, out of database space or simply bugs, then as things stand now we still flip the checkbox, whereas if that had to be done manually, this would be somewhat more likely to be handled more correctly. To put it another way: I don't see a sane way under the currently defined behavior, or the proposed behavior, to handle the situation when the function underlying a command can be triggered through multiple means in addition to the menuitem.
(In reply to comment #10) > but I disagree with the > proposed remedy. I strongly disagree having another "checkbox API" which looks like the current <input type="checkbox">, but works in a very different way. > > It's going to be very common to have several ways of activating commands, for > example through menu items, toolbar buttons and keyboard shortcuts. All three > will likely want to feed into the same status-updating function in the JS code. Right. That is why we should add support for <menuitem command="somecommand"> which will synchronize the state. > Additionally, if the code that handles the menuitem click sometimes fails and > throws an exception, for example due to exceptional circumstances like network > errors, out of database space or simply bugs, Those all are bugs which should be handled in the web app.
(In reply to comment #11) > (In reply to comment #10) > > but I disagree with the > > proposed remedy. > I strongly disagree having another "checkbox API" which looks like > the current <input type="checkbox">, but works in a very different way. I don't think that a menu item with a checkbox looks anything like a <input type=checkbox>. In fact, I think they are distinct enough that ideally we shouldn't even use "type=checkbox" for menu items. They neither look the same way visuall, nor act the same way when you click on them. Additionally the actual check marks generally look differently. If I look in my firefox menu right now (On Mac OSX), I see only a single menu item with a check mark next to it. It's in the "Window" menu and signifies which of all my firefox windows I currently have focused. If I click it it doesn't uncheck the check mark. If I click another item in the menu it also doesn't behave like a checkbox since it unchecks the item currently checked. In other words, it acts much more like a radio box than a checkbox. Except that it's rendered with a check mark rather than the bullet point which usually signifies radios. > > It's going to be very common to have several ways of activating commands, > > for example through menu items, toolbar buttons and keyboard shortcuts. All > > three will likely want to feed into the same status-updating function in > > the JS code. > Right. That is why we should add support for <menuitem command="somecommand"> > which > will synchronize the state. And that will make the check mark next to a menu item act even less like a <input type=checkbox> > > Additionally, if the code that handles the menuitem click sometimes fails > > and throws an exception, for example due to exceptional circumstances like > > network errors, out of database space or simply bugs, > Those all are bugs which should be handled in the web app. Indeed. But we should make the platform easy to develop for when we can.
(In reply to comment #12) > If I look in my firefox menu right now (On Mac OSX), I see only a single menu > item with a check mark next to it. It's in the "Window" menu and signifies > which of all my firefox windows I currently have focused. If I click it it > doesn't uncheck the check mark. If I click another item in the menu it also > doesn't behave like a checkbox since it unchecks the item currently checked. In > other words, it acts much more like a radio box than a checkbox. Except that > it's rendered with a check mark rather than the bullet point which usually > signifies radios. If I look at the view->toolbars menu (Firefox/linux), it has several checkboxes, which indicate whether some toolbar is visible. Clicking a checkbox changes the state. That is the most common case for checkbox-like menu items I've seen.
sicking: The idea is that you would point all the places that affect the checkbox at the same command, so that the buttons, keyboard shortcuts, etc, all end up driven by the same underlying checkbox logic, and the author doesn't have to worry about it. (This isn't yet in the spec, admittedly.) The behaviour you describe for the Window menu is a radio button menu item, not a checkbox. For checkboxes, I could maybe see an argument for letting authors check and uncheck things. For radio buttons, though, that's just a pain. Surely you agree that radio buttons should be automatic? I've fixed the definition of the activation behaviour (so it doesn't fire a second click event, d'oh). It is still unlike the <input> element in that the .checked value isn't changed until after the click event has fired (and not been canceled), though. 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: Partially Accepted Change Description: see diff given below Rationale: see above