Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
Sure, I'll put the summary of discussion there later. - R. Niwa On Apr 25, 2015, at 10:00 AM, Hayato Ito hay...@chromium.org wrote: Thank you, guys. I really appreciate if you guys could use the W3C bug, 18429, to discuss this kind of specific topic about Shadow DOM so that we can track the progress easily in one place. I'm not fan of the discussion being scattered. :) https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429 On Sat, Apr 25, 2015 at 9:32 AM Anne van Kesteren ann...@annevk.nl 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 I added an example there that shows how you could implement content select, it's rather trivial with the matches() API. I think you can derive any other use case easily from that example, though I'm willing to help guide people through others if it is unclear. I guess we might still want positional insertion as a convenience though the above seems to be all you need primitive-wise. -- https://annevankesteren.nl/
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
Thank you, guys. I really appreciate if you guys could use the W3C bug, 18429, to discuss this kind of specific topic about Shadow DOM so that we can track the progress easily in one place. I'm not fan of the discussion being scattered. :) https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429 On Sat, Apr 25, 2015 at 9:32 AM Anne van Kesteren ann...@annevk.nl 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 I added an example there that shows how you could implement content select, it's rather trivial with the matches() API. I think you can derive any other use case easily from that example, though I'm willing to help guide people through others if it is unclear. I guess we might still want positional insertion as a convenience though the above seems to be all you need primitive-wise. -- https://annevankesteren.nl/
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Apr 25, 2015, at 9:28 AM, Anne van Kesteren ann...@annevk.nl 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: That's the second approach I mentioned. Like I mentioned in the gist, this model assumes that redistribution is done by UA and only direct children can be distributed. I realized that those constraints are no longer necessary given we don't have content select or multiple generations of shadow DOM. https://gist.github.com/annevk/e9e61801fcfb251389ef I added an example there that shows how you could implement content select, it's rather trivial with the matches() API. I think you can derive any other use case easily from that example, though I'm willing to help guide people through others if it is unclear. I guess we might still want positional insertion as a convenience though the above seems to be all you need primitive-wise. -- https://annevankesteren.nl/
RE: Imperative API for Node Distribution in Shadow DOM (Revisited)
Nice work folks, and thanks for writing this up so quickly! Anne's Gist captured exactly what I was thinking this would look like. One nit: it would be nice if the callback could be registered from _inside_ the shadowRoot, but I couldn't come up with a satisfactory way to do that without adding more complexity. :) -Original Message- From: Ryosuke Niwa [mailto:rn...@apple.com] Sent: Saturday, April 25, 2015 10:13 AM To: Anne van Kesteren Cc: WebApps WG; Erik Bryn; Dimitri Glazkov Subject: Re: Imperative API for Node Distribution in Shadow DOM (Revisited) On Apr 25, 2015, at 9:28 AM, Anne van Kesteren ann...@annevk.nl 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: That's the second approach I mentioned. Like I mentioned in the gist, this model assumes that redistribution is done by UA and only direct children can be distributed. I realized that those constraints are no longer necessary given we don't have content select or multiple generations of shadow DOM. https://gist.github.com/annevk/e9e61801fcfb251389ef I added an example there that shows how you could implement content select, it's rather trivial with the matches() API. I think you can derive any other use case easily from that example, though I'm willing to help guide people through others if it is unclear. I guess we might still want positional insertion as a convenience though the above seems to be all you need primitive-wise. -- https://annevankesteren.nl/
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On Apr 25, 2015, at 9:28 AM, Anne van Kesteren ann...@annevk.nl 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
https://gist.github.com/annevk/e9e61801fcfb251389ef
```js
var shadow = host.createShadowRoot({
mode: closed,
distribute: (distributionList, insertionList) = {
for(var i = 0; i distributionList.length; i++) {
for(var ii = 0; ii insertionList.length; ii++) {
var select = insertionList[ii].getAttribute(select)
if(select != null distributionList[i].matches(select)) {
insertionList[ii].add(distrubtionList[i])
} else if(select != null) {
insertionList[ii].add(distrubtionList[i])
}
}
}
}
})
host.shadowRoot.distribute()
```
One major drawback of this API is computing insertionList is expensive because
we'd have to either (where n is the number of nodes in the shadow DOM):
Maintain an ordered list of insertion points, which results in O(n) algorithm
to run whenever a content element is inserted or removed.
Lazily compute the ordered list of insertion points when `distribute` callback
is about to get called in O(n).
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.
- R. Niwa
Re: Minutes of Shadow DOM meeting
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 Title: Web apps Web COmponents meeting -- 24 Apr 2015 - DRAFT - Web apps Web COmponents meeting 24 Apr 2015 Agenda See also: IRC log Attendees Present Chaals, Léonie, Mikeâ¢, AnnevK, Arron, Travis, Hayato, Smaug, DGlazkov, CWilso, AlexR, SamW, Maciej, TedOC, Domenic, Travis_Leithead, AliceBoxhall, WilliamChen, ScottM, ErikBryn, MarkG, SteveOrvell, Misko, WilsonPage, AdamKlein, TaylorSavage Regrets Chair DGlazkov, chaals Scribe chaals Contents Topics Introductions State of consensus and contention Multiple shadow roots per element Default value of "closed shadow tree" Imperative distribution API Seperate event retargeting from style composition Shadow boundary piercing combinators consensus points... what does closed *mean*? Event retargetting Named slots Styling Summary of Action Items Summary of Resolutions Introductions DG: Lots of people here... that's good. ... goal of the meeting is to make sure we move Web Components closer to being interoperable standard (actually shipped...) ... There are some contentious bits on Shadow DOM, and we aim to resolve that here. ... We need to determine what goes into v1 that we can all live with and ship - and put the rest into a v2 ... I would like to leave here not just feeling happy, but actually going to do work and knowing what it will be. ... would like to have champions for the things that we have to do still. ... The goal is to get browsers implementing, but we need experts from the rest of the ecosystem to tell us about their experience too. CW: Chris Wilson - mostly here to find the tea... (Googler) RN: Ryosuke Niwa, Apple AB: Alice Boxhall, Google accessibility - chrome Misko: work on angular.js OP: Smaug from mozilla WC: William Chen, firefox EO: Ted O'Connor, Apple HI: Hayato Ito, work on shadow dom for google and spec it Justin: Work on polymer AvK: Anne, work for Mozilla on standards SW: Sam Weinig, Apple MS: Mike⢠Smith, W3C LJW: Léonie Watson, Paciello Group. CMN: Chaals from Yandex AE: Arron Eichols, MS - work on webapps TL: Travis Leithead - the MS guy EB: Erik Bryn MG: Mark Giffin, writing web components docs for MDN WP: Wilson Page, working with Web Components on firefox OS Jan: Founder of component kitchen MJS: Maciej, webkit at Apple AR: Alex Russell, googler on web platform AK: Adam Klein, V8 at google SM: Scott Miles, work on polymer team TS: Taylor Savage, google SA: Steve Orvell google [polymer team people listening on the phone - we don't let them speak] dfreedm here in irc as well State of consensus and contention DG: Most vendors aside from Google have explained their current position... ... would like to figure out how important contentions are - blocker, useful to have, v1 or v2 or... misko https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits - https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits The collected points of disagreement... Multiple shadow roots per element MJS: Apple thinks this should be removed and replaced with something like the "named slots" proposal. Strongly think this is the case for v1 - better to replace it with something useful or subclassing won't be useful. ... there is a time trade off to replacing it AvK: Mozilla probably don't care strongly for v1 - we would like some solution, and the Apple thing might (or not) work for us... DG: So there is an alternative, which is not the same as "let's drop what we have" TL: For multiple shadow roots, should be removed in v1. You can get a lot done just with a single shadow. I like Apple's proposal simplifying the way content is distributed. Seems
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
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: Imperative API for Node Distribution in Shadow DOM (Revisited)
Thanks. I am really glad to see more and more guys are thinking about Shadow DOM. I know distribution/re-distributions is a tough issue. A lot of exciting things are waiting for you. :) On Sat, Apr 25, 2015 at 10:19 AM Ryosuke Niwa rn...@apple.com wrote: Sure, I'll put the summary of discussion there later. - R. Niwa On Apr 25, 2015, at 10:00 AM, Hayato Ito hay...@chromium.org wrote: Thank you, guys. I really appreciate if you guys could use the W3C bug, 18429, to discuss this kind of specific topic about Shadow DOM so that we can track the progress easily in one place. I'm not fan of the discussion being scattered. :) https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429 On Sat, Apr 25, 2015 at 9:32 AM Anne van Kesteren ann...@annevk.nl 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 I added an example there that shows how you could implement content select, it's rather trivial with the matches() API. I think you can derive any other use case easily from that example, though I'm willing to help guide people through others if it is unclear. I guess we might still want positional insertion as a convenience though the above seems to be all you need primitive-wise. -- https://annevankesteren.nl/
Re: :host pseudo-class
On 4/26/2015 12:32 AM, Anne van Kesteren wrote: I don't understand why :host is a pseudo-class rather than a pseudo-element. My mental model of a pseudo-class is that it allows you to match an element based on a boolean internal slot of that element. :host is not that since e.g. * does not match :host as I understand it. That seems super weird. Why not just use ::host? Copying WebApps since this affects everyone caring about Shadow DOM. My guess is it's because a shadow host element is an element, not a pseudo-element. The reason * doesn't match :host is because the host element, in the context of its shadow tree, is featureless, as mentioned in [1]section 3.1.1 of css-scoping and [2]section 3.3 of selectors-4. Does the following note in css-scoping 3.1.1 answer your question? Why is the shadow host so weird? The shadow host lives outside the shadow tree, and its markup is in control of the page author, not the component author. It would not be very good if a component used a particular class name internally in a shadow tree, and the page author using the component accidentally also used the the same class name and put it on the host element. Such a situation would result in accidental styling that is impossible for the component author to predict, and confusing for the page author to debug. However, there are still some reasonable use-cases for letting a stylesheet in a shadow tree style its host element. So, to allow this situation but prevent accidental styling, the host element appears but is completely featureless and unselectable except through :host. [1]: http://dev.w3.org/csswg/css-scoping-1/#host-element-in-tree [2]: http://dev.w3.org/csswg/selectors-4/#data-model -- Daniel Tan NOVALISTIC http://NOVALISTIC.com
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
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. How does the distribute() behave? Does it end up invoking distribution in all the nested shadow roots or only in the callee? 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. (even then one could skip distribution say for example during page load time and do a page level distribute all the stuff once all the data is ready etc, if wanted.). -Olli [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 added an example there that shows how you could implement content select, it's rather trivial with the matches() API. I think you can derive any other use case easily from that example, though I'm willing to help guide people through others if it is unclear. I guess we might still want positional insertion as a convenience though the above seems to be all you need primitive-wise.
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
On 04/25/2015 01:58 PM, Ryosuke Niwa 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. It is not clear to me at all how you would handle the case when a node has several ancestors with shadow trees, and each of those want to distribute the node to some insertion point. Also, what is the use case to distribute non-direct descendants? 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: Imperative API for Node Distribution in Shadow DOM (Revisited)
Just to clarity, I obviously haven't had a time to discuss this with my
colleagues so I don't know which one (or something else entirely) we (Apple)
end up endorsing/opposing at the end.
On Apr 25, 2015, at 12:14 AM, Ryosuke Niwa rn...@apple.com wrote:
Hi all,
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
https://gist.github.com/rniwa/2f14588926e1a11c65d3
Imperative API for Node Distribution in Shadow DOM
There are two approaches to the problem depending on whether we want to
natively support redistribution or not.
To recap, a redistribution of a node (N_1) happens when it's distributed to
an insertion point (I_1) inside a shadow root (S_1), and I_1's parent also
has a shadow root which contains an insertion point which ends picking up
N_1. e.g. the original tree may look like:
(host of S_1) - S_1
+ N_1 + (host of S_2) - S_2
+ I_1 + I_2
Here, (host of S_1) has N_1 as a child, and (host of S_2) is a child of S_1
and has I_1 as a child. S_2 has I_2 as a child. The composed tree, then, may
look like:
(host of S_1)
+ (host of S_2)
+ I_2
+ N_1
https://gist.github.com/rniwa/2f14588926e1a11c65d3#redistribution-is-implemented-by-authorsRedistribution
is implemented by authors
In this model, we can add insertAt and remove on content element and expose
distributedNodes defined as follows:
insertAt(Node nodeToDistribute, long index) - Inserts nodeToDistribute to the
list of the distributed nodes at index. It throws if nodeToDistribute is not
a descendent (or a direct child if wanted to keep this constraint) of the
shadow host of the ancestor shadow root of containt or if index is larger
than the length of distributedNodes.
remove(Node distributedNode) - Remove distributedNode from the list
distributed nodes. Throws if distributedNodes doesn't contain this node.
distributedNodes - Returns an array of nodes that are distributed into this
insertion point in the order they appear.
In addition, content fires a synchrnous distributionchanged event when
distributedNodeschanges (in response to calls to insertAt or remove).
https://gist.github.com/rniwa/2f14588926e1a11c65d3#prosPros
Very simple / very primitive looking.
Defers the exact mechanism/algorithm of re-distributions to component authors.
We can support distributing any descendent, not just direct children, to any
insertion points. This was not possible with select attribute especially with
the presence of multiple generations of shadow DOM due to perfomance problems.
Allows distributed nodes to be re-ordered (select doesn't allow this).
https://gist.github.com/rniwa/2f14588926e1a11c65d3#consCons
Each component needs to manually implement re-distributions by recursively
traversing through distributedNodes of content elements inside
distributedNodes of the content element if it didn't want to re-distribute
everything. This is particularly challenging because you need to listen to
distributionchanged event on every such content element. We might need
something aking to MutationObserver's subtree option to monitor this if we're
going this route.
It seems hard to support re-distribution natively in v2.
https://gist.github.com/rniwa/2f14588926e1a11c65d3#redistribution-is-implemented-by-uasRedistribution
is implemented by UAs
In this model, the browser is responsible for taking care of redistributions.
Namely, we would like to expose distributionPool on the shadow root which
contains the ordered list of nodes that could be distributed (because they're
direct children of the host) or re-distributed. Conceptually, you could think
of it as a depth first traversal of distributedNodes of every content
element. Because this list contains every candidate for (re)distribution,
it's impractical to include every descendent node especially if we wanted to
do synchronous updates so we're back to supporting only direct children for
distribution.
In this proposal, we add a new callback distributeCallback(NodeList
distributionPool) as an arguemnt (probably inside a dictionary) to
createShadowRoot. e.g.
var shadowRoot = element.createShadowRoot({
distributedCallback: function (distributionPool) {
... // code to distribute nodes
}
});
Unfortunately, we can't really use insertAt and remove in model because
distributionPoolmaybe changed under the foot by (outer) insertion points in
the light DOM if this shadow root to attached to a host inside another shadow
DOM unless we manually listen to distributionchangedevent on every content
(which may recursively
[Shadow DOM] Use Cases for Selective Redistributions
Hi, Could someone give me a concrete use cases for node redistributions where the second and subsequent insertion points need to redistribute a subset of nodes that have been redistributed to an insertion point in an earlier shadow DOM? Maybe someone at Google working on Polymer would have one? Wasn't this feature was needed in inheritance cases when we had multiple generations of shadow DOM (which we just decided to remove from the spec)? If we don't need to redistribute a subset of nodes (at least for the majority of use cases we care about in v1), then we could just not worry about node redistributions in our imperative API. Note that we can redistribute the entire content element just fine since a content element can be distributed along with its distributed nodes as one piece. - R. Niwa
Imperative API for Node Distribution in Shadow DOM (Revisited)
Hi all,
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
https://gist.github.com/rniwa/2f14588926e1a11c65d3
Imperative API for Node Distribution in Shadow DOM
There are two approaches to the problem depending on whether we want to
natively support redistribution or not.
To recap, a redistribution of a node (N_1) happens when it's distributed to an
insertion point (I_1) inside a shadow root (S_1), and I_1's parent also has a
shadow root which contains an insertion point which ends picking up N_1. e.g.
the original tree may look like:
(host of S_1) - S_1
+ N_1 + (host of S_2) - S_2
+ I_1 + I_2
Here, (host of S_1) has N_1 as a child, and (host of S_2) is a child of S_1 and
has I_1 as a child. S_2 has I_2 as a child. The composed tree, then, may look
like:
(host of S_1)
+ (host of S_2)
+ I_2
+ N_1
https://gist.github.com/rniwa/2f14588926e1a11c65d3#redistribution-is-implemented-by-authorsRedistribution
is implemented by authors
In this model, we can add insertAt and remove on content element and expose
distributedNodes defined as follows:
insertAt(Node nodeToDistribute, long index) - Inserts nodeToDistribute to the
list of the distributed nodes at index. It throws if nodeToDistribute is not a
descendent (or a direct child if wanted to keep this constraint) of the shadow
host of the ancestor shadow root of containt or if index is larger than the
length of distributedNodes.
remove(Node distributedNode) - Remove distributedNode from the list distributed
nodes. Throws if distributedNodes doesn't contain this node.
distributedNodes - Returns an array of nodes that are distributed into this
insertion point in the order they appear.
In addition, content fires a synchrnous distributionchanged event when
distributedNodeschanges (in response to calls to insertAt or remove).
https://gist.github.com/rniwa/2f14588926e1a11c65d3#prosPros
Very simple / very primitive looking.
Defers the exact mechanism/algorithm of re-distributions to component authors.
We can support distributing any descendent, not just direct children, to any
insertion points. This was not possible with select attribute especially with
the presence of multiple generations of shadow DOM due to perfomance problems.
Allows distributed nodes to be re-ordered (select doesn't allow this).
https://gist.github.com/rniwa/2f14588926e1a11c65d3#consCons
Each component needs to manually implement re-distributions by recursively
traversing through distributedNodes of content elements inside distributedNodes
of the content element if it didn't want to re-distribute everything. This is
particularly challenging because you need to listen to distributionchanged
event on every such content element. We might need something aking to
MutationObserver's subtree option to monitor this if we're going this route.
It seems hard to support re-distribution natively in v2.
https://gist.github.com/rniwa/2f14588926e1a11c65d3#redistribution-is-implemented-by-uasRedistribution
is implemented by UAs
In this model, the browser is responsible for taking care of redistributions.
Namely, we would like to expose distributionPool on the shadow root which
contains the ordered list of nodes that could be distributed (because they're
direct children of the host) or re-distributed. Conceptually, you could think
of it as a depth first traversal of distributedNodes of every content element.
Because this list contains every candidate for (re)distribution, it's
impractical to include every descendent node especially if we wanted to do
synchronous updates so we're back to supporting only direct children for
distribution.
In this proposal, we add a new callback distributeCallback(NodeList
distributionPool) as an arguemnt (probably inside a dictionary) to
createShadowRoot. e.g.
var shadowRoot = element.createShadowRoot({
distributedCallback: function (distributionPool) {
... // code to distribute nodes
}
});
Unfortunately, we can't really use insertAt and remove in model because
distributionPoolmaybe changed under the foot by (outer) insertion points in the
light DOM if this shadow root to attached to a host inside another shadow DOM
unless we manually listen to distributionchangedevent on every content (which
may recursively appear in distributedNodes of those content).
One way to work around this problem is let UA also propagate changes to
distributionPool to each nested shadow DOM. That is, when distributionPool of a
shadow root gets modified due to changes to distributionPools of direct
children (of the shadow host) that are content elements themselves, UA will
Re: Proposal for changes to manage Shadow DOM content distribution
On Apr 24, 2015, at 2:23 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 22, 2015 at 5:04 PM, Ryosuke Niwa rn...@apple.com wrote: I find it decidedly relevant given I'm pointing out that attribute-specified slots Domenic mentioned isn't what you described. Since the only venue in which attribute-specified slots came up are [1], [2], and [3]. We're DEFINITELY NOT interested in filling slots based on values of arbitrary attributes. [1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0188.html [2] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0190.html [3] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0195.html Apologies, I'd misread [1] and didn't realize it really was talking about projecting the value of an attribute into the content of a slot. (Though I'm confused by the vehemence of your denial here, given that in [2] you said you could imagine that such a feature could be easily added.) What I meant is that we don't want a declarative syntax to filling a slot based with elements based on attribute values of those elements. I'm less concerned about distributing the value of an attribute to a slot based on its attribute name. Regardless, all of this is moot for foreseeable future given we just reached a consensus to focus on an imperative API for v1 on today's F2F. - R. Niwa
Re: Minutes of Shadow DOM meeting
* 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. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
Re: Minutes of Shadow DOM meeting
On 4/25/15 8:45 AM, Bjoern Hoehrmann wrote: * cha...@yandex-team.ru wrote: http://www.w3.org/2015/04/25-webapps-minutes.html See http://www.w3.org/2015/04/24-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.
Re: Minutes of Shadow DOM meeting
On 4/25/15 8:45 AM, Bjoern Hoehrmann wrote: * 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. I just copied the data in the above document to the meeting's agenda page: https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting#Summary_of_Contentious_Bits
Re: Imperative API for Node Distribution in Shadow DOM (Revisited)
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 I added an example there that shows how you could implement content select, it's rather trivial with the matches() API. I think you can derive any other use case easily from that example, though I'm willing to help guide people through others if it is unclear. I guess we might still want positional insertion as a convenience though the above seems to be all you need primitive-wise. -- https://annevankesteren.nl/
:host pseudo-class
I don't understand why :host is a pseudo-class rather than a pseudo-element. My mental model of a pseudo-class is that it allows you to match an element based on a boolean internal slot of that element. :host is not that since e.g. * does not match :host as I understand it. That seems super weird. Why not just use ::host? Copying WebApps since this affects everyone caring about Shadow DOM. -- https://annevankesteren.nl/
