Re: nth descendent selector

On Tue, Nov 13, 2012 at 1:56 PM, Liam R E Quin <liam@w3.org> wrote:
> On Tue, 2012-11-13 at 11:27 -0800, Tab Atkins Jr. wrote:
>> On Fri, Nov 9, 2012 at 2:33 AM, Dave Smith <da__smith@hotmail.com> wrote:
>> > For example
>> > li:nth(7)
>> > would be equivalent to document.getElementsByTagName('li')[6]
>>
>> The XQuery language (cousin to Selectors) has this functionality.
>
> (as does XPath)

Heh, XPath is actually what I meant to refer to.  ^_^

>> Unfortunately, it's difficult to do in Selectors, because all browsers
>> (and most JS-based selector engines, too) optimize selectors by
>> evaluating them right-to-left, rather than the left-to-right that you
>> probably expect.
>
> For what it's worth, XQuery engines do this too - or sometimes evaluate
> from the middle, too - for performance reasons.
>
> There were papers on this at various VLDB conferences.
>
> Early on in XQuery develpment there were concerns about performance of
> the XPath "full axis feature", but it turned out that the workarounds
> users found for missing axis support were massively slower and harder to
> optimize than native support; the same is probably true of some of the
> CSS selector proposals. It also turned out that the "full axis feature"
> could be optimized heavily - e.g., again, there was a paper I think at
> VLDB, showing how to turn backwards-looking expressions into
> forwards-looking ones, so that you could implement preceding-sibling and
> friends as efficiently as following-sibilng even in a streaming
> environment.

Cool!  If someone who likes working on Selectors code is ever
interested in exploring these kinds of optimizations, I'd be very
interested in hearing about it!

~TJ

Received on Tuesday, 13 November 2012 22:04:48 UTC