W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: [webcomponents]: Changing API from constructable ShadowRoot to factory-like

From: Elliott Sprehn <esprehn@google.com>
Date: Fri, 9 Nov 2012 12:32:00 -0800
Message-ID: <CAO9Q3iLW1tPDtJCnyjk9yhNaC3rEbi__rM=WE0xJ0w-t+ajySA@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Erik Arvidsson <arv@chromium.org>, Dimitri Glazkov <dglazkov@google.com>, public-webapps <public-webapps@w3.org>, Blake Kaplan <mrbkap@mozilla.com>, Jonas Sicking <sicking@mozilla.com>, Boris Zbarsky <bzbarsky@mit.edu>
Sounds good to me. :)



On Fri, Nov 9, 2012 at 12:30 PM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> I think a factory function is better here for the reasons Dimitri stated.
> But I also agree that an addFoo function returning a new object seems
> strange. I think that createShadowRoot may be better than either option.
>
>  - Maciej
>
> On Nov 8, 2012, at 11:42 AM, Erik Arvidsson <arv@chromium.org> wrote:
>
> > addShadowRoot seem wrong to me to. Usually add* methods takes an
> > argument of something that is supposed to be added to the context
> > object.
> >
> > If we are going with a factory function I think that createShadowRoot
> > is the right name even though create methods have a lot of bad history
> > in the DOM APIs.
> >
> > On Thu, Nov 8, 2012 at 1:01 PM, Elliott Sprehn <esprehn@google.com>
> wrote:
> >> True, though that's actually one character longer, probably two with
> normal
> >> formatting ;P
> >>
> >> new ShadowRoot(element,{
> >> element.addShadowRoot({
> >>
> >> I'm more concerned about the constructor with irreversible side effects
> of
> >> course.
> >>
> >> - E
> >>
> >>
> >> On Thu, Nov 8, 2012 at 9:57 AM, Dimitri Glazkov <dglazkov@google.com>
> wrote:
> >>>
> >>> That _is_ pretty nice, but we can add this as a second argument to the
> >>> constructor, as well:
> >>>
> >>> root = new ShadowRoot(element, {
> >>>  applyAuthorSheets: false,
> >>>  resetStyleInheritance: true
> >>> });
> >>>
> >>> At this point, the stakes are primarily in aesthetics... Which makes
> >>> the whole question so much more difficult to address objectively.
> >>>
> >>> :DG<
> >>>
> >>> On Thu, Nov 8, 2012 at 9:54 AM, Elliott Sprehn <esprehn@google.com>
> wrote:
> >>>> The real sugar I think is in the dictionary version of addShadowRoot:
> >>>>
> >>>> root = element.addShadowRoot({
> >>>>  applyAuthorSheets: false,
> >>>>  resetStyleInheritance: true
> >>>> })
> >>>>
> >>>>
> >>>> On Thu, Nov 8, 2012 at 9:49 AM, Dimitri Glazkov <dglazkov@google.com>
> >>>> wrote:
> >>>>>
> >>>>> Sure. Here's a simple example without getting into traversable shadow
> >>>>> trees (those are still being discussed in a different thread):
> >>>>>
> >>>>> A1) Using constructable ShadowRoot:
> >>>>>
> >>>>> var element = document.querySelector('div#foo');
> >>>>> // let's add a shadow root to element
> >>>>> var shadowRoot = new ShadowRoot(element);
> >>>>> // do work with it..
> >>>>> shadowRoot.applyAuthorSheets = false;
> >>>>> shadowRoot.appendChild(myDocumentFragment);
> >>>>>
> >>>>> A2) Using addShadowRoot:
> >>>>>
> >>>>> var element = document.querySelector('div#foo');
> >>>>> // let's add a shadow root to element
> >>>>> var shadowRoot = element.addShadowRoot();
> >>>>> // do work with it..
> >>>>> shadowRoot.applyAuthorSheets = false;
> >>>>> shadowRoot.appendChild(myDocumentFragment);
> >>>>>
> >>>>> Now with traversable shadow trees:
> >>>>>
> >>>>> B1) Using constructable ShadowRoot:
> >>>>>
> >>>>> var element = document.querySelector('div#foo');
> >>>>> alert(element.shadowRoot); // null
> >>>>> var root = new ShadowRoot(element);
> >>>>> alert(root === element.shadowRoot); // true
> >>>>> var root2 = new ShadowRoot(element);
> >>>>> alert(root === element.shadowRoot); // false
> >>>>> alert(root2 === element.shadowRoot); // true
> >>>>>
> >>>>> B2) Using addShadowRoot:
> >>>>>
> >>>>> var element = document.querySelector('div#foo');
> >>>>> alert(element.shadowRoot); // null
> >>>>> var root = element.addShadowRoot();
> >>>>> alert(root === element.shadowRoot); // true
> >>>>> var root2 = element.addShadowRoot();
> >>>>> alert(root === element.shadowRoot); // false
> >>>>> alert(root2 === element.shadowRoot); // true
> >>>>>
> >>>>> :DG<
> >>>>>
> >>>>> On Thu, Nov 8, 2012 at 9:42 AM, Maciej Stachowiak <mjs@apple.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> Could you please provide equivalent code examples using both
> >>>>>> versions?
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Maciej
> >>>>>>
> >>>>>> On Nov 7, 2012, at 10:36 AM, Dimitri Glazkov <dglazkov@google.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Folks,
> >>>>>>>
> >>>>>>> Throughout the year-long (whoa!) history of the Shadow DOM spec,
> >>>>>>> various people commented on how odd the constructable ShadowRoot
> >>>>>>> pattern was:
> >>>>>>>
> >>>>>>> var root = new ShadowRoot(host); // both creates an instance *and*
> >>>>>>> makes an association between this instance and host.
> >>>>>>>
> >>>>>>> People (I cc'd most of them) noted various quirks, from the
> >>>>>>> side-effectey constructor to relatively uncommon style of the API.
> >>>>>>>
> >>>>>>> I once was of the strong opinion that having a nice, constructable
> >>>>>>> object has better ergonomics and would overcome the mentioned code
> >>>>>>> smells.
> >>>>>>>
> >>>>>>> But... As we're discussing traversable shadows and the possibility
> >>>>>>> of
> >>>>>>> having Element.shadowRoot, the idea of changing to a factory
> pattern
> >>>>>>> now looks more appealing:
> >>>>>>>
> >>>>>>> var element = document.querySelector('div#foo');
> >>>>>>> alert(element.shadowRoot); // null
> >>>>>>> var root = element.addShadowRoot({ resetStyleInheritance: true });
> >>>>>>> alert(root === element.shadowRoot); // true
> >>>>>>> var root2 = element.addShadowRoot();
> >>>>>>> alert(root === element.shadowRoot); // false
> >>>>>>> alert(root2 === element.shadowRoot); // true
> >>>>>>>
> >>>>>>> You gotta admit this looks very consistent and natural relative to
> >>>>>>> how
> >>>>>>> DOM APIs work today.
> >>>>>>>
> >>>>>>> We could still keep constructable object syntax as alternative
> >>>>>>> method
> >>>>>>> or ditch it altogether and make calling constructor throw an
> >>>>>>> exception.
> >>>>>>>
> >>>>>>> What do you think, folks? In the spirit of last night's events,
> >>>>>>> let's
> >>>>>>> vote:
> >>>>>>>
> >>>>>>> 1) element.addShadowRoot rocks! Let's make it the One True Way!
> >>>>>>> 2) Keep ShadowRoot constructable! Factories stink!
> >>>>>>> 3) Let's have both!
> >>>>>>> 4) element.addShadowRoot, but ONLY if we have traversable shadow
> >>>>>>> trees
> >>>>>>> 5) Kodos.
> >>>>>>>
> >>>>>>> :DG<
> >>>>>>>
> >>>>>>> P.S. I would like to retain the atomic quality of the operation:
> >>>>>>> instantiate+associate in one go. There's a whole forest of problems
> >>>>>>> awaits those who contemplate detached shadow roots.
> >>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
> >
> >
> >
> > --
> > erik
> >
>
>
Received on Friday, 9 November 2012 20:33:08 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:56 GMT