Original Message
Subject: Mobile Web Applications Interoperability Event, 6-7 December
2011, Sophia-Antipolis, France
Resent-Date:Tue, 18 Oct 2011 13:45:25 +
Resent-From:public-test-in...@w3.org
Date: Tue, 18 Oct 2011 15:44:54 +0200
From: ext Francois Daoust
Lachlan and I have been having an...um...*spirited* twitter discussion
regarding querySelectorAll, the (deceased?) queryScopedSelectorAll,
and :scope. He asked me to continue here, so I'll try to keep it
short:
The rooted forms of querySelector and querySelectorAll are mis-designed.
Discussions
On Tue, Oct 18, 2011 at 5:42 PM, Alex Russell slightly...@google.com wrote:
Lachlan and I have been having an...um...*spirited* twitter discussion
regarding querySelectorAll, the (deceased?) queryScopedSelectorAll,
and :scope. He asked me to continue here, so I'll try to keep it
short:
The
On Tue, Oct 18, 2011 at 09:42, Alex Russell slightly...@google.com wrote:
Ah, but we don't need to care what CSS thinks of our DOM-only API. We
can live and let live by building on :scope and specifying find* as
syntactic sugar, defined as:
HTMLDocument.prototype.find =
On 10/18/11 1:14 PM, ext Peter Saint-Andre wrote:
As co-director of the IETF Applications Area, I will be attending TPAC
this year. If there is interest, I would be happy to provide a brief
(15-minute) report to the WebApps WG about work on the WebSocket
protocol at the IETF and coordination
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14414
Ian 'Hixie' Hickson i...@hixie.ch changed:
What|Removed |Added
Status|NEW |RESOLVED
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14480
Ian 'Hixie' Hickson i...@hixie.ch changed:
What|Removed |Added
Status|NEW |RESOLVED
This is _very_ hard to reasonably unless the browser can trust those
functions to not do anything weird. Which of course it can't. So your
options are either much slower selector matching or not having this. Your
pick.
This too has come up in some discussions on CSS (CSSOM I think) that I
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
On Tue, Oct 18, 2011 at 5:04 PM, Boris Zbarsky bzbar...@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
On 10/18/11 5:23 PM, Brian Kardell wrote:
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.
So the script
On 10/18/11 5:23 PM, Brian Kardell wrote:
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.
So the script
On Tue, Oct 18, 2011 at 5:32 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/18/11 5:23 PM, Brian Kardell wrote:
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
I think the query selector functionality is important enough that one
could easily justify adding additional APIs to make this work
better/faster, even if they overlap with existing APIs. But, it would
be unfortunate if more APIs were added to the DOM and libraries still
weren't able to use them
On Tue, Oct 18, 2011 at 6:00 PM, Erik Arvidsson a...@chromium.org wrote:
On Tue, Oct 18, 2011 at 09:42, Alex Russell slightly...@google.com wrote:
Ah, but we don't need to care what CSS thinks of our DOM-only API. We
can live and let live by building on :scope and specifying find* as
syntactic
Some pseudos can contain selector groups, so it would be more than just
split on comma.
On Oct 18, 2011 7:40 PM, Alex Russell slightly...@google.com wrote:
On Tue, Oct 18, 2011 at 6:00 PM, Erik Arvidsson a...@chromium.org wrote:
On Tue, Oct 18, 2011 at 09:42, Alex Russell
On 19/10/11 7:20 AM, Yehuda Katz wrote:
I agree entirely.
I have asked a number of practitioner friends about this scenario:
div id=parent
p id=childspan id=inlineContent/span/p
/div
document.getElementById(child).querySelectorAll(div span); //
returns #inline
In 100% of cases, people
On Tue, Oct 18, 2011 at 4:46 PM, Sean Hogan shogu...@westnet.com.au wrote:
On 19/10/11 7:20 AM, Yehuda Katz wrote:
I agree entirely.
I have asked a number of practitioner friends about this scenario:
div id=parent
p id=childspan id=inlineContent/span/p
/div
Hi Matt,
On Tue, Oct 18, 2011 at 6:25 PM, Matt Shulman mat...@google.com wrote:
I think the query selector functionality is important enough that one
could easily justify adding additional APIs to make this work
better/faster, even if they overlap with existing APIs. But, it would
be
On Tue, Oct 18, 2011 at 8:59 PM, Brian Kardell bkard...@gmail.com wrote:
I know that there were discussions that crossed over into CSS about a
@global or a :context which could sort of include things outside the
scope as part of the query but not be the subject. Does any of that
relate here?
On Tue, Oct 18, 2011 at 9:40 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/18/11 4:20 PM, Yehuda Katz wrote:
* Speeding up certain operations like `#foo` and `body`. There is *no
excuse* for it being possible to implement userland hacks that
improve on the performance of
On Wed, Oct 19, 2011 at 12:45 AM, Brian Kardell bkard...@gmail.com wrote:
Some pseudos can contain selector groups, so it would be more than just
split on comma.
Yes, yes, of course. I've written one of these parsers. Just saying
that the impl would split selector groups and prefix them all
On Wed, Oct 19, 2011 at 12:46 AM, Sean Hogan shogu...@westnet.com.au wrote:
On 19/10/11 7:20 AM, Yehuda Katz wrote:
I agree entirely.
I have asked a number of practitioner friends about this scenario:
div id=parent
p id=childspan id=inlineContent/span/p
/div
On 19/10/11 10:58 AM, Tab Atkins Jr. wrote:
On Tue, Oct 18, 2011 at 4:46 PM, Sean Hoganshogu...@westnet.com.au wrote:
On 19/10/11 7:20 AM, Yehuda Katz wrote:
I agree entirely.
I have asked a number of practitioner friends about this scenario:
div id=parent
p id=childspan
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13799
Ian 'Hixie' Hickson i...@hixie.ch changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
On 10/18/11 6:05 PM, Brian Kardell wrote:
They would run in their own sandbox and they would have access to the
parameters passed into the function by way of pattern.
OK; I think that people might have a pretty tough time with a
programming environment like that... but maybe.
The 'match'
On 10/18/11 7:38 PM, Alex Russell wrote:
The resolution I think is most natural is to split on ,
That fails with :any, with the expanded :not syntax, on attr selectors, etc.
You can split on ',' while observing proper paren and quote nesting, but
that can get pretty complicated.
A minor
On 10/18/11 8:08 PM, Alex Russell wrote:
The other excuse is that adding special cases (which is what you're asking
for) slows down all the non-special-case codepaths. That may be fine for
_your_ usage of querySelectorAll, where you use it with a particular limited
set of selectors, but it's
Overall, I wholeheartedly support the proposal.
I don't really see the benefit of allowing starting with a combinator. I
think it's a rare case that you actually care about the scope element and in
those cases, using :scope is fine. Instead of element.findAll( div
.thinger), you use
29 matches
Mail list logo
