Re: Selecting an element combining nth-of-type() and a class/ID

2009/3/30 Tab Atkins Jr. <jackalmage@gmail.com>:
> On Mon, Mar 30, 2009 at 10:22 AM, Giovanni Campagna
> <scampa.giovanni@gmail.com> wrote:
>> 2009/3/30 Tab Atkins Jr. <jackalmage@gmail.com>:
>>> On Mon, Mar 30, 2009 at 8:07 AM, Charles <landemaine@gmail.com> wrote:
>>>> What if you want it to match another pseudo class with also an ID?
>>>> For instance: li:nth-match(2, :nth-last-of-type#today.new)
>>>> We need a similar flexibility...
>>>
>>> I'm not sure what that would match, even if you had the hypothetical
>>> ability to do that.  Can you give an example?
>>>
>>> ~TJ
>>>
>>>
>>
>> Theoretically, the :nth-match works as follows, in the following (invalid) tree.
>> <ul>
>> <p class="new">a</p>
>> <li class="new">b</li>
>> <li id="today">c</li>
>> <q>d</q>
>> <li class="new" id="today">e</li>
>> <p class="new" id="today">f</li>
>> <li class="new" id="today">g</li>
>> </ul>
>> 1) First take all direct childs that matches the second part of the
>> nth-match(), that is "#today.new:nth-last-of-type" (rewritten in
>> common order). This means:
>> 1.1) Take the elements with ID #today: "c", "e", "f" and "g".
>> 1.2) Take the subsets of those which have class .new: "e", "f" and "g".
>> 1.3) Take their element types: "li" and "p"
>> 1.4) Find which of them is the last in the set of elements with the
>> same type: we have "f" and "g". "e" is not, because it is followed by
>> another <li> (it doesn't matter if the latter <li> matches #today.new)
>> 1.5) The resulting list is then "f" and "g"
>> 2) Among the results of the first match, find which is number two: in
>> our case it is "g".
>> 3) Among the results of the step 2 (just one node), find those which
>> match "li": only "g"
>>
>> It is a li element that is the second element being the last of its
>> type and having class "new" and id "today".
>> If <q> (element "c") had class "new" and id "today", we would have had
>> no match from the selector.
>
> All right, that works.  I forget that CSS doesn't care about html's
> "ids must be unique in a document" restriction.
>
>> Anyway, I'm not sure what advantage you can get from such a complex selector.
>
> I don't think there's anything *wrong* with such a complex selector -
> it doesn't pose any conceptual problems.  You grab a bunch of <li>s,
> specialize the matched group by the provided selector, then select the
> 2nd one. But I wouldn't shed a tear if it wasn't allowed, either
> (however, defining that to be not allowed would likely be too complex,
> unless we went overboard and said that only simple selectors are
> allowed).
>
> ~TJ
>

I just meant: "the particular selector (not :nth-match in general) is
so complex I probably wouldn't use", because he threw in the middle
ids, classes, last-of-type, nth-match and types, all at the same time.
Anyway, we already have a lot of ways to select complex and completely
useless selectors like foo:not(bar), so this is not a problem.

Giovanni

Received on Monday, 30 March 2009 15:51:03 UTC