W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2011

[Bug 12845] Disallow shadowing attributes

From: <bugzilla@jessica.w3.org>
Date: Fri, 24 Jun 2011 22:07:19 +0000
To: public-script-coord@w3.org
Message-Id: <E1QaEX1-0006zo-Dl@jessica.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

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:03 UTC