Re: [webcomponents] How about let's go with slots?

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?

:DG<