W3C home > Mailing lists > Public > public-appformats@w3.org > August 2006

Re: [XBL2] state="" attribute

From: Anne van Kesteren <annevk@opera.com>
Date: Mon, 14 Aug 2006 21:44:42 -0700
To: "Ian Hickson" <ian@hixie.ch>
Cc: public-appformats@w3.org
Message-ID: <op.tea54sg864w2qv@id-c0020.globalsuite.net>

On Mon, 14 Aug 2006 16:21:55 -0700, Ian Hickson <ian@hixie.ch> 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
Received on Tuesday, 15 August 2006 04:45:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:05 UTC