Re: Why is querySelector much slower?
On 4/29/15 12:23 AM, Glen Huang wrote: 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? No, it's the cost introduced by needing custom property behavior for integer-named properties on lists (and in particular the need to have them appear and disappear, not be redefinable, and so forth). The upshot in the SpiderMonkey implementation is that the list object is a proxy in the ES6 sense, which makes the [0] access take a slower path through the JS engine than I'd like. -Boris
FYI: First Public Working Draft of Web Payments Use Cases
Dear Web Apps Working Group, On 16 April 2015, the W3C Web Payments Interest Group [1] published: Web Payments Use Cases 1.0 http://www.w3.org/TR/web-payments-use-cases/ This document is a prioritized list of Web payments use cases. Guided by these use cases, the W3C Web Payments Interest Group plans to derive architecture and associated technology requirements to integrate payments into the Open Web Platform. We invite your feedback on public-webpayments-comme...@w3.org to help us improve the document. Please note that comments sent to that list are publicly archived [2]. The Interest Group holds its next face-to-face meeting 16-18 June when we plan to process early feedback on this draft. Any feedback you have by early June would be greatly appreciated. We will also let you know about opportunities for early feedback on subsequent documents (architecture and requirements). To learn more about this group's goals and the anticipated benefits of improved payments on the Web, please see: https://www.w3.org/Payments/IG/wiki/ExecSummary Thank you, Ian Jacobs, W3C Web Payments Activity Lead [1] http://www.w3.org/Payments/IG/ [2] https://lists.w3.org/Archives/Public/public-webpayments-comments/ -- Ian Jacobs i...@w3.org http://www.w3.org/People/Jacobs Tel: +1 718 260 9447
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Wed, Apr 29, 2015 at 4:15 PM, Dimitri Glazkov dglaz...@google.com wrote: On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa rn...@apple.com wrote: 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 their solution, multiple generations of shadow DOM, may not be as great as they thought it would be. Given that, I'm quite terrified of making the same mistake in spec'ing how distribution works and later regretting it. At least the way I understand it, multiple shadow roots per element and distributions are largely orthogonal bits of machinery that solve largely orthogonal problems. Yes. Distribution is mainly about making composition of components work seamlessly, so you can easily pass elements from your light dom into some components you're using inside your shadow dom. Without distribution, you're stuck with either: * avoiding content entirely and literally moving the elements from the light dom to your shadow tree (like, appendChild() the nodes themselves), which means the outer page no longer has access to the elements for their own styling or scripting purposes (this is terribad, obviously), or * components have to be explicitly written with the expectation of being composed into other components, writing their own content select *to target the content elements of the outer shadow*, which is also extremely terribad. Distribution makes composition *work*, in a fundamental way. Without it, you simply don't have the ability to use components inside of components except in special cases. ~TJ
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Wed, Apr 29, 2015 at 4:47 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 29, 2015, at 4:37 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 29, 2015 at 4:15 PM, Dimitri Glazkov dglaz...@google.com wrote: On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa rn...@apple.com wrote: 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 their solution, multiple generations of shadow DOM, may not be as great as they thought it would be. Given that, I'm quite terrified of making the same mistake in spec'ing how distribution works and later regretting it. At least the way I understand it, multiple shadow roots per element and distributions are largely orthogonal bits of machinery that solve largely orthogonal problems. Yes. Distribution is mainly about making composition of components work seamlessly, so you can easily pass elements from your light dom into some components you're using inside your shadow dom. Without distribution, you're stuck with either: As I clarified my point in another email, neither I nor anyone else is questioning the value of the first-degree of node distribution from the light DOM into insertion points of a shadow DOM. What I'm questioning is the value of the capability to selectively re-distribute those nodes in a tree with nested shadow DOMs. * components have to be explicitly written with the expectation of being composed into other components, writing their own content select *to target the content elements of the outer shadow*, which is also extremely terribad. Could you give me a concrete use case in which such inspection of content elements in the light DOM is required without multiple generations of shadow DOM? In all the use cases I've studied without multiple generations of shadow DOM, none required the ability to filter nodes inside a content element. Distribution makes composition *work*, in a fundamental way. Without it, you simply don't have the ability to use components inside of components except in special cases. Could you give us a concrete example in which selective re-distribution of nodes are required? That'll settle this discussion/question altogether. I'll let a Polymer person provide a concrete example, as they're the ones that originally brought up redistribution and convinced us it was needed, but imagine literally any component that uses more than one content (so you can't get away with just distributing the content element itself), being used inside of some other component that wants to pass some of its light-dom children to the nested component. Without redistribution, you can only nest components (using one component inside the shadow dom of another) if you either provide contents directly to the nested component (no content) or the nested component only has a single distribution point in its own shadow. ~TJ
Re: Nice version Re: Minutes of Shadow DOM meeting
Will do. :DG On Sun, Apr 26, 2015 at 2:08 AM, cha...@yandex-team.ru wrote: Attached here is a clean version, which will be archived. Note that there was a lot of sidechat in IRC it is unclear how much of that everyone in the room was aware of. I hope the minutes are a pretty accurate record now, but if people feel otherwise I hope they say so. I'll link this version to the meeting page in the wiki: https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting Dimitri, can you please forward the link to attendees who are not members of webapps? cheers 26.04.2015, 00:14, cha...@yandex-team.ru cha...@yandex-team.ru: 25.04.2015, 14:45, Bjoern Hoehrmann derhoe...@gmx.net: * cha...@yandex-team.ru wrote: We'll post a summary - there is most of one at https://docs.google.com/spreadsheets/d/1hnCoaJTXkfSSHD5spISJ76nqbDcOVNMamgByiz3QWLA/edit?pli=1#gid=0 Perhaps a document in some kind of open format would be a better medium than some proprietary application with unclear stability policies that does not work in my browser. The minutes (thanks to Taylor Savage fora great scribing job) are at http://www.w3.org/2015/04/25-webapps-minutes.html That contains just a few lines. Looks like the decade-old UTC day change bug is still plaguing the minutes generation tool. Sigh. Well, alternatively it is the decades-old scribe forgetting to do the thing right… I'll put together the minutes and repost them shortly. I've attached a rough version but I'll need to do some more cleaning because I made a mess halfway through. The content is there and legible at least… -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de cheers -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru - - - Find more at http://yandex.com -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru - - - Find more at http://yandex.com
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
Here's one case of redistribution: https://github.com/Polymer/core-scaffold/blob/master/core-scaffold.html#L122 Any time you see content inside a custom element it's potentially redistribution. Here there's on that is (line 122), and one that could be (line 116), and one that definitely isn't (line 106). I personally think that Hayato's analogy to function parameters is very motivating. Arguing from use-cases at this point is going to miss many things because so far we've focused on the most simple of components, are having to rewrite them for Polymer 0.8, and haven't seen the variety and complexity of cases that will evolve naturally from the community. General expressiveness is extremely important when you don't have an option to work around it - redistribution is one of these cases. Cheers, Justin On Wed, Apr 29, 2015 at 4:57 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 29, 2015 at 4:47 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 29, 2015, at 4:37 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 29, 2015 at 4:15 PM, Dimitri Glazkov dglaz...@google.com wrote: On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa rn...@apple.com wrote: 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 their solution, multiple generations of shadow DOM, may not be as great as they thought it would be. Given that, I'm quite terrified of making the same mistake in spec'ing how distribution works and later regretting it. At least the way I understand it, multiple shadow roots per element and distributions are largely orthogonal bits of machinery that solve largely orthogonal problems. Yes. Distribution is mainly about making composition of components work seamlessly, so you can easily pass elements from your light dom into some components you're using inside your shadow dom. Without distribution, you're stuck with either: As I clarified my point in another email, neither I nor anyone else is questioning the value of the first-degree of node distribution from the light DOM into insertion points of a shadow DOM. What I'm questioning is the value of the capability to selectively re-distribute those nodes in a tree with nested shadow DOMs. * components have to be explicitly written with the expectation of being composed into other components, writing their own content select *to target the content elements of the outer shadow*, which is also extremely terribad. Could you give me a concrete use case in which such inspection of content elements in the light DOM is required without multiple generations of shadow DOM? In all the use cases I've studied without multiple generations of shadow DOM, none required the ability to filter nodes inside a content element. Distribution makes composition *work*, in a fundamental way. Without it, you simply don't have the ability to use components inside of components except in special cases. Could you give us a concrete example in which selective re-distribution of nodes are required? That'll settle this discussion/question altogether. I'll let a Polymer person provide a concrete example, as they're the ones that originally brought up redistribution and convinced us it was needed, but imagine literally any component that uses more than one content (so you can't get away with just distributing the content element itself), being used inside of some other component that wants to pass some of its light-dom children to the nested component. Without redistribution, you can only nest components (using one component inside the shadow dom of another) if you either provide contents directly to the nested component (no content) or the nested component only has a single distribution point in its own shadow. ~TJ
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa rn...@apple.com wrote: 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 their solution, multiple generations of shadow DOM, may not be as great as they thought it would be. Given that, I'm quite terrified of making the same mistake in spec'ing how distribution works and later regretting it. At least the way I understand it, multiple shadow roots per element and distributions are largely orthogonal bits of machinery that solve largely orthogonal problems. :DG
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Tue, Apr 28, 2015 at 1:52 PM, Ryosuke Niwa rn...@apple.com wrote: 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. Thank you for doing this. There are a couple of unescaped tags in https://gist.github.com/rniwa/2f14588926e1a11c65d3#extention-to-custom-elements-for-consistency, I think? Any chance you could move it to the Web Components wiki? That way, we could all collaborate. :DG
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Apr 29, 2015, at 4:37 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 29, 2015 at 4:15 PM, Dimitri Glazkov dglaz...@google.com wrote: On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa rn...@apple.com wrote: 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 their solution, multiple generations of shadow DOM, may not be as great as they thought it would be. Given that, I'm quite terrified of making the same mistake in spec'ing how distribution works and later regretting it. At least the way I understand it, multiple shadow roots per element and distributions are largely orthogonal bits of machinery that solve largely orthogonal problems. Yes. Distribution is mainly about making composition of components work seamlessly, so you can easily pass elements from your light dom into some components you're using inside your shadow dom. Without distribution, you're stuck with either: As I clarified my point in another email, neither I nor anyone else is questioning the value of the first-degree of node distribution from the light DOM into insertion points of a shadow DOM. What I'm questioning is the value of the capability to selectively re-distribute those nodes in a tree with nested shadow DOMs. * components have to be explicitly written with the expectation of being composed into other components, writing their own content select *to target the content elements of the outer shadow*, which is also extremely terribad. Could you give me a concrete use case in which such inspection of content elements in the light DOM is required without multiple generations of shadow DOM? In all the use cases I've studied without multiple generations of shadow DOM, none required the ability to filter nodes inside a content element. Distribution makes composition *work*, in a fundamental way. Without it, you simply don't have the ability to use components inside of components except in special cases. Could you give us a concrete example in which selective re-distribution of nodes are required? That'll settle this discussion/question altogether. - R. Niwa
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Apr 29, 2015, at 4:16 PM, Dimitri Glazkov dglaz...@google.com wrote: On Tue, Apr 28, 2015 at 1:52 PM, Ryosuke Niwa rn...@apple.com wrote: 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. Thank you for doing this. There are a couple of unescaped tags in https://gist.github.com/rniwa/2f14588926e1a11c65d3#extention-to-custom-elements-for-consistency, I think? Any chance you could move it to the Web Components wiki? That way, we could all collaborate. Sure, what's the preferred work flow? Fork and push a PR? - R. Niwa.
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Wed, Apr 29, 2015 at 5:59 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 29, 2015, at 4:16 PM, Dimitri Glazkov dglaz...@google.com wrote: On Tue, Apr 28, 2015 at 1:52 PM, Ryosuke Niwa rn...@apple.com wrote: 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. Thank you for doing this. There are a couple of unescaped tags in https://gist.github.com/rniwa/2f14588926e1a11c65d3#extention-to-custom-elements-for-consistency, I think? Any chance you could move it to the Web Components wiki? That way, we could all collaborate. Sure, what's the preferred work flow? Fork and push a PR? Actually, we might need to figure this out first. Github Wiki is not super-friendly to fork/push-PR model. But I do like your idea. Maybe just an .md page in a repo? - R. Niwa.
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Apr 29, 2015, at 5:12 PM, Justin Fagnani justinfagn...@google.com wrote: Here's one case of redistribution: https://github.com/Polymer/core-scaffold/blob/master/core-scaffold.html#L122 Any time you see content inside a custom element it's potentially redistribution. Here there's on that is (line 122), and one that could be (line 116), and one that definitely isn't (line 106). Thank you very much for an example. I'm assuming core-header-panel is [1]? It grabs core-toolbar. It looks to me that we could also replace line 122 with: ```html content class=.core-header select=core-toolbar, .core-header/content content select=*/content ``` and you wouldn't need redistribution. I wouldn't argue that it provides a better developer ergonomics but there's a serious trade off here. If we natively supported redistribution and always triggered via `distribute` callback, then it may not be acceptable to invoke `distribute` on every DOM change in terms of performance since that could easily result in O(n^2) behavior. This is why the proposal we (Anne, I, and others) discussed involved using mutation observers instead of childrenChanged lifecycle callbacks. Now, frameworks such as Polymer could provide a sugar on top of it by automatically re-distributing nodes as needed when implementing your select attribute. I personally think that Hayato's analogy to function parameters is very motivating. Arguing from use-cases at this point is going to miss many things because so far we've focused on the most simple of components, are having to rewrite them for Polymer 0.8, and haven't seen the variety and complexity of cases that will evolve naturally from the community. General expressiveness is extremely important when you don't have an option to work around it - redistribution is one of these cases. Evaluating each design proposal based on a concrete use case is extremely important precisely because we might miss out on expressiveness in some cases as we're stripping down features, and we can't reject a proposal or add a feature for a hypothetical/theoretical need. [1] https://github.com/Polymer/core-header-panel/blob/master/core-header-panel.html - R. Niwa
Re: Inheritance Model for Shadow DOM Revisited
Thanks. As far as my understanding is correct, the conclusions so far are: - There is no use cases which shadow as function can't support, but content slot can support. - there are use cases which shadow as function can support, but content slot can't support. - shadow as function is more expressive than content slot - content slot is trying to achieve something by removing expressiveness from web developers, instead of trusting them. I still don't understand fully what the proposal is trying to achieve. I've never heard such a complain, content select is too expressive and easy to be misused. Please remove it, from web developers. I think any good APIs could be potentially wrongly used by a web developer. But that shouldn't be a reason that we can remove a expressive API from web developers who can use it correctly and get benefits from the expressiveness. On Wed, Apr 29, 2015 at 3:52 AM Ryosuke Niwa rn...@apple.com wrote: On Wed, Apr 29, 2015 at 2:09 AM Ryosuke Niwa rn...@apple.com wrote: On Apr 27, 2015, at 9:50 PM, Hayato Ito hay...@chromium.org wrote: The feature of shadow 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 shadow 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 hay...@chromium.org 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 content select=.input-foo 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 content slot can support, but shadow as function can't support? The problem isn’t so much that slot can do something shadow as function can’t support. It’s that shadow 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
