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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 30 Mar 2009 10:36:17 -0500
Message-ID: <dd0fbad0903300836w5dcecc7es2310df27b77a7e65@mail.gmail.com>
To: Giovanni Campagna <scampa.giovanni@gmail.com>
Cc: "www-style@w3.org list" <www-style@w3.org>
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

Received on Monday, 30 March 2009 15:45:10 UTC

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