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

Re: Proposal for limited :matches pseudoclass

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 14 Jan 2009 10:29:31 -0600
Message-ID: <dd0fbad0901140829y1e374ef4xd8b5347505a0e36d@mail.gmail.com>
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.

Received on Wednesday, 14 January 2009 16:42:53 UTC

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