- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 30 Mar 2009 10:36:17 -0500
- 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 allowed). ~TJ
Received on Monday, 30 March 2009 15:45:10 UTC