W3C home > Mailing lists > Public > www-style@w3.org > January 2009

Re: Proposal for limited :matches pseudoclass

From: Giovanni Campagna <scampa.giovanni@gmail.com>
Date: Wed, 14 Jan 2009 17:55:18 +0100
Message-ID: <65307430901140855i7912ab97o5f2b4dd35c2e95f3@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style@w3.org
Well, "a > b < c d < e" means an element "e" that is parent of "d",
descendant of "c", parent of "b", child of "a"
because b should be child of "a" and "c" at the same time, this doesn't
match anything, but it is not difficult to read, if you read starting from
the last token (as you do with current selectors)
If you written "a b < c d < e", that means "e" parent of "d", descendant of
"c", parent of "b", descendant of "a", actually matches an element in the
following tree

   any element
        any element
           E <-- this is matched

This may be solved as well with classes instead of complex tree navigation,
but it may be necessary where classes are not available (eg. pure XML).

Furthermore, I'm not personally against a :matches pseudoclass (in addition
of # placeholder) just I expected it to be "element matches selector
contained in pseudoclass", not just element is "parent or sibling", and this
can be very expensive at computation time (at least linear on number of
element matching the selector without pseudoclass), while instead <, <<, -
and -- can be optimized
Frex, I expect that in selector "myancestor #my-id", first UA gets #my-id
(only one element, found from ID map), then finds a myancestor some where in
the tree, without travelling all the DOM: this means that fast ways to get
from child to parent - ancestor. For siblings, the concept is similar: UAs
already optimized +, I don't think it is much of runtime expense to use the
same patterns but to select a different element.


2009/1/14 Tab Atkins Jr. <jackalmage@gmail.com>

> On Wed, Jan 14, 2009 at 7:35 AM, Giovanni Campagna
> <scampa.giovanni@gmail.com> wrote:
> > Uhm...
> >
> > the difference between "td > input:checked" and "td:matches(>
> > input:checked)" is the subject of the selector (the element that gets the
> > CSS applied), but instead of a :matches pseudoclass, if what about parent
> > selector (as opposite of child selector)
> > that is:
> > "td > input:checked" matches a checked input that is child of a td
> > "input:checked < td" matches a td that is parent of a checked input
> >
> > Advantages:
> > - the child is always "less-than" the parent: it is easier to understand
> (to
> > me at least)
> > - the matched element is always the last in the selector
> > - we don't need a new pseudoclass (what about if we need a "matches"
> > pseudoclass in CSS4 for matching a RegExp? Less keywords mean forward
> > compatibility)
> >
> > Disadvantages:
> > - I don't know what are counterparts of descendant and siblings selectors
> The lack of any appropriate opposites for any other combinator is a
> decent drawback, I think (though it could certainly be done, perhaps
> with << for general ancestor, and - and -- for previous adjacent
> sibling and previous general sibling, respectively).
> More importantly, though, I feel this allows you to get some very
> confusing combinators when you start moving up and down the tree.
> Frex, "a > b < c d < e" would be possible, but I severely doubt it
> would be easy to understand.
> ~TJ
Received on Wednesday, 14 January 2009 17:06:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:23 UTC