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@gmail.com>
Date: Wed, 7 Nov 2012 10:43:09 -0800
Message-ID: <CAPJYB1jF9aXFpzmeZxCtAy6y+RVdCVbJF+iSxkLEc-PWOW+6CQ@mail.gmail.com>
To: Dimitri Glazkov <dglazkov@google.com>
Cc: public-webapps <public-webapps@w3.org>, Blake Kaplan <mrbkap@mozilla.com>, Jonas Sicking <sicking@mozilla.com>, Elliott Sprehn <esprehn@google.com>, Maciej Stachowiak <mjs@apple.com>, Boris Zbarsky <bzbarsky@mit.edu>
I'm for 1) , having a constructor with side effects is confusing and
inconsistent with the platform (and other languages).



On Wed, 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 Wednesday, 7 November 2012 18:44:20 GMT

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