Re: "match a selectors string" in the DOM spec doesn't do what it wants to be doing

"Tab Atkins Jr." <[email protected]>
Newsgroups gmane.comp.web.dom.general
Message-ID <CAAWBYDBJKVjJvrmV4LxdxHjmxabchuWPJZYeOyJgB_eFsy1vXw@mail.gmail.com>
On Fri, Aug 8, 2014 at 6:31 PM, Boris Zbarsky <[email protected]> wrote:
> On 8/8/14, 6:02 PM, Tab Atkins Jr. wrote:
>> I think this does what you want?
>> http://dev.w3.org/csswg/selectors/#match-against-element
>
> Looks like it, modulo the same observability issues Anne's current setup
> has.

If selector matching ever becomes observable, we've got to settle on a
matching algorithm in general, not just for this simple case.  The
spec still talks about matching in the natural way, evaluating the
selector from left to right, rather than from right to left as
browsers tend to do.

I could possibly restate the entire algorithm in terms of
right-to-left evaluation, but that would entail a rather more involved
rewriting of the semantics of the combinators and everything that
talks about matching even indirectly.  The algorithm also gets
significantly more complex in the RTL direction, due to context
issues: when evaluating LTR, you definitely *start* by looking at the
elements visible in your current context; to do RTL, you have to break
up the selector along context-crossing combinators and evaluate each
chunk (in LTR order) individually.

~TJ
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.