I removed it in 14f5ce7108 because I
thought it was unnecessary, but it wasn't. When we build a tree like
this:
.matches ─┬─ .doesntmatch
└─ .alsodoesntmatch
We would get the changes for the .matches part returned. This is however
only right if that node of the tree contains results. If results only
exist with the child nodes (all of which don't match), then this part
should not match either.
The new region selector tracks more than just one soimple selector, so
it requires some more advanced specificity tracking.
Technically, this is still not correct, because it will report the same
specificity for
tab:sorted
and
tab:sorted:sorted
(and the second selector will be printed as the first) but this is
regions, so meh.
This is just a way to handle regions more conveniently. What this does
is to change the descendant matcher into a maybe-descendant matcher
whenever the current object we're parsing might be a region. Because "*"
might also refer to a region and not just a new element.
See testsuite/reftests/css-match-region-matches-star.ui for a testcase.
When parsing a selector like
tab:active
We used to create 2 selector objects, one for the region, and one for
the pseudoclass. Now, for convenience, we special-case region
pseudoclass parsing so that the active flag is added to the region
selector.
A side effect is that ":nth-child(1)" no longer works for regions.
Hopefully people didn't use this but used the saner ":first-child"
instead.
:not() works for names, ids, classes and pseudoclasses based on states.
It does not yet work for positional pseudoclasses (like :last-child or
:even) as there is region madness going on with those.
We use the new g_type_get_type_registration_serial() so that we can
cache and properly invalidate the result of g_type_from_name().
This bumps the glib requirement to 2.35.3 to get the new function.
https://bugzilla.gnome.org/show_bug.cgi?id=689847
Rather than first collecting matches and then getting the change
for them we do the change collection directly on the tree. This
is about twice as fast.
We add some "artificial" ordering to the otherwise unordered
tree nodes. This means the tree will be the same every time for the
same input. This is good because e.g. tree order affects the
reordering of the simple selectors, which may affect how
css providers are printed, which need to be consistent for
the css tests to work.
When building the tree we generally reorder the selectors inside
the same simple selector in order to pick a good first selector
to balance the tree better. However, some kinds of selectors
can't really be reordered, even thought they are simple.
This is since the matching code for some types handle
the existance of a directly preceeding selector differently:
REGION and ANY selectors look for a DESCENDANT previous
POSITION selector look for a REGION previous
From a set of GtkCssSelectors and the rulesets they match to
we create a large decision tree that lets us efficitently match
against all the rules and return the set of matched rulesets.
The tree is created such that at each level we pick the initial rule[1]
in all the considered selectors for that level and use put the
one that is in most selectors in the node. All selectors matching that
are put in the previous part of the tree.
