Closed
Bug 24031
Opened 25 years ago
Closed 25 years ago
child and sibling combinators shouldn't have greedy matching
Categories
(Core :: CSS Parsing and Computation, defect, P3)
Tracking
()
VERIFIED
FIXED
M16
People
(Reporter: ian, Assigned: dbaron)
References
()
Details
(Keywords: css2, Whiteboard: have fix)
Attachments
(1 file)
|
(deleted),
patch
|
Details | Diff | Splinter Review |
The following snippet:
<DIV class="test">
<DIV>
<P><SPAN> THIS TEXT SHOULD HAVE GREEN BORDER </SPAN></P>
</DIV>
</DIV>
...with the following style:
DIV.test > * SPAN { border: thick solid lime; }
...doesn't result in the SPAN having a thick lime border.
Test case:
http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/child-selector.html
Virtually any change to the rule will result in a working rule, as can be seen
at the bottom of the test page quoted.
David: Do you know about this bug? Is it a dup?
See also bug 15608.
|
||
Comment 1•25 years ago
|
||
The problem seems more serious than described in the testcase. Apparently the
child selector ('>') doesn't work at all. If you remove them all from the
testcase snippets, it works all the same. Bummer.
|
Assignee | |
Comment 2•25 years ago
|
||
Child selectors still work in most cases:
http://www.people.fas.harvard.edu/~dbaron/css/test/childsel
|
|
||
Comment 3•25 years ago
|
||
A mail I received today from hyatt, addressed to pavlov and raph@acm.org, and
which describes a similar problem:
----
I think it should be red. The two rules have the same weight, origin, and
specificity, and this means that the latter rule should be matched (according to
6.4.1 of the CSS2 spec., http://www.w3.org/TR/REC-CSS2/cascade.html#specificity).
This looks like a bug in Mozilla. Pierre would be the one to get this bug,
assuming
I'm right. cc'ing him.
Dave
(hyatt@netscape.com)
Stuart Parmenter wrote:
>
>
> ------------------------------------------------------------------------
>
> Subject: CSS nondeterministic matching
> Date: Tue, 22 Feb 2000 23:54:00 -0800
> From: Raph Levien <raph@onan.artofcode.com>
> To: pavlov@netscape.com
> CC: raph@acm.org
>
> Hi Pavlov,
>
> I understand you'll forward this to the relevant CSS people within
> Mozilla.
>
> I've just been reading through Mozilla's CSS implementation in:
>
> http://lxr.mozilla.org/seamonkey/source/layout/html/style/src/nsCSSStyleSheet.cpp
>
> I find myself confused about the difference between true
> nondeterministic and greedy matching. It seems to me that the CSS spec
> calls for the former, while Mozilla implements the latter.
>
> Here's an example that should illustrate the difference (also at
> http://www.levien.com for your viewing pleasure):
>
> <html><title>CSS test</title>
> <body>
> <style type="text/css">
> <!--
> BLOCKQUOTE BLOCKQUOTE BLOCKQUOTE { color: blue }
> DIV > BLOCKQUOTE BLOCKQUOTE { color: red }
> P { color: green }
> -->
> </style>
> <div>
> <blockquote>
> 1. black in amaya
> </blockquote>
> <blockquote>
> <blockquote>
> 2. red in amaya
> </blockquote>
> </blockquote>
> <blockquote>
> <blockquote>
> <blockquote>
> 3. red in amaya
> </blockquote>
> </blockquote>
> </blockquote>
> <p> 4. green in amaya </p>
> </div>
> </body>
> </html>
>
> It seems to me that (3) should be red, as the innermost BLOCKQUOTE
> does have a BLOCKQUOTE with a DIV parent as an ancestor. However, it
> also seems to me that Mozilla won't match, because it does the tree
> selection greedily. I.e., the BLOCKQUOTE simple selector right after
> the ">" matches the middle BLOCKQUOTE tag, and gets used up. It then
> tries to match the DIV simple selector against the outermost BLOCKQUOTE
> tag, which fails.
>
> I've confirmed that Mozilla has (1) black (2) red (3) blue and (4)
> green, while Amaya has the results I'd expect from the CSS spec.
>
> Am I understanding this correctly? I'm currently implementing my
> own CSS for SVG work, with an emphasis on performance and W3C
> compliance, and want to make sure to get this right.
>
> Raph
|
|
||
Comment 4•25 years ago
|
||
See http://www.levien.com/css-test.html for the testcase above
|
|
Assignee | |
Comment 6•25 years ago
|
||
That looks like the same bug, and it means this is a rather serious problem.
Hopefully it can be fixed easily without hurting performance.
Are there cases where this would happen with adjacent sibling selectors (or
others?), or are child selectors the only place where this can cause problems?
I should add tests to my tests to check this problem...
|
||
Comment 7•25 years ago
|
||
Taking over 1/3 of Pierre's NEW bugs to help reduce his doomage factor
Assignee: pierre → attinasi
|
|
||
Comment 8•25 years ago
|
||
Reassigned back to me these bugs that shouldn't have left my list.
Assignee: attinasi → pierre
|
|
Assignee | |
Updated•25 years ago
|
Summary: "DIV.test > * SPAN" not matching when "DIV.test > * > * SPAN" does! → child selectors shouldn't have greedy matching
|
|
Assignee | |
Comment 9•25 years ago
|
||
This problem also occurs with adjacent sibling combinators. I just added a test
for it at the end of http://www.people.fas.harvard.edu/~dbaron/css/test/sibsel .
I'm looking at the code right now to see if I can fix this. It might be easy...
Summary: child selectors shouldn't have greedy matching → child and sibling combinators shouldn't have greedy matching
|
|
Assignee | |
Comment 10•25 years ago
|
||
Stealing this bug, since I have a fix for it.
I've tested this fix on:
* my selector tests
* the CSS1 and CSS2 (in progress) test suites
Ian, do you have any selector tests I should look at?
I'll attach the fix to this bug in a few minutes. Pierre - could you take a
close look at the fix? Please be as critical of it as possible, since this is
code that gets executed a lot. What other tests should I run? If you think
it's good, I could probably check it in sometime. However, I should probably do
a little profiling first to make sure it hasn't affected performance...
Assignee: pierre → dbaron
Whiteboard: have fix
Target Milestone: --- → M16
|
|
Assignee | |
Comment 11•25 years ago
|
||
|
Reporter | |
Comment 12•25 years ago
|
||
David: Only the one mentioned in this bug, I'm afraid.
http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/child-selector.html
|
|
Assignee | |
Comment 13•25 years ago
|
||
I think the performance problem I mention in the patch is actually not an issue,
because generally selectors don't match. If there were a selector that matched
almost everything in the document, it would likely have simple selectors
matching nodes near the top of the tree, so this approach might even be
better...
|
|
Assignee | |
Comment 14•25 years ago
|
||
Fix checked in 2000-04-21 17:47 PDT.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
|
|
Reporter | |
Comment 15•24 years ago
|
||
As per meeting with ChrisD yesterday, taking QA.
VERIFIED FIXED on Win2K with commerical build 2000072520. My testcase
now displays correctly, David's testcase still displays fine.
Status: RESOLVED → VERIFIED
QA Contact: chrisd → py8ieh=bugzilla
You need to log in
before you can comment on or make changes to this bug.
Description
•