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

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: [] On Behalf Of fantasai
Sent: Tuesday, March 11, 2008 1:41 PM
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.

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
   <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
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?


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