W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > August 2011

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

From: <bugzilla@jessica.w3.org>
Date: Mon, 01 Aug 2011 20:18:00 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Qnyw4-0007EN-LD@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13401

--- Comment #6 from Jan Varga <jan.varga@gmail.com> 2011-08-01 20:17:59 UTC ---
(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

-- 
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 Monday, 1 August 2011 20:18:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:15 UTC