On Mon, 14 Aug 2006 16:21:55 -0700, Ian Hickson <[EMAIL PROTECTED]> wrote:
We'll do that too, but where's the harm in having this attribute? There's
zero requirements on UAs, it just allows authors to do more.
I actually was considering just saying that any attribute is allowed, but
that seemed more dangerous.
How is it different from allowing that? Besides of course that one will
"validate" and the other won't. (I agree that people using custom
attributes is painful when extending a specification. We noticed that when
implementing Web Forms 2.)
I've been using state="" a lot in XBL1+SVG documents. I use it for things
like where a switch has three states, and one of the elements in the
shadow tree needs to have those states. Then I key CSS off it, without
having to worry about the class attribute, which is used for separate
things (like UI state).
I see the point where you want to switch between different states for your
control, but I'm wondering if that's really the only thing you'd want to
extend it with. And also if it makes sense to just have an attribute for
that which takes arbitrary strings without any kind of abstraction. How
does that work for accessibility tools for example?
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
