- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 14 Jan 2009 10:29:31 -0600
- To: "Giovanni Campagna" <scampa.giovanni@gmail.com>
- Cc: fantasai <fantasai.lists@inkedblade.net>, www-style@w3.org
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 16:42:53 UTC