RE: [CSS21] [css3-selectors] attribute selectors

Points:
1. Agree
2. Agree
3. I don't think an empty string should throw out the rule and result in error recovery. I'm completely happy having a no-op rule that can't match. There are lots of ways to create no-op rules. If you fail ~="", then why not fail ~=" " or even ~="  " (note two spaces ;-).

Justin Rogers [MSFT]

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of fantasai
Sent: Tuesday, March 11, 2008 1:41 PM
To: www-style@w3.org
Subject: [CSS21] [css3-selectors] attribute selectors


A comment from David Baron prompted me to look into this a little more closely,
particularly to check the CSS2.1 spec.

http://www.w3.org/TR/CSS21/selector.html#attribute-selectors
http://www.w3.org/TR/css3-selectors/#attribute-selectors

For [att~=val] CSS2.1 says
   # If this selector is used, the words in the value must not contain spaces
   # (since they are separated by spaces).
which implies that
   [att~="x x"]
is invalid. However the Selectors spec says
   # If "val" contains whitespace, it will never represent anything (since the
   # words are separated by spaces).
which implies that
   [att~="x x"]
is valid but simply doesn't match anything.

One of these specs needs to change. I suggest adopting the CSS3 wording for CSS2.


For [att|=val] CSS2.1 says
   # Match when the element's "att" attribute value is a hyphen-separated list
   # of "words", beginning with "val".
which implies that
   [lang|=e]
matches
   <p lang="en">
However the Selectors spec says
   # Represents an element with the att attribute, its value either being exactly
   # "val" or beginning with "val" immediately followed by "-" (U+002D).
which requires that it doesn't.

I recommend adopting the CSS3 wording for CSS2.


Finally, wrt the resolution in
   http://lists.w3.org/Archives/Public/www-style/2008Feb/0331.html
about making empty string substring match selectors invalid, I'll note that
Firefox, Opera, and IE7 all treat [attr~=""] as valid but not matching anything
and Safari matches it against some values of attr. Are we sure we want to make
these invalid rather than specifying existing behavior?

~fantasai

Received on Tuesday, 11 March 2008 23:37:51 UTC