Re: [selectors-4] selector matching being specified from left to right

On Mon, Mar 23, 2015 at 6:17 PM, L. David Baron <dbaron@dbaron.org> wrote:
> http://dev.w3.org/csswg/selectors-4/#evaluating-selectors introduces
> an algorithm that defines how selectors are matched.  It does so by
> doing the matching from left to right (across combinators), which is
> the opposite of what all implementations that I'm aware of do.
>
> Specifying it this way seems like a very bad idea, because it
> introduces a number of risks:
>
>  (1) specification authors might introduce features that are easy to
>  describe in the spec's left-to-right matching but hard to implement
>  in the implementations' right-to-left matching
>
>  (2) we might want to introduce features that are simple in the
>  implementations' right-to-left matching, but that are hard to
>  describe it the spec's right-to-left matching
>
>  (3) we might introduce features where it's easy to make subtle
>  errors in the mapping between the two descriptions; this can lead
>  to things that are technically bugs in implementations, and might
>  even do so interoperably.  It's better for these not to be bugs,
>  and just to match the spec.
>
> So I think that if the spec introduces an algorithmic description of
> selector matching (as the current draft of selectors-4 does), that
> algorithm should work the same way implementations work.

Selector matching is often informally described in a left-to-right
manner.  When people talk about matching a selector against a single
element, they sometimes talk in right-to-left terms, but when matching
against a tree, it's usually described with left-to-right language.
(At least, in my experience.)

Your #2 is already true in reverse; we have features that are easy to
describe in left-to-right language, but hard in right-to-left.
::shadow and >>> are easy to describe in left-to-right as just an
elaboration on the existing "move down the tree" language.  If you try
to describe them right-to-left, you either have to start from the
universe of all possible elements and use a check at the end of every
matching that the matched elements are in the expected tree, which
doesn't match how implementations work, or you have to deal with
splitting the selector into sub-selectors at tree boundaries, so you
can evaluate each subselector right-to-left, but the selector as a
whole left-to-right.  (Doing that with maybe-crossing-a-tree-boundary
cases like >>> is even more complicated, as you have to fork the
cases.)

I'm not opposed to figuring out how to write it in the opposite
direction, but it *will* make things more complicated in interesting
ways.  There are tradeoffs either way.

~TJ

Received on Wednesday, 25 March 2015 21:23:06 UTC