[Bug 13401] Make command.checked behavior consistent with input.checked

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13401

--- Comment #10 from Jonas Sicking <jonas@sicking.cc> 2011-08-18 23:50:36 UTC ---
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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 18 August 2011 23:50:39 UTC