Re: [css3-selectors] The :nth-sibling combinator

First, a brief note on your subject: CSS3 Selectors is quite finished
by now (already at PR stage, implemented by most major browsers with
the last one, IE, catching up on previous of its next release), so
nothing's gonna change there beyond maybe some minor editorial fix
(such as typos, updating references to something that changes name or
location, etc).

However, there is already a wiki page at
http://wiki.csswg.org/spec/selectors4 that gathers ideas and
suggestions so they can be reviewed when the WG begins working on
Selectors 4, so I think it's a good idea to have some discussion on
this suggestion anyway (which may then be linked from the wiki, saving
some work to the WG when the time comes for them to formally consider
the suggestion).

Also, what you seem to be suggesting is a pseudo-class rather than a
combinator (whenever you see a single ":", you have a pseudo-class;
combinators are stuff that goes in between selectors, such as the
space and the characters '+', '>', or '~'). Using the right terms may
help you get your message across, which means less time wasted on
clarifications and more time spent on useful discussion ;-)

Now, with the bureaucracy and terminology dealt with, let me go to the
flesh and meat of your post:

On Thu, Jun 17, 2010 at 8:51 PM, Gabriele Romanato
<gabriele.romanato@gmail.com> wrote:
> I don't actually know if something like a :nth-sibling() combinator, whose
> syntax should resemble that of the other :nth selectors, is useful or
That's not a good start: if we don't know whether it would be useful
or not, why would implementers work on it instead of devoting those
efforts to something that's known to be useful or needed?
I do believe this could be useful, but it should be demonstrated with
clear use cases before it can be spec'ed: the spec should fulfill the
feature's requirements, and real requirements can only be derived from
real use-cases.

> feasible.
This has to be, on the worst case, very close in costs to the general
sibling combinator (~) which is already implemented by most browsers.
So I'd bet that it is indeed feasible.

> I stumbled on this problem while viewing a demo on scrollable
> tables that made a large use of something like the following:
>
> span + span + span {}
>
> Actually, this may be rewritten using a :nth-child() combinator.
Can it? If you have a markup like this:
<div>
   <span>...</span>
   <span>...</span>
   <span>...</span>
</div>
then either div>span+span+span or div>span:nth-child(3) would do.
However, what would happen if you had something like this?
<div>
   <span>...</span>
   <img ... alt="Now things are getting funnier!">
   <span>...</span>
</div>
Then we get a difference between what the selectors would match:
div>span+span+span matches nothing, while div>span:nth-child(3)
matches the <span> after the <img>.
Now, let's take things even crazier:
<div>
   <span>...</span>
   <span>...</span>
   <span>...</span>
   <span>Which selectors shall match this?</span>
</div>
Now the fun really begins: obviously, div>span:nth-child(3) will match
the 3rd <span>, but not the fourth. Less obviously, div>span+span+span
will match *both* the third and the fourth <span>s! (Did you expect
it?). As a matter of fact, it's possible to match it with
div>span:nth-child(3+1n) or something like that (sorry, I'm unsure now
about the exact syntax). To match only the third <span> with a
'+'-based selector, the simplest way I can think of would be
div>span:first-child+span+span

Here come a few questions for you to consider:
What should your suggested nth-sibling match on each of the above
cases? Try to think about a few more variations of the examples,
figure out what would the nth-sibling match and then try different
'+'-based and nth-child -based combinations to see if you can really
achieve the same matches with existing selectors.

If, for all uses of nth-sibling, an equivalent* selector can be
defined with existing selector technology, then the feature is
"sintax-sugar". Otherwise, it is "new functionality".
(* Two selectors are equivalent if, and only if, they match exactly
the same nodes for any arbitrary document tree.)
In the case of syntax-sugar, it's guaranteed that the functionality is
feasible: in fact, it's already implemented (another concern is how
does it interact with different selector-engine optimizations, but
that's a side topic). On the worst case, it could be transformed to
the equivalent upon loading the style-sheet. Whether a syntax-sugar is
worth including on a spec often boils down to balancing spec bloating
vs. style-sheet bloating: if adding extra bloat to the spec will
reduce it from a vast array of style-sheets, then it's worth it.
In the case of new functionality, things get more complex: we* have to
figure out how easy/hard would it to implement, how would it impact on
the implementations' performance, and how much useful would it be.
Then we can balance the costs against the benefits and take the best
choice. (*We on this paragraph means "the WG, each implementer, and
interested contributors in the mailing list".)

> Anyway, I
> also don't know if it's too expensive from the point of view of the
> effective implementation or if it's actually another case of excess of
> functionality (as Hakon Wium Lie clearly explains in his thesis on CSS). So,
> what do you think? There are a lot of "I don't know" in this mail, though.
Do you know, at least, what would it do? It's easy to conceive ideas
on the abstract, but they can be quite ambiguous. Personally, I can't
tell you what I think because, right now, I don't know what the
suggested nth-sibling selector would do. Could you please try to
describe it more explicitly? A collection of examples (some uses of
the selectors, a set of markup fragments, and an explicit listing of
what would be matched on each case) would be definitely helpful here
(you may use my markup samples above as a starting point: come up with
some uses of nth-sibling and match each selector against each markup
sample).


Regards,
Eduard Pascual

Received on Friday, 18 June 2010 16:27:37 UTC