- From: Anton Prowse <prowse@moonhenge.net>
- Date: Sun, 15 Mar 2009 19:35:06 +0100
- To: "www-style@w3.org" <www-style@w3.org>
Boris Zbarsky wrote: > Anton Prowse wrote: >> # [att~=val] Represents an element with the att attribute whose > ... >> Issue 1: Intuitively one might expect that if "val" were the empty >> string it would represent an element with the att attribute whose value >> is the empty string, rather than fail to represent anything. (HTML5 >> currently proposes that <img>, <img alt=""> and <img alt="bar"> have >> different semantics, for example, and so there is a use case for such >> matching.) > > This use case is met by, respectively: > > img:not([alt]) > img[alt=""] > img[alt]:not([alt=""]) > > and changing the behavior of [att~=val] wouldn't change anything in > terms of making life simpler for authors here, as far as I can see. > > Note the long discussion about this earlier on this list; I think it's > been more or less discussed to death, with the WG changing and > re-changing its decision several times. Sure; I wasn't actually proposing a change to the behaviour, just pointing out that the spec didn't match my intuition on reading (which was backed up by an easily-conceived use case). I'm a great believer in explanatory text when something in an otherwise-intuitive spec goes against intuition, so I guess I'd like to see a note somewhere explaining, exactly as you did, that the use case is met in other ways. Cheers, Anton Prowse http://dev.moonhenge.net
Received on Sunday, 15 March 2009 18:36:01 UTC