Re: [selectors] Previous-sibling combinator?

On Tue, Feb 3, 2015 at 8:37 AM, Henrik Andersson <henke@henke37.cjb.net> wrote:
> Clive Chan skrev:
>> The existence of the following-sibling combinator, +, begs the
>> question: why doesn't a previous-sibling combinator exist? I can't
>> imagine that it's any harder to implement, and I can't come up with
>> any semantic objection - in fact, the lack of symmetry would be a
>> semantic argument for it.
>>
>> If the above seems at all reasonable, the symbol "-" would make sense
>> for the job.
>>
>> Clive Chan
>>
> The symbol could be misinterpreted as a range specifier. At least by
> humans, I have no clue if the actual syntax has any risk of confusion.

Dash has significant parsing complications - dashes tend to get
absorbed into nearby identifiers.  For example, `foo-bar` is a single
ident token, as opposed to `foo+bar` which is two idents separated by
a + token.  Anything new we add needs to be friendly with CSS
tokenization, so we don't run into the same problems as we have with
unicode-range, etc.

In general, we shouldn't be adding new ascii combinators.  We settled
on a /foo/ syntax for new combinators, giving them readable names.

That said, I'm not certain this should be a combinator at all.  We can
instead put :has() in the fast profile if we limit it to only
containing + (and > ?) combinators.

-------

Back to the original question, the reason that previous-sibling
combinator doesn't exist is because the existing combinators all
select "further down" into the tree, which enables some nice
optimizations - while you're building the tree from the parser, you
can take the "most recently added" node and figure out all the
selectors that will apply to it.

That said, there are some exceptions to that, such as
:nth-last-child().  As well, given the new :nth-last-child(n of
selector) syntax, in at least some cases you can hack a "previous
sibling" combinator out of it.  And implementors have said in the past
that at least sibling and child combinators shouldn't be too expensive
to "reverse" in this way.

~TJ

Received on Wednesday, 4 February 2015 04:18:44 UTC