- 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
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 <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Tuesday, 15 August 2006 04:45:26 UTC