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

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

From: Dimitri Glazkov <dglazkov@google.com>
Date: Thu, 8 Nov 2012 09:57:54 -0800
Message-ID: <CADh5Ky10WrtsEUX5-O0JLi8QossHmmCWh7kzzdK3fB0frEmSsw@mail.gmail.com>
To: Elliott Sprehn <esprehn@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>
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 17:58:15 GMT

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