>From experience building components for Firefox OS I think the 'default slot' pattern will fulfill most of our use-cases. This means we won't have to burden our component users by requiring them to add `slot="foo"` all over the place. Is it fair to say that if this declarative API lands in V1, it's unlikely we'll see imperative API in V2? Have we not exhausted all the options? On Thu, May 21, 2015 at 6:45 PM, Dimitri Glazkov <dglazkov@google.com> wrote: > > > On Thu, May 21, 2015 at 10:22 AM, Travis Leithead < > travis.leithead@microsoft.com> wrote: > >> This works for me too. >> >> And I like the proposed new bikeshed-ed names Anne suggests below. >> > > SG. Started a proposal stub here: > https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Slots-Proposal.md > > :DG< > > >> >> -----Original Message----- >> From: Anne van Kesteren [mailto:annevk@annevk.nl] >> Sent: Wednesday, May 20, 2015 9:10 PM >> To: Dimitri Glazkov >> Cc: Scott Miles; Ryosuke Niwa; Edward O'Connor; Travis Leithead; Maciej >> Stachowiak; Arron Eicholz; public-webapps >> Subject: Re: [webcomponents] How about let's go with slots? >> >> On Tue, May 19, 2015 at 3:18 AM, Dimitri Glazkov <dglazkov@google.com> >> wrote: >> > 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? >> >> This probably works for Mozilla. It would be good to see the proposed >> processing model and its implications for an eventual imperative API. >> It's somewhat troubling we don't agree on synchronous vs >> when-layout-or-event-dispatch-happens. >> >> Also, I suggest we bikeshed the markup in the direction of >> slot=some-slot-name and <slot name=some-slot-name> rather than >> content-slot=some-slot-name and <content slot=some-slot-name>. >> >> >> -- >> https://annevankesteren.nl/ >> > >
Received on Friday, 22 May 2015 06:34:20 UTC