1820835 - Matching for :has() relative selectors

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, enhancement)

Comment 1

[David Shin[:dshin]]

Attachment: Bug 1820835: `:has` relative selector matching, with no caching/filtering. r=emilio,#layout-reviewers

Comment 2

[David Shin[:dshin]]

Attachment: Bug 1820835: Part 2 - `:has` matching - don't let relative selector matching escape its nested context. r=emilio,#layout-reviewers

e.g. Given ':has( .b .c)', and '.a .b .c', if we try to run the match on .b, we
can terminate the right-to-left match early when the next element to match is .a.
We need to skip only at the exact nesting level since the escape in the further
nesting (e.g. ':has(:is(.a .b .c))') is valid.

Depends on D172019

Comment 3

[David Shin[:dshin]]

Attachment: Bug 1820835: Part 3 - Skip matching the anchor element on relative selector with descendant combinator. r=emilio,#layout-reviewers

As long as the relative selector matching does not escape the boundary defined
by the relative selector anchor element, it's trivially true that the match
is the descendant of the anchor element.

Depends on D172020

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/655f5564fd2a
`:has` relative selector matching, with no caching/filtering. r=emilio

Comment 5

[Bill Goldstein [:aja] (UTC-6)]

Mixed results here... label and textarea is okay, but label and input fails (except for general sibling). so maybe problem with void elements?

Comment 6

[Bill Goldstein [:aja] (UTC-6)]

Attachment: has.html

What I tested with

Comment 7

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/655f5564fd2a

Comment 8

[David Shin[:dshin]]

Of note, as :aja's testcase demonstrates: There are issues with style sharing cache (bug 1793012) that causes correctness issues.