Re: CSS pseudo-selector :closest and :further

I ran into very similar use cases a few month ago.

The case of :closest is a weaker version of the filtered combinator 
proposal https://lists.w3.org/Archives/Public/www-style/2014Oct/0210.html

For example:
     .button-group .text:closest​
is really:
     .button-group >>(:not(.text)) .text


The problems with :nested and :further are the same as :has(): you have 
to know about the entire subtree to decide anything.


On 3/18/15 11:10 AM, Marat Tanalin wrote:
> 18.03.2015, 20:23, "David Rodrigues" <david.proweb@gmail.com>:
>> will be great if create a new pseudo-selector definition that allow
>> select closest or further element from a base element.
>
> I like the idea in general. It would also make sense to have a complementary selector to select elements at a specific tree-level between the closest descendant and the distant (further) descendant elements, e.g.:
>
>      .example:nested(2)
>
> would match elements that have the `example` class and are 2 levels deep from the base element:
>
>      <div class="example"><!-- This does not match. -->
>          <div class="example"><!-- This does match. -->
>              ...
>          </div>
>      </div>
>
> As for naming, `closest` idiom is indeed already used for selecting parent/ancestor element in JavaScript. We could use the same function for all three cases:
>
>      .example:nested(first) -- selects first (closest in your originally proposed terms) descendant having the class.
>
>      .example:nested(last) -- selects last (further in your originally proposed terms) descendant having the class.
>
>      .example:nested(2) -- selects second-level descendant having the class.
>
> It may also be more flexible to use entirely another approach: a functional notation that could allow to use more complex selectors to match desired elements, e.g.:
>
>      ::nested(first, UL > LI.example.foo#bar)
>
> would match `LI` elements which are children of an `UL` element and have `example` and `foo` classes and the `bar` id.
>

Received on Wednesday, 18 March 2015 20:02:46 UTC