Re: Why is querySelector much slower?

[Glen Huang]

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 you're seeing is that the benchmark claims the operation is performed 
> in 1-2 clock cycles

I never thought about relating ops/sec numbers to clock cycles. Thanks for the 
tip.

> So what this getElementById benchmark measures is how fast a loop counter can 
> be decremented from some starting value to 0.

This makes so much sense now.

> because of the proxy machinery involved on the JS engine side

Do you mean the cost introduced by passing a C++ object into ecmascript world?

> In this case, those all seem to have about the same cost;

I now see why querySelector has some extract work to do.

> But for real-life testcases algorithmic complexity can often be much more 
> important.

Yes. But I suddenly find microbenchmarks to be a wonderful conversation 
starter. ;)

Thanks again for all the explanations, I'm motivated by them to actually dig 
into the engine source code to discover things myself next time (probably not 
easy, but should be rewarding). :)

Re: Directory Upload Proposal

[Jonas Sicking]

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 interest, I would like to work on this within the 
>> scope of the WebApps working group.
>
> I personally will stay out of WG politics. But I think the proposal
> will receive more of the needed attention and review in this WG than
> in the HTML WG. But I'm not sure if W3C policies dictate that this is
> done in the HTML WG.
>
>> [4] Proposal: 
>> http://internetexplorer.github.io/directory-upload/proposal.html
>
> So, some specific feedback on the proposal.
>
> First off, I don't think you can use the name "dir" for the new
> attribute since that's already used for setting rtl/ltr direction.
> Simply renaming the attribute to something else should fix this.
>
> 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 and/or annoyance.
>
> My understanding is that the current proposal is mainly so that if we
> in the future add something like Directory.enumerateDeep(), that that
> would automatically enable deep enumeration through all user options.
> However that could always be solved by adding a
> HTMLInputElement.enumerateFilesDeep() function.

Oh, there's another thing missing that I missed. We also need some
function, similar to .click(), which allows a webpage to
programmatically bring up a directory picker. This is needed on
platforms like Windows and Linux which use separate platform widgets
for picking a directory and picking a file. Many websites hide the
default browser provided  UI and then call .click()
when the user clicks the website UI.

A tricky question is what to do on platforms that don't have a
separate directory picker (like OSX) or which doesn't have a concept
of directories (most mobile platforms). We could either make those UAs
on those platforms not have the separate .clickDirectoryPicker()
function (or whatever we'll call it), or make them have it but just do
the same as .click().

/ Jonas

Re: Directory Upload Proposal

[Jonas Sicking]

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 
>>> directory (the attribute that gets back the virtual root holding the 
>>> selected files and folders).
>
> I wonder, is it necessary to have a separate "dir"/"directory" attribute from 
> "multiple"? Adding a new DOM attribute will allow for feature detecting this 
> change. UA's can handle the presentation of a separate directory picker if 
> necessary--why force this distinction on the web developer?

We need the "dir"/"directory" attribute in order for pages to indicate
that it can handle Directory objects. No matter where/how we expose
those Directory objects.

/ Jonas

Re: Directory Upload Proposal

[Jonas Sicking]

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 
>>> to the webpage, generally results in less developer confusion and/or 
>>> annoyance.
>
> I like this consolidation, but Ali concern (and one I share) is that legacy 
> code using .files will not expect to encounter new Directory objects in the 
> list and will likely break unless the Directory object maintains a 
> backwards-compatible File-like appearance.

Legacy pages won't be setting the "directory" attribute.

In fact, this is the whole purpose of the "directory" attribute. To
enable pages to signal "I can handle the user picking directories".

> I have a concern about revealing the user's directory names to the server, 
> and suggested anonymizing the names, but it seems that having directory path 
> names flow through to the server intact is an important scenario for 
> file-syncing, which anonymizing might break.

I agree that this is a concern, though one separate from what API we use.

I do think it's fine to expose the directory name of the directory
that the user pick. It doesn't seem very different from the fact that
we expose the filename of the files that the user pick.

/ Jonas

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

[Justin Fagnani]

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 appeal of this proposal is that it's a small change to the
> current spec and avoids changing user expectations about the state of the
> dom and can explain the two declarative proposals for distribution.
>
> It seems like with this API, we’d have to make O(n^k) calls where n is the
> number of distribution candidates and k is the number of insertion points,
> and that’s bad.  Or am I misunderstanding your design?
>
>
> I think you've understood the proposed design. As you noted, the cost is
> actually O(n*k). In our use cases, k is generally very small.
>
>
> I don't think we want to introduce O(nk) algorithm. Pretty much every
> browser optimization we implement these days are removing O(n^2) algorithms
> in the favor of O(n) algorithms. Hard-baking O(nk) behavior is bad because
> we can't even theoretically optimize it away.
>
>
> You're aware, obviously, that O(n^2) is a far different beast than
> O(nk).  If k is generally small, which it is, O(nk) is basically just
> O(n) with a constant factor applied.
>
>
> To make it clear: I'm not trying to troll Ryosuke here.
>
> He argued that we don't want to add new O(n^2) algorithms if we can
> help it, and that we prefer O(n).  (Uncontroversial.)
>
> He then further said that an O(nk) algorithm is sufficiently close to
> O(n^2) that he'd similarly like to avoid it.  I'm trying to
> reiterate/expand on Steve's message here, that the k value in question
> is usually very small, relative to the value of n, so in practice this
> O(nk) is more similar to O(n) than O(n^2), and Ryosuke's aversion to
> new O(n^2) algorithms may be mistargeted here.
>
>
> Thanks for clarification. Just as Justin pointed out [1], one of the most
> important use case of imperative API is to dynamically insert as many
> insertion points as needed to wrap each distributed node.  In such a use
> case, this algorithm DOES result in O(n^2).
>

I think I said it was a possibility opened by an imperative API, but I
thought it would be very rare (as will be any modification of the shadow
root in the distribution callback). I think that accomplishing decoration
by inserting an insertion point per distributed node is probably a
degenerate case and it would be better if we supported decoration, but that
seems like a v2+ type feature.

-Justin


>
> In fact, it could even result in O(n^3) behavior depending on how we spec
> it.  If the user code had dynamically inserted insertion points one by one
> and UA invoked this callback function for each insertion point and each
> node.  If we didn't, then author needs a mechanism to let UA know that the
> condition by which insertion points select a node has changed and it needs
> to re-distribute all the nodes again.
>
> - R. Niwa
>
> [1]
> https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0325.html
>
>

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

[Ryosuke Niwa]

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 
 current spec and avoids changing user expectations about the state of the 
 dom and can explain the two declarative proposals for distribution.
 
> It seems like with this API, we’d have to make O(n^k) calls where n is 
> the number of distribution candidates and k is the number of insertion 
> points, and that’s bad.  Or am I misunderstanding your design?
 
 I think you've understood the proposed design. As you noted, the cost is 
 actually O(n*k). In our use cases, k is generally very small.
>>> 
>>> I don't think we want to introduce O(nk) algorithm. Pretty much every 
>>> browser optimization we implement these days are removing O(n^2) algorithms 
>>> in the favor of O(n) algorithms. Hard-baking O(nk) behavior is bad because 
>>> we can't even theoretically optimize it away.
>> 
>> You're aware, obviously, that O(n^2) is a far different beast than
>> O(nk).  If k is generally small, which it is, O(nk) is basically just
>> O(n) with a constant factor applied.
> 
> To make it clear: I'm not trying to troll Ryosuke here.
> 
> He argued that we don't want to add new O(n^2) algorithms if we can
> help it, and that we prefer O(n).  (Uncontroversial.)
> 
> He then further said that an O(nk) algorithm is sufficiently close to
> O(n^2) that he'd similarly like to avoid it.  I'm trying to
> reiterate/expand on Steve's message here, that the k value in question
> is usually very small, relative to the value of n, so in practice this
> O(nk) is more similar to O(n) than O(n^2), and Ryosuke's aversion to
> new O(n^2) algorithms may be mistargeted here.

Thanks for clarification. Just as Justin pointed out [1], one of the most 
important use case of imperative API is to dynamically insert as many insertion 
points as needed to wrap each distributed node.  In such a use case, this 
algorithm DOES result in O(n^2).

In fact, it could even result in O(n^3) behavior depending on how we spec it.  
If the user code had dynamically inserted insertion points one by one and UA 
invoked this callback function for each insertion point and each node.  If we 
didn't, then author needs a mechanism to let UA know that the condition by 
which insertion points select a node has changed and it needs to re-distribute 
all the nodes again.

- R. Niwa

[1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0325.html 

RE: Directory Upload Proposal

[Travis Leithead]

>> 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 the 
>> selected files and folders).

I wonder, is it necessary to have a separate "dir"/"directory" attribute from 
"multiple"? Adding a new DOM attribute will allow for feature detecting this 
change. UA's can handle the presentation of a separate directory picker if 
necessary--why force this distinction on the web developer?

-Original Message-
From: Ali Alabbas [mailto:a...@microsoft.com] 
Sent: Tuesday, April 28, 2015 4:21 PM
To: Tab Atkins Jr.; Ryan Seddon
Cc: Web Applications Working Group WG
Subject: 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 providing the mechanisms necessary 
>>> to enable directory uploads.
>>
>> The use of the dir attribute seems odd since I can already apply dir="rtl"
>> to an input to change the text direction.
>
>Good catch; that's a fatal naming clash, and needs to be corrected.
>The obvious one is to just expand out the name to "directory".
>
>~TJ

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 the selected files and 
folders).

[1] https://github.com/InternetExplorer/directory-upload/issues/1

RE: Directory Upload Proposal

[Travis Leithead]

>> 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 and/or 
>> annoyance.

I like this consolidation, but Ali concern (and one I share) is that legacy 
code using .files will not expect to encounter new Directory objects in the 
list and will likely break unless the Directory object maintains a 
backwards-compatible File-like appearance.

In the proposed model, the "directory" would be a virtual wrapper around any 
existing selected files, and could wholly replaces .files, while providing a 
nice extension point for additional behavior later.

I have a concern about revealing the user's directory names to the server, and 
suggested anonymizing the names, but it seems that having directory path names 
flow through to the server intact is an important scenario for file-syncing, 
which anonymizing might break.

-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc] 
Sent: Monday, April 27, 2015 9:45 PM
To: Ali Alabbas
Cc: Web Applications Working Group WG
Subject: Re: Directory Upload Proposal

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 interest, I would like to work on this within the 
> scope of the WebApps working group.

I personally will stay out of WG politics. But I think the proposal will 
receive more of the needed attention and review in this WG than in the HTML WG. 
But I'm not sure if W3C policies dictate that this is done in the HTML WG.

> [4] Proposal: 
> http://internetexplorer.github.io/directory-upload/proposal.html

So, some specific feedback on the proposal.

First off, I don't think you can use the name "dir" for the new attribute since 
that's already used for setting rtl/ltr direction.
Simply renaming the attribute to something else should fix this.



My understanding is that the current proposal is mainly so that if we in the 
future add something like Directory.enumerateDeep(), that that would 
automatically enable deep enumeration through all user options.
However that could always be solved by adding a
HTMLInputElement.enumerateFilesDeep() function.

/ Jonas

RE: Directory Upload Proposal

[Ali Alabbas]

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 providing the mechanisms necessary 
>>> to enable directory uploads.
>>
>> The use of the dir attribute seems odd since I can already apply dir="rtl"
>> to an input to change the text direction.
>
>Good catch; that's a fatal naming clash, and needs to be corrected.
>The obvious one is to just expand out the name to "directory".
>
>~TJ

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 the selected files and 
folders).

[1] https://github.com/InternetExplorer/directory-upload/issues/1

Re: Directory Upload Proposal

[Tab Atkins Jr.]

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.
>
> The use of the dir attribute seems odd since I can already apply dir="rtl"
> to an input to change the text direction.

Good catch; that's a fatal naming clash, and needs to be corrected.
The obvious one is to just expand out the name to "directory".

~TJ

Re: Directory Upload Proposal

[Ryan Seddon]

> 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 apply dir="rtl"
to an input to change the text direction.

IndieUI Teleconference Agenda; 29 April at 21:00Z

[Janina Sajka]

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. Eastern  Time(EDT: UTC -4)
10:00 PMLondon -- British  Time (BST: UTC +1)
11:00 PMParis -- Central European Time  (CET: UTC +2)
 5:00 AMBeijing -- China Standard Time  (Thursday, 30 April 
CST: UTC +8)
 6:00 AMTokyo -- Japan Standard Time(Thursday, 30 April 
JST: UTC +9)
Where:  W3C Teleconference--See Below

* Time of day conversions

Please verify the correct time of this meeting in your time zone using
the Fixed Time Clock at:

http://timeanddate.com/worldclock/fixedtime.html?msg=IndieUI+Teleconference&iso=20150429T1700&p1=43&ah=1

** Preliminary Agenda for IndieUI Task Force Teleconference 29 April 2015

Meeting: IndieUI Task Force Teleconference
Chair:  Janina_Sajka
agenda+ preview agenda with items from two minutes
agenda+ Editors' Reports; Heartbeat Publications Update
agenda+ Future of IndieUI Work (Continued)
agenda+  Other Business
agenda+ Be Done

Resource: Teleconference Minutes
http://www.w3.org/2015/04/15-indie-ui-minutes.html

Resource: First Survey Results
https://www.w3.org/2002/09/wbs/54997/201503_planning/results

Resource: Second Survey Results
https://www.w3.org/2002/09/wbs/54997/201504_fate/results

Resource: Schema.org meta data mapping to Indie UI User context
https://docs.google.com/spreadsheets/d/1pb92piOlud5sXQadXYnbmtp9LCut26gv8ku-qqZTwec/edit#gid=0

Resource: Web Apps Editing TF
Editing Explainer:  http://w3c.github.io/editing-explainer/
User Intentions:
http://w3c.github.io/editing-explainer/commands-explainer.html

Resource: For Reference
Home Page:  http://www.w3.org/WAI/IndieUI/
Email Archive:  http://lists.w3.org/Archives/Public/public-indie-ui/

Resource: Teleconference Logistics
Dial the Zakim bridge using either SIP or the PSTN.
PSTN: +1.617.761.6200 (This is a U.S. number).
SIP: za...@voip.w3.org
You should be prompted for a pass code,
This is
46343#
(INDIE#)

Alternatively, bypass the Zakim prompts and SIP directly into our
teleconference.
SIP: 0046...@voip.w3.org

Instructions for connecting using SIP:
http://www.w3.org/2006/tools/wiki/Zakim-SIP
Place for users to contribute additional VoIP tips.
http://www.w3.org/2006/tools/wiki/Zakim-SIP-tips

IRC: server: irc.w3.org, channel: #indie-ui.

During the conference you can manage your participation with Zakim
commands as follows:
   61# to mute yourself
   60# to unMute yourself
   41# to raise your hand (enter speaking queue)
   40# to lower your hand (exit speaking queue)

The system acknowledges these commands with a rapid, three-tone
confirmation.  Mobile phone users especially should use the mute
function
if they don't have a mute function in their phone.  But the hand-raising
function is a good idea for anyone not using IRC.

* IRC access

An IRC channel will be available. The server is
irc.w3.org,
The port number is 6665 (Note this is not the normal default) and
The channel is #indie-ui.

* Some helpful Scribing and Participation Tips
http://www.w3.org/WAI/PF/wiki/Teleconference_cheat_sheet

For more on the IRC setup and the robots we use for agenda and speaker
queuing and for posting the log to the web, see:

- For RRSAgent, that captures and posts the log with special attention
to action items:
http://www.w3.org/2002/03/RRSAgent

- For Zakim, the IRC interface to the bridge manager, that will
maintain speaker and agenda queues:
http://www.w3.org/2001/12/zakim-irc-bot

- For a Web gateway to IRC you can use if your network administrators
forbid IRC, see:
http://www.w3.org/2001/01/cgi-irc

- For more on W3C use of IRC see:
http://www.w3.org/Project/IRC/

--

Janina Sajka,   Phone:  +1.443.300.2200
sip:jan...@asterisk.rednote.net
Email:  jan...@rednote.net

The Linux Foundation
Chair, Open Accessibility:  http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,  Protocols & Formats http://www.w3.org/wai/pf
IndieUI http://www.w3.org/WAI/IndieUI/

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

[Ryosuke Niwa]

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]

[Tab Atkins Jr.]

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 as part of a
> client-side operation. The client-side experience could be managed with a
> sane timeout param - eg return false if no response after X seconds (or ms).

Nothing prevents you from waiting on an XHR to return before
continuing.  Doing it with async operations is slightly more complex
than blocking with a sync operation, is all.

~TJ

=[xhr]

[Ken Nelson]

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 experience could be managed with a
sane timeout param - eg return false if no response after X seconds (or ms).

Thanks

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

[Ryosuke Niwa]

> 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 of us are proposing. That idea only came up 
in Steve's proposal [1] that kept the current timing of distribution.

> I also don't believe we should support distributing any arbitrary descendant, 
> that has a large complexity cost and doesn't feel like simplification. It 
> makes computing style and generating boxes much more complicated.

That certainly is a trade off. See a use case I outlined in [2].

> A synchronous childrenChanged callback has similar issues with when it's safe 
> to run script, we'd have to defer it's execution in a number of situations, 
> and it feels like a duplication of MutationObservers which specifically were 
> designed to operate in batch for better performance and fewer footguns (ex. a 
> naive childrenChanged based distributor will be n^2).

Since the current proposal is to add it as a custom element's lifecycle 
callback (i.e. we invoke it when we cross UA code / user code boundary), this 
shouldn't be an issue. If it is indeed an issue, then we have a problem with a 
lifecycle callback that gets triggered when an attribute value is modified.

In general, I don't think we can address Steve's need to make the consistency 
guarantee [3] without running some script either synchronously or as a 
lifecycle callback in the world of an imperative API.

- R. Niwa

[1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0342.html
[2] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0344.html
[3] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0357.html

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

[Elliott Sprehn]

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 though, but that has a different API shape since you'd register a
separate .js file as the "custom distributor." like

(document || shadowRoot).registerCustomDistributor({src: "distributor.js"});

I also don't believe we should support distributing any arbitrary
descendant, that has a large complexity cost and doesn't feel like
simplification. It makes computing style and generating boxes much more
complicated.

A synchronous childrenChanged callback has similar issues with when it's
safe to run script, we'd have to defer it's execution in a number of
situations, and it feels like a duplication of MutationObservers which
specifically were designed to operate in batch for better performance and
fewer footguns (ex. a naive childrenChanged based distributor will be n^2).


On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa  wrote:

>
> > On Apr 27, 2015, at 12:25 AM, Justin Fagnani 
> wrote:
> >
> > On Sun, Apr 26, 2015 at 11:05 PM, Anne van Kesteren 
> wrote:
> >> On Sat, Apr 25, 2015 at 10:49 PM, Ryosuke Niwa  wrote:
> >> > If we wanted to allow non-direct child descendent (e.g. grand child
> node) of
> >> > the host to be distributed, then we'd also need O(m) algorithm where
> m is
> >> > the number of under the host element.  It might be okay to carry on
> the
> >> > current restraint that only direct child of shadow host can be
> distributed
> >> > into insertion points but I can't think of a good reason as to why
> such a
> >> > restriction is desirable.
> >
> > The main reason is that you know that only a direct parent of a node can
> distribute it. Otherwise any ancestor could distribute a node, and in
> addition to probably being confusing and fragile, you have to define who
> wins when multiple ancestors try to.
> >
> > There are cases where you really want to group element logically by one
> tree structure and visually by another, like tabs. I think an alternative
> approach to distributing arbitrary descendants would be to see if nodes can
> cooperate on distribution so that a node could pass its direct children to
> another node's insertion point. The direct child restriction would still be
> there, so you always know who's responsible, but you can get the same
> effect as distributing descendants for a cooperating sets of elements.
>
> That's an interesting approach. Ted and I discussed this design, and it
> seems workable with Anne's `distribute` callback approach (= the second
> approach in my proposal).
>
> Conceptually, we ask each child of a shadow host the list of distributable
> node for under that child (including itself). For normal node without a
> shadow root, it'll simply itself along with all the distribution candidates
> returned by its children. For a node with a shadow root, we ask its
> implementation. The recursive algorithm can be written as follows in pseudo
> code:
>
> ```
> NodeList distributionList(Node n):
>   if n has shadowRoot:
> return 
>   else:
> list = [n]
> for each child in n:
>   list += distributionList(n)
> return list
> ```
>
> Now, if we adopted `distribute` callback approach, one obvious mechanism
> to do (1) is to call `distribute` on n and return whatever it didn't
> distribute as a list. Another obvious approach is to simply return [n] to
> avoid the mess of n later deciding to distribute a new node.
>
> >> So you mean that we'd turn distributionList into a subtree? I.e. you
> >> can pass all descendants of a host element to add()? I remember Yehuda
> >> making the point that this was desirable to him.
> >>
> >> The other thing I would like to explore is what an API would look like
> >> that does the subclassing as well. Even though we deferred that to v2
> >> I got the impression talking to some folks after the meeting that
> >> there might be more common ground than I thought.
> >
> > I really don't think the platform needs to do anything to support
> subclassing since it can be done so easily at the library level now that
> multiple generations of shadow roots are gone. As long as a subclass and
> base class can cooperate to produce a single shadow root with insertion
> points, the platform doesn't need to know how they did it.
>
> I think we should eventually add native declarative inheritance support
> for all of this.
>
> One thing that worries me about the `distribute` callback approach (a.k.a.
> Anne's approach) is that it bakes distribution algorithm into the platform
> without us having thoroughly studied how subclassing will be done upfront.
>
> Mozilla tried to solve this problem with XBS, and they seem to think what
> they have isn't really great. Google has spent multiple years working on
> this problem but they come around to say t

Re: Inheritance Model for Shadow DOM Revisited

[Ryosuke Niwa]

> 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 Miksovsky, co-author of Apple's 
>> > proposal, knows well that.
>> 
>> We're (and consequently I'm) fully aware of that feature/prosal, and we 
>> still don't think it adequately addresses the needs of subclassing.
>> 
>> The problem with " as function" is that the superclass implicitly 
>> selects nodes based on a CSS selector so unless the nodes a subclass wants 
>> to insert matches exactly what the author of superclass considered, the 
>> subclass won't be able to override it. e.g. if the superclass had an 
>> insertion point with select="input.foo", then it's not possible for a 
>> subclass to then override it with, for example, an input element wrapped in 
>> a span.
>> 
>> > The reason I reverted it from the spec (and the blink), [1], is a 
>> > technical difficulty to implement, though I've not proved that it's 
>> > impossible to implement.
>> 
>> I'm not even arguing about the implementation difficulty. I'm saying that 
>> the semantics is inadequate for subclassing.

> On Apr 28, 2015, at 10:34 AM, Hayato Ito  wrote:
> 
> Could you help me to understand what "implicitly" means here?

I mean that the superclass’ insertion points use a CSS selector to select nodes 
to distribute. As a result, unless the subclass can supply the exactly kinds of 
nodes that matches the CSS selector, it won’t be able to override the contents 
into the insertion point.

> 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”.

The problem is that it may not be possible to coordinate across class hierarchy 
like that if the superclass was defined in a third party library. With the 
named slot approach, superclass only specifies the name of a slot, so subclass 
will be able to override it with whatever element it supplies as needed.

> Could you give me an concrete example which  can support, but 
> " as function" can't support?

The problem isn’t so much that slot can do something " as function" 
can’t support. It’s that " as function" promotes over specification of 
what element can get into its insertion points by the virtue of using a CSS 
selector.

Now, it's possible that we can encourage authors to always use a class name in 
select attribute to support this use case. But then why are we adding a 
capability that we then discourage authors from using it.

- R. Niwa

[Bug 28579] New: [Shadow]:

[bugzilla]

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
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: ty...@tylerlubeck.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 14978

"Any element can host zero of one associated node tree, called shadow tree."


Should this say "Any element can host zero or one associated node trees, called
a shadow tree"?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: Inheritance Model for Shadow DOM Revisited

[Hayato Ito]

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  can support, but
" as function" can't support?


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 Miksovsky, co-author of Apple's proposal, knows
> well that.
>
> We're (and consequently I'm) fully aware of that feature/prosal, and we
> still don't think it adequately addresses the needs of subclassing.
>
> The problem with " as function" is that the superclass implicitly
> selects nodes based on a CSS selector so unless the nodes a subclass wants
> to insert matches exactly what the author of superclass considered, the
> subclass won't be able to override it. e.g. if the superclass had an
> insertion point with select="input.foo", then it's not possible for a
> subclass to then override it with, for example, an input element wrapped in
> a span.
>
> > The reason I reverted it from the spec (and the blink), [1], is a
> technical difficulty to implement, though I've not proved that it's
> impossible to implement.
>
> I'm not even arguing about the implementation difficulty. I'm saying that
> the semantics is inadequate for subclassing.
>
> - R. Niwa
>
>

RE: [components] Isolated Imports and Foreign Custom Elements

[Jonathan Bond-Caron]

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/0024.html
(2) Ability to have the script associated with the component run in a separate 
“world”

An alternative syntax:
http://other-server.example.com/component-library.html";>

Fits in nicely with ES realms/spaces/worlds/add your definition.

Re: Inheritance Model for Shadow DOM Revisited

[Ryosuke Niwa]

> 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 consequently I'm) fully aware of that feature/prosal, and we still 
don't think it adequately addresses the needs of subclassing.

The problem with " as function" is that the superclass implicitly 
selects nodes based on a CSS selector so unless the nodes a subclass wants to 
insert matches exactly what the author of superclass considered, the subclass 
won't be able to override it. e.g. if the superclass had an insertion point 
with select="input.foo", then it's not possible for a subclass to then override 
it with, for example, an input element wrapped in a span.

> The reason I reverted it from the spec (and the blink), [1], is a technical 
> difficulty to implement, though I've not proved that it's impossible to 
> implement.

I'm not even arguing about the implementation difficulty. I'm saying that the 
semantics is inadequate for subclassing.

- R. Niwa

Re: Why is querySelector much slower?

[Boris Zbarsky]

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 results very carefully.


The numbers you see for the getElementById benchmark there are on the 
order of 2e9 operations per second, yes?  And modern desktop/laptop CPUs 
are clocked somewhere in the 2-4 GHz range.  So what you're seeing is 
that the benchmark claims the operation is performed in 1-2 clock 
cycles.  This should seem unlikely if you think the operation involves a 
hashtable lookup!


What's happening there is that Gecko happens to know at JIT compile time 
in this microbenchmark:


1)  The bareword lookup is going to end up at the global, because there 
is nothing on the scope chain that would shadow the "document" name.
2)  The global has an own property named "document" whose getter is 
side-effect-free.
3)  The return value of the "document" property has only been observed 
to be a Document.
4)  Looking up "getElementById" on the return value of the "document" 
property has consistently found it on Document.prototype.

5)  Document.prototype.getElementById is known to be side-effect-free.
6)  The return value of getElementById is not used (assigned to a 
function-local variable that is then not used).


The upshot of all that is that with a few guards both the 
"getElementById" call get and the  "document" get can be dead-code 
eliminated here.  And even if you stored the value somewhere persistent 
they could both still be loop-hoisted in this case.  So what this 
getElementById benchmark measures is how fast a loop counter can be 
decremented from some starting value to 0.  It happens that this can be 
done in about 1-2 clock cycles per loop iteration.


OK, so what about querySelector("#id") vs getElementsByClassName?

In the former case, loop-hoisting and dead code elimination are 
disallowed because querySelector can throw.  That means that you can't 
eliminate it, and you can't move it past other things that might have 
observable side effects (like the counter increment).  Arguably this is 
a misfeature in the design of querySelector.


In the latter case, loop-hoisting or dead code elimination can't happen 
because Gecko doesn't know enough about what [0] will do so assumes the 
worst: that it can have side-effects that can affect what the "document" 
getter returns as well as what the getElementsByClassName() call returns.


So there are no shortcuts here; you have to actually do the calls. What 
do those calls do?


querySelector does a hashtable lookup for the selector to find a parsed 
selector.  Then it sets up some state that's needed for selector 
matching.  Then it detects that the selector's right-hand-most bit has a 
simple ID selector and does a fast path that involves looking up that id 
in the hashtable and then comparing the selector to the elements that 
are returned until one of them matches.


getElementsByClassName has to do a hashtable lookup on the class name, 
then return the result.  Then it has to do the [0] (which is actually 
surprisingly expensive, by the way, because of the proxy machinery 
involved on the JS engine side).


So we _could_ make querySelector faster here by adding another special 
case for selectors that are _just_ an id as opposed to the existing 
optimization (which works for "#foo > #bar" and similar as well).  And 
of course the new special case would only work the way you want for 
document.querySelector, not element.querySelector; the latter needs to 
check for your result being a descendant of the element anyway.  It's a 
tradeoff between complexity of implementation (which has its own 
maintenance _and_ performance costs) and real-life use cases.


Lastly, I'd like to put numbers to this.  On this particular testcase, 
the querySelector("#list") call takes about 100ns on my hardware: about 
300 CPU cycles.  We could add that other set of special-casing and get 
it down to 70ns (I just checked by implementing it, so this is not a 
random guess).  At that point you've got two hashtable lookups (which we 
could try to make faster, perhaps), the logic to detect that the 
optimization can be done at all (which is not that trivial; our selector 
representation requires a bunch of checks to ensure that it's just an id 
selector), and whatever work is involved in the binding layer.  In this 
case, those all seem to have about the same cost; about 17-18ns (50 CPU 
cycles) each.


So is your use case one where the difference between querySelector 
costing 100ns and it costing 70ns actually makes a difference?



It doesn't look like it benefits much from an eagerly populated hash table?


It benefits a good bit for non-toy documents where avoiding walking the 
entire DOM is the important part of the optimization.  Again, 
microbenchmarks mostly s

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

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28353

Koji Ishii  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Koji Ishii  ---
Ah, sorry, I was thinking of table DOM operation but that was not the original
topic. So for rendering of table is defined well with display and anonymous
boxes, so I agree that it should work.

So, what you meant was anything that has mapping to CSS display should work,
but  is not? That I did not read well from your sentence at the first
point, but now make sense. Thank you (and sorry) for explaining twice.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: Why is querySelector much slower?

[Boris Zbarsky]

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?

[Boris Zbarsky]

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 is returned 
without walking the DOM (assuming there are at least two matching elements)?


Yes, exactly.


querySelector("foo") and getElementsByTagName("foo")[0] can return different 
nodes


Still a bit confused regarding this. If the premise is the selector only 
contains characters allowed in a tag name


Then in that case I _think_ those are now equivalent, though I'd have to 
check it carefully.  They didn't use to be back when 
getElementsByTagName was defined as matching on qualified name, not 
localname...


-Boris

Re: Why is querySelector much slower?

[Boris Zbarsky]

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.

This is not too bad if you only have a few lists around, but if you have 
several thousand it can start to hurt.


-Boris

Re: Web Storage Rec errata?

[Arthur Barstow]

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 
status.



Hi Anssi,

Re the priority of this issue, is this mostly a "truth and beauty" 
process-type request or is this issue actually creating a problem(s)? 
(If the later, I would appreciate it, if you would please provide some 
additional context.)


The main thing blocking the publication of errata is a commitment from 
someone to actually do the work. I also think Ian's automatic push of 
commits from the WHATWG version of Web Storage to [2] was stopped a long 
time ago so there could be additional changes to be considered, and the 
totality of changes could include normative changes. Did you check for 
these later changes?


If you, or anyone else, would like to help with this effort, that would 
be great. (If it would be helpful, we could create a new webstorage repo 
under github/w3c/, work on the errata in that repo and redirect the 
CVS-backed errata document to the new repo.)


Personally, I think putting errata in a separate file - as opposed to 
putting changes directly into [1] - is mostly "make work" and fails the 
"principle of least surprise". However, I think the consortium's various 
processes preclude us from doing what I consider is "the right thing".


-Thanks, ArtB



Thanks,

-Anssi

[1]http://www.w3.org/TR/webstorage/
[2]http://dev.w3.org/cvsweb/html5/webstorage/Overview.html

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

[Arthur Barstow]

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 answers and 
after following up a bit I've been informed that the above document is 
obsolete.



Yes, this is true.


It would be very helpful if there was a notice on the page that 
informed it's visitors of the same.



Yes, I agree. I think the "principle of least surprise" implies the 
document at w3.org/TR/selectors-api/ should be gutted of all technical 
content and a reference to the DOM spec [DOM] (which supersede Selectors 
API) should be added (as well as a clear statement work on selectors-api 
has stopped and its features/APIs are superseded by [DOM]). However, I 
suspect the consortium's publication processes might not permit that.


Xiaoqian, Yves - can we do as I suggest above? If not, what is your 
recommendation re making sure people understand work on selectors-api 
has stopped and it is superseded by [DOM]?


-Thanks, AB

[DOM] http://www.w3.org/TR/dom/

Re: Why is querySelector much slower?

[Glen Huang]

> 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 populated hash 
table?

P.S it's very interesting to see Gecko is around 100x faster than others when 
it comes to the performance of getElementById. It probably does something 
unusual?