W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: QSA, the problem with ":scope", and naming

From: Brian Kardell <bkardell@gmail.com>
Date: Tue, 18 Oct 2011 17:23:29 -0400
Message-ID: <CADC=+je9vAG5Fufv7QAxKQZuRFoLv7ZjkE1m82r00vuaabOEZA@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-webapps@w3.org
On Tue, Oct 18, 2011 at 5:04 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 10/18/11 5:01 PM, Brian Kardell wrote:
>> This too has come up in some discussions on CSS (CSSOM I think) that I
>> have had.  In the right context - I don't think it would actually be
>> that hard.  It would require a way to provide a sand-boxed evaluation
>> (read only elements)
> This is not that easy.  Especially because you can reach all DOM objects
> from elements, so you have to lock down the entire API somehow.

Right, you would need essentially, to pass in a node list which
iterated 'lite' read-only elements.  Not impossible to imagine -
right? Maybe I'm way off, but actually seems not that difficult to
imagine the implementation.

>> and a pattern much like jquery's where it is a
>> filter which can only return true or false.  True enough that it would
>> be slower than native for a few reasons - but perhaps still useful.
> The slowness comes from not having a way to tell whether the world has
> changed under you or not and therefore having to assume that it has, not
> from the actual call into JS per se.
I imagine that they would be implemented as filters so if you had

div .x:foo(.bar) span

The normal CSS resolution would be to get the spans, narrow by .x's
then throw what you have so far to the filter, removing anything that
returned false and carrying on as normal. The slowness as I see it
would be that the filter would yes, call across the boundary and yes
have to build some intermediate and evaluating anything too complex in
the filter in that would be very slow by comparison probably - but you
don't have to do "much" to be useful...  Is there something in that
pattern that I am missing in terms of  what you are saying about
identifying what has changed out from underneath you? As far as I can
see it doesn't invalidate anything that already exists in CSS/selector
implementations in terms of indexes or anything - but I've been
looking for an answer to this exact question so if you know something
I'd be very interested in even a pointer to some code so I can
understand myself.
Received on Tuesday, 18 October 2011 21:24:04 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC