W3C home > Mailing lists > Public > www-style@w3.org > March 2009

Re: [css3-selectors] New last call WD for Selectors

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sun, 15 Mar 2009 13:15:28 -0400
Message-ID: <49BD37B0.60306@mit.edu>
To: Anton Prowse <prowse@moonhenge.net>
CC: "www-style@w3.org" <www-style@w3.org>
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.

>   # Attribute values must be identifiers or strings.
> 
> Issue 2a:  The term "identifier" is undefined.  (Same issue exists in
> 6.3.2.)

Indeed; this should be defined as the IDENT token from the scanner 
(section 10.2).  Note that the grammar does so quite explicitly when 
defining the grammar for the attribute selectors (section 10.1).

> Issue 2b:  The term "string" string is undefined, but is presumed to be
> an identifier delimited by " marks.  What about ' and other marks?
> (Same issue exists in 6.3.2.)

It's defined in the scanner (section 10.2).

Perhaps the terminology section (1.2) should just explicitly say which 
of these terms refer to scanner tokens; that should help, no?

-Boris
Received on Sunday, 15 March 2009 17:16:16 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:17 GMT