- From: <bugzilla@jessica.w3.org>
- Date: Fri, 24 Jun 2011 22:07:19 +0000
- To: public-script-coord@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12845 --- Comment #30 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-06-24 22:07:16 UTC --- (In reply to comment #28) > > Or maybe better would be to not use generic names for the command API that then > lead to collisions? The idea is specifically to reuse the attributes that already exist with the semantics we want, rather than introducing a whole new set of properties that replicate existing ones. > It's not like you can prevent people tabbing to <textarea> anyway! Tabbing to textarea isn't the problem. The only way textarea is a "problem" is that you can set an accesskey for it, which then makes it a command; you can then disable it, but the command won't be disabled because accesskey commands are never disabled, but the <textarea> itself will be disabled, so textarea.disabled will claim the command is disabled even though it isn't. The problem here isn't that the attribute is shadowed, the problem is that the command API doesn't honour the <textarea disabled> state. The way to solve that is to make it honour that state. But that's a separate bug (please file it if you care about it). Similarly with <track>, the problem is that it makes no sense for that to be a command, just like it makes no sense for it to be contenteditable="", tabindex=""ed, accesskey=""ed, or have many of the other global attributes applied to it. If we care about fixing _that_, I can make the spec explicitly list all the elements on which these interactive attributes can be set. But that's a separate bug as well (please file it if you care about it). (In reply to comment #29) > > If we are in the state that calling the superclass function would violate some > invariants because the specification assumes that it cannot be called on the > object, then that really would be a problem. I don't think that's the case, > though. I don't think it's the case either. However, I never intended for there to be two copies of these attributes. I'd like a way whereby I can just redefine the attribute on the subclass, e.g. to change it so that it is not readonly. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Friday, 24 June 2011 22:07:20 UTC