- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Wed, 29 Apr 2015 18:06:57 -0700
- To: Justin Fagnani <justinfagnani@google.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Dimitri Glazkov <dglazkov@google.com>, Anne van Kesteren <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>, Erik Bryn <erik@erikbryn.com>, Edward O'Connor <eoconnor@apple.com>
> On Apr 29, 2015, at 5:12 PM, Justin Fagnani <justinfagnani@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
Received on Thursday, 30 April 2015 01:07:27 UTC