Last Comment Bug 75872 - [CSS]bad matching in [attr |= value] selectors if value contains a dash
: [CSS]bad matching in [attr |= value] selectors if value contains a dash
[css] fixed by 83616
: css2, intl, testcase
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
P2 normal (vote)
: ---
Assigned To: Daniel Glazman (:glazou)
: Hixie (not reading bugmail)
: Jet Villegas (:jet)
Depends on: 83616
  Show dependency treegraph
Reported: 2001-04-13 02:55 PDT by Daniel Glazman (:glazou)
Modified: 2014-04-26 03:08 PDT (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

test case showing bug (775 bytes, text/html)
2001-04-13 03:01 PDT, Daniel Glazman (:glazou)
no flags Details
patch for 75872 (1.76 KB, patch)
2001-04-19 05:41 PDT, Daniel Glazman (:glazou)
no flags Details | Diff | Splinter Review
test case ; all paragraph must be green with a correct implementation (1.86 KB, text/html)
2001-05-11 05:18 PDT, Daniel Glazman (:glazou)
no flags Details

Description User image Daniel Glazman (:glazou) 2001-04-13 02:55:32 PDT
Attribute dash-separated value selector has incorrect answer if the tested value
contains a dash. Test case attached.
Comment 1 User image Daniel Glazman (:glazou) 2001-04-13 03:01:48 PDT
Created attachment 30736 [details]
test case showing bug
Comment 2 User image Daniel Glazman (:glazou) 2001-04-19 05:41:34 PDT
Created attachment 31432 [details] [diff] [review]
patch for 75872
Comment 3 User image Daniel Glazman (:glazou) 2001-04-19 05:44:43 PDT
Proposing patch for this bug. Test case attached to this bug becomes green.
Ian, can you please torture it a little bit ? I think it is ok because I have
other css3 selectors tests that go green but...

Pierre : since vietnamese motorbikes don't have internet access, can you
         r= before your sabbatical ?-) [just kidding, lucky man]
Marc : sr= ?

Comment 4 User image Daniel Glazman (:glazou) 2001-04-19 05:47:26 PDT
bug ==>
Comment 5 User image Marc Attinasi 2001-04-19 10:16:57 PDT
I approve! sr=attinasi
- Thanks Daniel
Comment 6 User image Pierre Saslawsky 2001-04-20 18:18:40 PDT
Space characters are not handled with homogeneity:
   <p lang = "en-us">         matches        *[lang |= "en-us"]
   <p lang = " en-us">        matches        *[lang |= "en-us"]
   <p lang = "en-us ">        doesn't match  *[lang |= "en-us"]

Also, with:
    *[lang |= "en-us"]        matching works as described above
    *[lang |= " en-us"]       nothing matches
    *[lang |= "en-us "]       nothing matches

I don't know what the spec says about leading and trailing spaces.  I think both 
should be ignored.

Otherwise, r=pierre.
Comment 7 User image Daniel Glazman (:glazou) 2001-05-02 00:58:17 PDT
Good catch, thanks Pierre. Investigating. If I find no answer, I will push this
issue to the CSS WG.
Btw, setting milestone for 0.9.1.
Comment 8 User image Hixie (not reading bugmail) 2001-05-11 01:34:12 PDT
# User agents MAY ignore leading and trailing white space in CDATA attribute 
# values (e.g., "   myval   " MAY be interpreted as "myval"). Authors SHOULD 
# NOT declare attribute values with leading or trailing white space.

We SHOULD NOT ignore trailing spaces in the CSS attributes.

In other words... what Pierre describes is, technically, correct, although I 
would recommend trim()ing the value of the attribute before doing the comparison
(not in the DOM, of course).
Comment 9 User image Hixie (not reading bugmail) 2001-05-11 01:39:23 PDT
DOH! I mean "CSS selectors" not "CSS attributes".

As in, [attr|="x     "] should match <el attr="x     -"/>.

You might want to do the test twice, once without the trim, and if it doesn't
match, then trim it, and try again (if there was anything to trim -- does trim()
tell you if it trimmed anything?).
Comment 10 User image Daniel Glazman (:glazou) 2001-05-11 05:18:48 PDT
Created attachment 34063 [details]
test case ; all paragraph must be green with a correct implementation
Comment 11 User image Daniel Glazman (:glazou) 2001-05-11 05:39:46 PDT
Ian: I think I have found a difficult case...
Given your comments above, the selector

  [attr|=" e"]

should match

  attr="      e "
             you find here the selected value

right ?...

I think that the only way to solve this problem is Pierre's proposal : trim
the attribute's value *and* the selected value in selector.

Anyway, this bug needs more discussion between us, and perhaps an escalation to
the CSS WG, and we are friday afternoon, just a few hours before the freeze.
==> marking 0.9.2.
Comment 12 User image Hixie (not reading bugmail) 2001-05-12 22:10:10 PDT
No, in my opinion

 [attr|=" e"]

should NOT match

  attr="      e "

...because either you completely trim the value, or you don't, you don't do 
bits. I see absolutely no advantage to matching in the above case.

(BTW, the freeze was for major landings, not any bug fix.)
Comment 13 User image Daniel Glazman (:glazou) 2001-05-14 01:34:18 PDT
Ian, I think that this won't be clear from a CSS author's perspective and I
recommend bringing this issue to the CSS WG.

Marc, David, what do you think ?
Comment 14 User image Hixie (not reading bugmail) 2001-05-15 15:57:05 PDT
Daniel: Why isn't it clear? Authors will very quickly learn to not include 
spaces in their dash match attribute selectors... I look forward to replying to
your post in w3c-css-wg. :-)
Comment 15 User image Daniel Glazman (:glazou) 2001-05-28 01:22:38 PDT
Decision from CSS Working Group : you never trim white space on the CSS side.
White space in attribute values is trimmed during parsing of the XML.
The match is an exact match.

Back to implementation.
Comment 16 User image Hixie (not reading bugmail) 2001-05-28 22:45:21 PDT
...which is basically what I said... :-)
Comment 17 User image David Baron :dbaron: ⌚️UTC-8 2001-06-20 11:09:07 PDT
This should be fixed with my checkin for bug 83616.
Comment 18 User image rubydoo123 2001-06-29 17:05:27 PDT
Ian, can you test if this is indeed fixed with David's checkin for bug 83616?
Comment 19 User image basic 2001-07-08 20:41:49 PDT
attachment 30736 [details] works for me in build 2001070108 win32
attachment 34063 [details] is invalid
marking resolve fixed, Hixie: can you confirm?
Comment 20 User image Madhur Bhatia 2003-02-21 14:48:10 PST
looking at testcase attachment 34063 [details], I still see the bug 

following is the style provided
<style type="text/css">
  p { color : red }
  p[lang|="a     "] { color : green }
  p[lang|="b"] { color : green }
  p[lang|="c"] { color : green }
  p[lang|="  d   "] { color : green }
  p[lang|="  en"] { color : green }
  p[lang|="fr"] { color : green }

  p.false { color : green }
  p[lang|="f"] { color : red } {color : green }
  p[lang|=" nl"] { color : red } {color : green }
  p[lang|="se "] { color : red }

the following praragraph text is displayed in 'red'
<p lang=" b">This paragraph should be green.</p>
<p lang="c ">This paragraph should be green.</p>
<p lang="  fr-ca  ">Ce paragraphe doit être vert.
     (<span lang="en" style="font-style:italic">This paragraph should be

re-opening  bug 
Comment 21 User image Boris Zbarsky [:bz] (still a bit busy) 2003-05-03 22:38:52 PDT
Madhur, see comment 19.

Resolving fixed again per comment 17.

Note You need to log in before you can comment on or make changes to this bug.