Re: proposal for a new css combinator

On Wed, Jan 13, 2010 at 6:02 AM, Niels Matthijs
<niels.matthijs@internetarchitects.be> wrote:
> I’m quite sure that someone before me must’ve thought about this, or maybe I
> just didn’t look closely enough at the latest specs, but I believe we are
> missing an important css combinator.
>
> For the full explanation you can check the following article:
> http://www.onderhond.com/blog/work/missing-css-combinator
>
> In short, I’d like something between the space and child combinator. A
> combinator that allows for an (x) number of levels between parent and child,
> but stops at the first matching level it hits.
>
> For example (assuming the % symbol would be used for the combinator):
> .box%header would match the header element of the .box component, but no
> other header elements of nested components inside the .box. The child
> combinator could be used, but adding a wrapping element (structural – div or
> functional – a or form) would break the css, which is not a good thing.
>
> This would allow us to style components in a flexible way without the
> trouble of breaking the css with wrapping elements and without css rules
> spilling over to nested components of a different kind.

Ah, so sort of like jQuery's closest() function, just in the opposite
direction.  Match the first such descendant, but not other elements in
the match's subtree.  "foo % bar > baz" would mean "find a baz which
is a child of a bar, with the bar having a foo ancestor but no other
bar ancestors between itself and the foo".

Sounds interesting and probably a useful generalization from the child
combinator.  I suspect that it would be okay implementation-wise -
you'd do a normal ancestor search just like you do with a descendant
combinator, but also checking for duplicates matching the second part
so you can invalidate the match.

It gets a little interesting when you have a structure like "a % b > c
d", where you need to find a d, then a c with a b parent, then verify
that there are no more b's between it and a.  If you *do* find another
b in the ancestor chain, it's still possible to match, but you'll have
to double-check its child to make sure it's a c.  All the information
you need to make this match is available at the time the selector
engine would try to match it, it just can potentially get a little
complex.

I would definitely use this combinator, though.  I've hacked around
the need for it by either structuring my HTML so that I know I can use
the child combinator, or by providing some further uniquifier to the
element so I can use a descendant combinator safely.  This would make
things slightly easier and more intuitive in some of these
circumstances.

~TJ

Received on Wednesday, 13 January 2010 14:01:00 UTC