Re: [webcomponents] How about let's go with slots?
With respect to Dimitri's *unpacking* notion, we think it can work. In most cases today the redistribution tree is not large; however, if there were a lot of final destination points in that tree, unpacking would be cumbersome because you need to define a slot at every level for every final destination point from that level's perspective. We'd like the working group to explore some short hand syntax for this scenario. The one hypothetical use case we came up with that would be problematic for *unpacking* is dynamic creation of insertion points. This would require dynamic unpacking and that seems pretty ugly since you'd have to break encapsulation to do this. However, the use cases that one can imagine for dynamic insertion points would be better solved by an imperative distribution api anyway and are generally advanced enough that v2 seems ok for them. On Fri, May 15, 2015 at 5:55 PM, Dimitri Glazkov dglaz...@google.com wrote: On Fri, May 15, 2015 at 5:45 PM, Scott Miles sjmi...@google.com wrote: How does it work for redistribution We've done some investigation and think it can work. Note that distributions work just fine with slots. The only thing that doesn't is partial redistributions, and we haven't been able to find a scenario that's a blocker: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Partial-Redistributions-Analysis.md Please, if you can think of one, let's look at it. :DG
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
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. Do you mean instead that we synchronously invoke this algorithm when a child node is inserted or removed from the host? If so, that’ll impose unacceptable runtime cost for DOM mutations. I think the only timing UA can support by default will be at the end of micro task or at UA-code / user-code boundary as done for custom element lifestyle callbacks at the moment. Running this callback at the UA-code/user-code boundary seems like it would be fine. Running the more complicated distribute all the nodes proposals at this time would obviously not be feasible. The notion here is that since we're processing only a single node at a time, this can be done after an atomic dom action. “always correct” is somewhat stronger statement than I would state here since during UA calls these shouldDistributeToInsertionPoint callbacks, we'll certainly see transient offsetHeight values. Yes, you're right about that. Specifically it would be bad to try to read `offsetHeight` in this callback and this would be an anti-pattern. If that's not good enough, perhaps we can explore actually not working directly with the node but instead the subset of information necessary to be able to decide on distribution. Can you explain, under the initial proposal, how a user can ask an element's dimensions and get the post-distribution answer? With current dom api's I can be sure that if I do parent.appendChild(child) and then parent.offsetWidth, the answer takes child into account. I'm looking to understand how we don't violate this expectation when parent distributes. Or if we violate this expectation, what is the proposed right way to ask this question? In addition to rendering information about a node, distribution also effects the flow of events. So a similar question: when is it safe to call child.dispatchEvent such that if parent distributes elements to its shadowRoot, elements in the shadowRoot will see the event? On Mon, Apr 27, 2015 at 1:45 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 27, 2015, at 11:47 AM, Steve Orvell sorv...@google.com wrote: Here's a minimal and hopefully simple proposal that we can flesh out if this seems like an interesting api direction: https://gist.github.com/sorvell/e201c25ec39480be66aa 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? We keep the currently spec'd distribution algorithm/timing but remove `select` in favor of an explicit selection callback. What do you mean by keeping the currently spec’ed timing? We certainly can’t do it at “style resolution time” because style resolution is an implementation detail that we shouldn’t expose to the Web just like GC and its timing is an implementation detail in JS. Besides that, avoiding style resolution is a very important optimizations and spec’ing when it happens will prevent us from optimizing it away in the future/ Do you mean instead that we synchronously invoke this algorithm when a child node is inserted or removed from the host? If so, that’ll impose unacceptable runtime cost for DOM mutations. I think the only timing UA can support by default will be at the end of micro task or at UA-code / user-code boundary as done for custom element lifestyle callbacks at the moment. The user simply returns true if the node should be distributed to the given insertion point. Advantages: * the callback can be synchronous-ish because it acts only on a specific node when possible. Distribution then won't break existing expectations since `offsetHeight` is always correct. “always correct” is somewhat stronger statement than I would state here since during UA calls these shouldDistributeToInsertionPoint callbacks, we'll certainly see transient offsetHeight values. - R. Niwa
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
Again, the timing was deferred in [1] and [2] so it really depends on when each component decides to distribute. I want to be able to create an element x-foo that acts like other dom elements. This element uses Shadow DOM and distribution to encapsulate its details. Let's imagine a 3rd party user named Bob that uses div and x-foo. Bob knows he can call div.appendChild(element) and then immediately ask div.offsetHeight and know that this height includes whatever the added element should contribute to the div's height. Bob expects to be able to do this with the x-foo element also since it is just another element from his perspective. How can I, the author of x-foo, craft my element such that I don't violate Bob's expectations? Does your proposal support this? On Mon, Apr 27, 2015 at 3:42 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 27, 2015, at 3:15 PM, Steve Orvell sorv...@google.com 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. Do you mean instead that we synchronously invoke this algorithm when a child node is inserted or removed from the host? If so, that’ll impose unacceptable runtime cost for DOM mutations. I think the only timing UA can support by default will be at the end of micro task or at UA-code / user-code boundary as done for custom element lifestyle callbacks at the moment. Running this callback at the UA-code/user-code boundary seems like it would be fine. Running the more complicated distribute all the nodes proposals at this time would obviously not be feasible. The notion here is that since we're processing only a single node at a time, this can be done after an atomic dom action. Indeed, running such an algorithm each time node is inserted or removed will be quite expensive. “always correct” is somewhat stronger statement than I would state here since during UA calls these shouldDistributeToInsertionPoint callbacks, we'll certainly see transient offsetHeight values. Yes, you're right about that. Specifically it would be bad to try to read `offsetHeight` in this callback and this would be an anti-pattern. If that's not good enough, perhaps we can explore actually not working directly with the node but instead the subset of information necessary to be able to decide on distribution. I'm not necessarily saying that it's not good enough. I'm just saying that it is possible to observe such a state even with this API. Can you explain, under the initial proposal, how a user can ask an element's dimensions and get the post-distribution answer? With current dom api's I can be sure that if I do parent.appendChild(child) and then parent.offsetWidth, the answer takes child into account. I'm looking to understand how we don't violate this expectation when parent distributes. Or if we violate this expectation, what is the proposed right way to ask this question? You don't get that guarantee in the design we discussed on Friday [1] [2]. In fact, we basically deferred the timing issue to other APIs that observe DOM changes, namely mutation observers and custom elements lifecycle callbacks. Each component uses those APIs to call distribute(). In addition to rendering information about a node, distribution also effects the flow of events. So a similar question: when is it safe to call child.dispatchEvent such that if parent distributes elements to its shadowRoot, elements in the shadowRoot will see the event? Again, the timing was deferred in [1] and [2] so it really depends on when each component decides to distribute. - R. Niwa [1] https://gist.github.com/rniwa/2f14588926e1a11c65d3 [2] https://gist.github.com/annevk/e9e61801fcfb251389ef
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
Perhaps we need to make childrenChanged optionally get called when
attributes of child nodes are changed just like the way you can configure
mutation observers to optionally monitor attribute changes.
Wow, let me summarize if I can. Let's say we have (a) a custom elements
synchronous callback `childrenChanged` that can see child adds/removes and
child attribute mutations, (b) the first option in the proposed api here
https://gist.github.com/rniwa/2f14588926e1a11c65d3, (c) user element code
that wires everything together correctly. Then, unless I am mistaken, we
have enough power to implement something like the currently spec'd
declarative `select` mechanism or the proposed `slot` mechanism without any
change to user's expectations about when information in the dom can be
queried.
Do the implementors think all of that is feasible?
Possible corner case: If a content is added to a shadowRoot, this should
probably invalidate the distribution and redo everything. To maintain a
synchronous mental model, the content mutation in the shadowRoot subtree
needs to be seen synchronously. This is not possible with the tools
mentioned above, but it seems like a reasonable requirement that the
shadowRoot author can be aware of this change since the author is causing
it to happen.
On Mon, Apr 27, 2015 at 7:01 PM, Ryosuke Niwa rn...@apple.com wrote:
On Apr 27, 2015, at 5:43 PM, Steve Orvell sorv...@google.com wrote:
That might be an acceptable mode of operations. If you wanted to
synchronously update your insertion points, rely on custom element's
lifecycle callbacks and you can only support direct children for
distribution.
That's interesting, thanks for working through it. Given a
`childrenChanged` callback, I think your first proposal
`content.insertAt` and `content.remove` best supports a synchronous
mental model. As you note, re-distribution is then the element author's
responsibility. This would be done by listening to the synchronous
`distributionChanged` event. That seems straightforward.
Mutations that are not captured in childrenChanged that can affect
distribution would still be a problem, however. Given:
div id=host
div id=child/div
/div
child.setAttribute('slot', 'a');
host.offsetHeight;
Again, we are guaranteed that parent's offsetHeight includes any
contribution that adding the slot attribute caused (e.g. via a
#child[slot=a] rule)
If the `host` is a custom element that uses distribution, would it be
possible to have this same guarantee?
x-foo id=host
div id=child/div
/x-foo
child.setAttribute('slot', 'a');
host.offsetHeight;
That's a good point. Perhaps we need to make childrenChanged optionally
get called when attributes of child nodes are changed just like the way you
can configure mutation observers to optionally monitor attribute changes.
- R. Niwa
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
Here's a minimal and hopefully simple proposal that we can flesh out if this seems like an interesting api direction: https://gist.github.com/sorvell/e201c25ec39480be66aa We keep the currently spec'd distribution algorithm/timing but remove `select` in favor of an explicit selection callback. The user simply returns true if the node should be distributed to the given insertion point. Advantages: * the callback can be synchronous-ish because it acts only on a specific node when possible. Distribution then won't break existing expectations since `offsetHeight` is always correct. * can implement either the currently spec'd `select` mechanism or the proposed `slot` mechanism * can easily evolve to support distribution to isolated roots by using a pure function that gets read only node 'proxies' as arguments. Disadvantages: * cannot re-order the distribution * cannot distribute sub-elements On Sat, Apr 25, 2015 at 1:58 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 25, 2015, at 1:17 PM, Olli Pettay o...@pettay.fi wrote: On 04/25/2015 09:28 AM, Anne van Kesteren wrote: On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa rn...@apple.com wrote: In today's F2F, I've got an action item to come up with a concrete workable proposal for imperative API. I had a great chat about this afterwards with various people who attended F2F and here's a summary. I'll continue to work with Dimitri Erik to work out details in the coming months (our deadline is July 13th). https://gist.github.com/rniwa/2f14588926e1a11c65d3 I thought we came up with something somewhat simpler that didn't require adding an event or adding remove() for that matter: https://gist.github.com/annevk/e9e61801fcfb251389ef That is pretty much exactly how I was thinking the imperative API to work. (well, assuming errors in the example fixed) An example explaining how this all works in case of nested shadow trees would be good. I assume the more nested shadow tree just may get some nodes, which were already distributed, in the distributionList. Right, that was the design we discussed. How does the distribute() behave? Does it end up invoking distribution in all the nested shadow roots or only in the callee? Yes, that's the only reason we need distribute() in the first place. If we didn't have to care about redistribution, simply exposing methods to insert/remove distributed nodes on content element is sufficient. Should distribute callback be called automatically at the end of the microtask if there has been relevant[1] DOM mutations since the last manual call to distribute()? That would make the API a bit simpler to use, if one wouldn't have to use MutationObservers. That's a possibility. It could be an option to specify as well. But there might be components that are not interested in updating distributed nodes for the sake of performance for example. I'm not certain forcing everyone to always update distributed nodes is necessarily desirable given the lack of experience with an imperative API for distributing nodes. [1] Assuming we want to distribute only direct children, then any child list change or any attribute change in the children might cause distribution() automatically. I think that's a big if now that we've gotten rid of select attribute and multiple generations of shadow DOM. As far as I could recall, one of the reasons we only supported distributing direct children was so that we could implement select attribute and multiple generations of shadow DOM. If we wanted, we could always impose such a restriction in a declarative syntax and inheritance mechanism we add in v2 since those v2 APIs are supposed to build on top of this imperative API. Another big if is whether we even need to let each shadow DOM select nodes to redistribute. If we don't need to support filtering distributed nodes in insertion points for re-distribution (i.e. we either distribute everything under a given content element or nothing), then we don't need all of this redistribution mechanism baked into the browser and the model where we just have insert/remove on content element will work. - R. Niwa
Re: [webcomponents]: The Shadow Cat in the Hat Edition
For context here's another thread about ::part where we start to look a little into the rabbit hole: http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0012.html One wants the expressiveness of css applied to ::part but things get complicated very fast and the 'shadow cat' starts to look a lot more appealing.
Re: [webcomponents]: Naming the Baby
The word component will be used as a synonym for a custom element. Since this spec is designed to load various html resources that may include custom element definitions, attaching the word component to this spec is just confusing. We're loading html so rel=html is most straightforward. The name of the spec should be HTML links. On Wed, Mar 27, 2013 at 10:20 AM, Angelina Fabbro angelinafab...@gmail.comwrote: Just going to drop this in here for discussion. Let's try and get at what a just a component 'is': A gold-standard component: 1. Should do one thing well 2. Should contain all the necessary code to do that one thing (HTML, JS, CSS) 3. Should be modular (and thus reusable) 4. Should be encapsulated 5. (Bonus) Should be as small as it can be I think it follows, then, that a 'web component' is software that fits all of these criteria, but for explicit use in the browser to build web applications. The tools provided - shadow DOM, custom elements etc. give developers tools to create web components. In the case of: link rel=component href=.. I would (as mentioned before) call this a 'component include' as I think this description is pretty apt. It is true that widgets and components are synonymous, but that has been that way for a couple of years now at least already. Widgets, components, modules - they're all interchangeable depending on who you talk to. We've stuck with 'components' to describe things so far. Let's not worry about the synonyms. So far, the developers I've introduced to this subject understood implicitly that they could build widgets with this stuff, all the while I used the term 'components'. Cheers, - A On Tue, Mar 26, 2013 at 10:58 PM, Scott Miles sjmi...@google.com wrote: Forgive me if I'm perseverating, but do you imagine 'component' that is included to be generic HTML content, and maybe some scripts or some custom elements? I'm curious what is it you envision when you say 'component', to test my previous assertion about this word. Scott On Tue, Mar 26, 2013 at 10:46 PM, Angelina Fabbro angelinafab...@gmail.com wrote: 'Component Include' 'Component Include' describes what the markup is doing, and I like that a lot. The syntax is similar to including a stylesheet or a script and so this name should be evocative enough for even a novice to understand what is implied by it. - Angelina On Tue, Mar 26, 2013 at 4:19 PM, Scott Miles sjmi...@google.com wrote: Fwiw, my main concern is that for my team and for lots of other people I communicate with, 'component' is basically synonymous with 'custom element'. In that context, 'component' referring to chunk-of-web-resources-loaded-via-link is problematic, even if it's not wrong, per se. We never complained about this before because Dimitri always wrote the examples as link rel=components... (note the plural). When it was changed to link rel=component... was when the rain began. Scott On Tue, Mar 26, 2013 at 4:08 PM, Ryan Seddon seddon.r...@gmail.comwrote: I like the idea of package seems all encompassing which captures the requirements nicely. That or perhaps resource, but then resource seems singular. Or perhaps component-package so it is obvious that it's tied to web components? -Ryan On Tue, Mar 26, 2013 at 6:03 AM, Dimitri Glazkov dglaz...@google.comwrote: Hello folks! It seems that we've had a bit of informal feedback on the Web Components as the name for the link rel=component spec (cc'd some of the feedbackers). So... these malcontents are suggesting that Web Components is more a of a general name for all the cool things we're inventing, and link rel=component should be called something more specific, having to do with enabling modularity and facilitating component dependency management that it actually does. I recognize the problem, but I don't have a good name. And I want to keep moving forward. So let's come up with a good one soon? As outlined in http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0742.html Rules: 1) must reflect the intent and convey the meaning. 2) link type and name of the spec must match. 3) no biting. :DG
Re: [webcomponents]: Naming the Baby
Err, yeah, thanks for pointing that out. I also like import or imports. This makes sense given that the rel attribute is described as defining the relationship between the resource being loaded and the document (likely outdated spec: http://www.w3.org/TR/html401/struct/links.html#adef-rel). On Wed, Mar 27, 2013 at 11:50 AM, Eric Bidelman ericbidel...@google.comwrote: My association for HTML links is a. Seems too confusing. FWIW, I conducted a small survey to see what the broader community's mental model of this is: https://plus.google.com/u/0/118075919496626375791/posts/3GYkmd4UqLC. Got about 42 responses; the top 3 being: 1. Web Import link rel=import - 14 votes 2. Web Package link rel=package - 6 votes 3. Web Include link rel=include - 5 votes Do we foresee link rel=?? loading other types of resources in the future, not just .html? I like the idea of some sort of import or include, especially seeing that other web developers are aligned with this lingo. My 0$.02 On Wed, Mar 27, 2013 at 11:29 AM, Steve Orvell sorv...@google.com wrote: The word component will be used as a synonym for a custom element. Since this spec is designed to load various html resources that may include custom element definitions, attaching the word component to this spec is just confusing. We're loading html so rel=html is most straightforward. The name of the spec should be HTML links. On Wed, Mar 27, 2013 at 10:20 AM, Angelina Fabbro angelinafab...@gmail.com wrote: Just going to drop this in here for discussion. Let's try and get at what a just a component 'is': A gold-standard component: 1. Should do one thing well 2. Should contain all the necessary code to do that one thing (HTML, JS, CSS) 3. Should be modular (and thus reusable) 4. Should be encapsulated 5. (Bonus) Should be as small as it can be I think it follows, then, that a 'web component' is software that fits all of these criteria, but for explicit use in the browser to build web applications. The tools provided - shadow DOM, custom elements etc. give developers tools to create web components. In the case of: link rel=component href=.. I would (as mentioned before) call this a 'component include' as I think this description is pretty apt. It is true that widgets and components are synonymous, but that has been that way for a couple of years now at least already. Widgets, components, modules - they're all interchangeable depending on who you talk to. We've stuck with 'components' to describe things so far. Let's not worry about the synonyms. So far, the developers I've introduced to this subject understood implicitly that they could build widgets with this stuff, all the while I used the term 'components'. Cheers, - A On Tue, Mar 26, 2013 at 10:58 PM, Scott Miles sjmi...@google.comwrote: Forgive me if I'm perseverating, but do you imagine 'component' that is included to be generic HTML content, and maybe some scripts or some custom elements? I'm curious what is it you envision when you say 'component', to test my previous assertion about this word. Scott On Tue, Mar 26, 2013 at 10:46 PM, Angelina Fabbro angelinafab...@gmail.com wrote: 'Component Include' 'Component Include' describes what the markup is doing, and I like that a lot. The syntax is similar to including a stylesheet or a script and so this name should be evocative enough for even a novice to understand what is implied by it. - Angelina On Tue, Mar 26, 2013 at 4:19 PM, Scott Miles sjmi...@google.comwrote: Fwiw, my main concern is that for my team and for lots of other people I communicate with, 'component' is basically synonymous with 'custom element'. In that context, 'component' referring to chunk-of-web-resources-loaded-via-link is problematic, even if it's not wrong, per se. We never complained about this before because Dimitri always wrote the examples as link rel=components... (note the plural). When it was changed to link rel=component... was when the rain began. Scott On Tue, Mar 26, 2013 at 4:08 PM, Ryan Seddon seddon.r...@gmail.comwrote: I like the idea of package seems all encompassing which captures the requirements nicely. That or perhaps resource, but then resource seems singular. Or perhaps component-package so it is obvious that it's tied to web components? -Ryan On Tue, Mar 26, 2013 at 6:03 AM, Dimitri Glazkov dglaz...@google.com wrote: Hello folks! It seems that we've had a bit of informal feedback on the Web Components as the name for the link rel=component spec (cc'd some of the feedbackers). So... these malcontents are suggesting that Web Components is more a of a general name for all the cool things we're inventing, and link rel=component should be called something more specific, having to do with enabling modularity and facilitating component dependency management that it actually does. I recognize the problem, but I don't have a good
Re: [webcomponents]: First stab at the Web Components spec
Indeed. Unfortunately, using 'module' here could be confusing wrt ES6 modules. Perhaps package is better? The name is difficult. My main point is that using components causes unnecessary confusion. On Fri, Mar 8, 2013 at 12:24 PM, Dimitri Glazkov dglaz...@google.comwrote: On Fri, Mar 8, 2013 at 12:22 PM, Steve Orvell sorv...@google.com wrote: I also find the name confusing. It's common to use the term 'component' when describing the functionality of a custom element. What about HTML Modules? Then we probably need to rename link rel=module for consistency? :DG
Re: [webcomponents]: First stab at the Web Components spec
Also, it sounds like this specification should be titled Fetching components or some such as that's about all it defines. I also find the name confusing. It's common to use the term 'component' when describing the functionality of a custom element. What about HTML Modules? On Fri, Mar 8, 2013 at 1:19 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Mar 7, 2013 at 11:25 PM, Dimitri Glazkov dglaz...@google.com wrote: Please look over it. I look forward to your eagle-eyed insights in the form of bugs and emails. You try to monkey patch the obtain algorithm but in doing so you invoke a different fetch algorithm. One which does not expose resources as CORS-cross-origin. Also, for rel=component tainted resources make no sense, so we should only use No CORS in combination with fail. Why is Component not simply a subclass of Document? If you already have a Document object you might as well use that directly... Also, it sounds like this specification should be titled Fetching components or some such as that's about all it defines. Can't we just put all the component stuff in one specification? I find the whole organization quite confusing. -- http://annevankesteren.nl/
