- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 15 Aug 2006 05:52:16 +0000 (UTC)
- To: Anne van Kesteren <annevk@opera.com>
- Cc: public-appformats@w3.org
On Mon, 14 Aug 2006, Anne van Kesteren wrote: > > 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.) The difference is the extensibility thing, yeah. > > 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? It's the main thing I've needed. I'm sure there are other things. We need people with XBL authoring experience to really say what they are. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 15 August 2006 05:52:31 UTC