- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Mon, 18 May 2015 15:35:16 -0700
- To: Dimitri Glazkov <dglazkov@google.com>
- Cc: Scott Miles <sjmiles@google.com>, Edward O'Connor <eoconnor@apple.com>, Anne van Kesteren <annevk@annevk.nl>, Travis Leithead <travis.leithead@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, Arron Eicholz <arronei@microsoft.com>, public-webapps <public-webapps@w3.org>, Jan Miksovsky <jan@component.kitchen>
> On May 18, 2015, at 11:18 AM, Dimitri Glazkov <dglazkov@google.com> wrote: > > On Fri, May 15, 2015 at 4:58 PM, Scott Miles <sjmiles@google.com> wrote: >> Polymer really wants Shadow DOM natively, and we think the `slot` proposal can work, so maybe let's avoid blocking on design of an imperative API (which we still should make in the long run). >> >> As our entire stack is built on Web Components, the Polymer team is highly motivated to assist browser implementers come to agreement on a Shadow DOM specification. Specifically, as authors of the `webcomponents-js` polyfills, and more than one Shadow DOM shim, we are keenly aware of how difficult Shadow DOM is to simulate without true native support. >> >> I believe we are in general agreement with the implementers that an imperative API, especially one that cleanly explains platform behavior, is an ideal end point for Shadow DOM distribution. However, as has been discussed at length, it’s likely that a proper imperative API is blocked on other still-to-mature technologies. For this reason, we would like for the working group to focus on writing the spec for the declarative `slot` proposal [1]. We're happy to participate in the process. >> >> [1]: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution.md#proposal-part-1-syntax-for-named-insertion-points >> > It sounds like we are no longer in disagreement on the "F. Slots Proposal" item from the April 2015 Meeting (https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting), so we don't need to block it on the "C. The imperative distribution API" item. > > Given that all vendors agreed that "C" can wait until v2, we could just focus on concretizing the "slots" proposal and then put a lid on Shadow DOM v1. > > What do you think, folks? We (Apple) support focusing on the slot proposal and deferring the imperative API to v2 or at least not blocking the discussion for the named slots. - R. Niwa
Received on Monday, 18 May 2015 22:35:46 UTC