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

On Wednesday 2015-03-25 14:22 -0700, Tab Atkins Jr. wrote:
> 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.)

So how do implementations work?  Maybe it's worth describing that.
Because I don't think any implementations do right-to-left matching
across combinators.

> 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.

I think you're optimizing for the convenience of the spec author
over interoperability here.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)