W3C home > Mailing lists > Public > www-style@w3.org > April 2015

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

From: L. David Baron <dbaron@dbaron.org>
Date: Wed, 15 Apr 2015 23:24:24 -0700
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style list <www-style@w3.org>
Message-ID: <20150416062424.GA23839@pescadero.dbaron.org>
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)

Received on Thursday, 16 April 2015 06:24:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:30 UTC