Re: Why is querySelector much slower?

Ww, this is pure gold. Thank you so much for such thorough explanation, any even took the trouble to actually implement optimizations to make sure the numbers are right. I'm so grateful for the work you put into this just to answer my question. How do I accept your answer here? ;) > So what

Re: Directory Upload Proposal

On Mon, Apr 27, 2015 at 9:45 PM, Jonas Sicking wrote: > On Thu, Apr 23, 2015 at 12:28 PM, Ali Alabbas wrote: >> Hello WebApps Group, > > Hi Ali, > > Yay! This is great to see a formal proposal for! Definitely something > that mozilla is very interested in working on. > >> If there is sufficient i

Re: Directory Upload Proposal

On Tue, Apr 28, 2015 at 4:28 PM, Travis Leithead wrote: >>> Aaron opened an issue for this on GitHub [1] and I agree that it is a >>> problem and we should definitely rename it to something else! One option >>> might be to change dir to directory, but we would need a different name for >>> dire

Re: Directory Upload Proposal

On Tue, Apr 28, 2015 at 4:26 PM, Travis Leithead wrote: >>> Second, rather than adding a .directory attribute, I think that we should >>> simply add any selected directories to the .files list. My experience is >>> that having a direct mapping between what the user does, and what we expose >>>

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

On Tue, Apr 28, 2015 at 4:32 PM, Ryosuke Niwa wrote: > On Apr 27, 2015, at 4:23 PM, Tab Atkins Jr. wrote: > > On Mon, Apr 27, 2015 at 4:06 PM, Tab Atkins Jr. > wrote: > > On Mon, Apr 27, 2015 at 3:42 PM, Ryosuke Niwa wrote: > > On Apr 27, 2015, at 3:15 PM, Steve Orvell wrote: > IMO, the appea

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

On Apr 27, 2015, at 4:23 PM, Tab Atkins Jr. wrote: > On Mon, Apr 27, 2015 at 4:06 PM, Tab Atkins Jr. wrote: >> On Mon, Apr 27, 2015 at 3:42 PM, Ryosuke Niwa wrote: On Apr 27, 2015, at 3:15 PM, Steve Orvell wrote: IMO, the appeal of this proposal is that it's a small change to the >>>

RE: Directory Upload Proposal

>> Aaron opened an issue for this on GitHub [1] and I agree that it is a >> problem and we should definitely rename it to something else! One option >> might be to change dir to directory, but we would need a different name for >> directory (the attribute that gets back the virtual root holding

RE: Directory Upload Proposal

>> Second, rather than adding a .directory attribute, I think that we should >> simply add any selected directories to the .files list. My experience is >> that having a direct mapping between what the user does, and what we expose >> to the webpage, generally results in less developer confusion

RE: Directory Upload Proposal

On Tue, Apr 28, 2015 at 4:15 PM, Tab Atkins Jr. wrote: >On Tue, Apr 28, 2015 at 3:53 PM, Ryan Seddon wrote: >>> To enable developers to build future interoperable solutions, we've >>> drafted a proposal [4], with the helpful feedback of Mozilla and >>> Google, that focuses strictly on providin

Re: Directory Upload Proposal

On Tue, Apr 28, 2015 at 3:53 PM, Ryan Seddon wrote: >> To enable developers to build future interoperable solutions, we've >> drafted a proposal [4], with the helpful feedback of Mozilla and Google, >> that focuses strictly on providing the mechanisms necessary to enable >> directory uploads. > >

Re: Directory Upload Proposal

> To enable developers to build future interoperable solutions, we've > drafted a proposal [4], with the helpful feedback of Mozilla and Google, > that focuses strictly on providing the mechanisms necessary to enable > directory uploads. > The use of the dir attribute seems odd since I can already

IndieUI Teleconference Agenda; 29 April at 21:00Z

Cross-posting as is usual ... What: IndieUI Task Force Teleconference When: Wednesday 29 April 2:00 PMSan Francisco -- U.S. Pacific Time (PDT: UTC -7) 4:00 PMAustin -- U.S. Central Time(CDT: UTC -5) 5:00 PMBoston -- U.S. Eas

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

I've updated the gist to reflect the discussion so far: https://gist.github.com/rniwa/2f14588926e1a11c65d3 Please leave a comment if I missed anything. - R. Niwa

Re: =[xhr]

On Tue, Apr 28, 2015 at 7:51 AM, Ken Nelson wrote: > RE async: false being deprecated > > There's still occasionally a need for a call from client javascript back to > server and wait on results. Example: an inline call from client javascript > to PHP on server to authenticate an override password

=[xhr]

RE async: false being deprecated There's still occasionally a need for a call from client javascript back to server and wait on results. Example: an inline call from client javascript to PHP on server to authenticate an override password as part of a client-side operation. The client-side experien

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

> On Apr 28, 2015, at 1:04 PM, Elliott Sprehn wrote: > > A distribute callback means running script any time we update distribution, > which is inside the style update phase (or event path computation phase, ...) > which is not a location we can run script. That's not what Anne and the rest o

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

A distribute callback means running script any time we update distribution, which is inside the style update phase (or event path computation phase, ...) which is not a location we can run script. We could run script in another scripting context like is being considered for custom layout and paint

Re: Inheritance Model for Shadow DOM Revisited

> On Wed, Apr 29, 2015 at 2:09 AM Ryosuke Niwa wrote: >> >> > On Apr 27, 2015, at 9:50 PM, Hayato Ito wrote: >> > >> > The feature of " as function" supports *subclassing*. That's >> > exactly the motivation I've introduced it once in the spec (and >> > implemented it in blink). I think Jan M

[Bug 28579] New: [Shadow]:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28579 Bug ID: 28579 Summary: [Shadow]: Product: WebAppsWG Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: minor Priority: P2

Re: Inheritance Model for Shadow DOM Revisited

Could you help me to understand what "implicitly" means here? In this particular case, you might want to blame the super class's author and tell the author, "Please use so that subclass can override it with arbitrary element with class="input-foo". Could you give me an concrete example which ca

RE: [components] Isolated Imports and Foreign Custom Elements

On Thu Apr 23 02:58 PM, Maciej Stachowiak wrote: > > https://github.com/w3c/webcomponents/wiki/Isolated-Imports-Proposal > > I welcome comments on whether this approach makes sense. Security rules are unclear but love this approach https://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0

Re: Inheritance Model for Shadow DOM Revisited

> On Apr 27, 2015, at 9:50 PM, Hayato Ito wrote: > > The feature of " as function" supports *subclassing*. That's exactly > the motivation I've introduced it once in the spec (and implemented it in > blink). I think Jan Miksovsky, co-author of Apple's proposal, knows well that. We're (and con

Re: Why is querySelector much slower?

On 4/28/15 2:59 AM, Glen Huang wrote: Looking at the microbenchmark again, for Gecko, getElementById is around 300x faster than querySelector('#id'), and even getElementsByClassName is faster than it. This is why one should not write microbenchmarks. ;) Or at least if one does, examine the

[Bug 28353] [Shadow]: Use a parent/child relationship in the composed tree for some elements, i.e. /

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28353 Koji Ishii changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|---

Re: Why is querySelector much slower?

On 4/28/15 2:44 AM, Glen Huang wrote: But If I do getElementsByClass()[0], and LiveNodeList is immediately garbage collectable Then it will only be collected the next time GC happens. Which might not be for a while. -Boris

Re: Why is querySelector much slower?

On 4/28/15 1:58 AM, Glen Huang wrote: Just a quick follow up question to quench my curiosity: if I do "list[1]" and no one has ever asked the list for any element, Gecko will find the first two matching elements, and store them in the list, if I then immediately do "list[0]", the first element

Re: Why is querySelector much slower?

On 4/28/15 2:13 AM, Glen Huang wrote: On second thought, if the list returned by getElementsByClass() is lazy populated as Boris says, it shouldn't be a problem. The list is only updated when you access that list again. Mutations have to check whether the list is marked dirty already or not. T

Re: Web Storage Rec errata?

On 4/21/15 5:39 AM, Kostiainen, Anssi wrote: Hi, Is there a plan to publish an errata to sync the Web Storage Rec [1] with the latest? I counted 8 commits cherry picked into the Editor's Draft since Rec [2]. If no errata publication is planned, I'd expect the Rec to clearly indicate its statu

[selectors-api] How to mark TR version as obsolete/superseded? [Was: Re: Obsolete Document]

On 3/26/15 8:30 AM, Gulfaraz Yasin wrote: Hi It has come to my notice that the following document http://www.w3.org/TR/selectors-api/#resolving-namespaces is obsolete. Hi Gulfaraz, Thanks for your e-mail and sorry for the slow reply. I was directed to it's page from one of StackOverflow's

Re: Why is querySelector much slower?

> querySelector with an id selector does in fact benefit from the id hashtable Looking at the microbenchmark again, for Gecko, getElementById is around 300x faster than querySelector('#id'), and even getElementsByClassName is faster than it. It doesn't look like it benefits much from an eagerly