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: Thu, 8 Nov 2012 10:01:03 -0800
Message-ID: <CAO9Q3i+E6NfphATHT5f=dcLRffzW8MsEavUvBoSLSQwLRAAYRQ@mail.gmail.com>
To: Dimitri Glazkov <dglazkov@google.com>
Cc: Maciej Stachowiak <mjs@apple.com>, public-webapps <public-webapps@w3.org>, Blake Kaplan <mrbkap@mozilla.com>, Jonas Sicking <sicking@mozilla.com>, Boris Zbarsky <bzbarsky@mit.edu>
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.
> >> >>
> >> >
> >
> >
>
Received on Thursday, 8 November 2012 18:40:28 GMT

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