- From: Giovanni Campagna <scampa.giovanni@gmail.com>
- Date: Wed, 14 Jan 2009 17:55:18 +0100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style@w3.org
- Message-ID: <65307430901140855i7912ab97o5f2b4dd35c2e95f3@mail.gmail.com>
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 A any element C B any element E <-- this is matched D 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. Giovanni 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