Re: [webcomponents]: Changing API from constructable ShadowRoot to factory-like
Sorry for the late response.
Adding more "create*" methods feels like a bug. I understand that there are
a couple of concerns/arguments here:
- Current implementations that aren't self-hosting are going to have
trouble with the idea of unattached ("floating") ShadowRoot instances
- As a result, the mental model implementers seem to have is that "new
ShadowRoot(element)" has side-effects *on the element*, and that pretty
clearly feels wrong. A future when re-attaching a ShadowRoot to a different
element solves this (root.attach(element)?), but it's not planned for now.
- "new" may lead to errors when a ShadowRoot instance is allocated out
of one window and an element to attach to is from another. The general DOM
solution of "allocate out of the element's ownerDocument window" feels
right here, but isn't elegant in some corner cases.
So while I still favor something like "new ShadowRoot().attach(element)" or
"new ShadowRoot(element)", I think I can live with the create*() version
for now.
I would like for us to support one of the forward-looking versions,
however, if only in a known-limited form.
On Tue, Nov 20, 2012 at 12:08 AM, Dimitri Glazkov wrote:
> I made the change to the editor's draft:
> http://dvcs.w3.org/hg/webcomponents/rev/e0dfe2ac8104
>
> You can read the shiny new parts of the spec here:
>
> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#extensions-to-element
>
> Please let me know if I goofed up something, preferably by filing bugs :)
>
> :DG<
>
>
Re: [webcomponents]: Changing API from constructable ShadowRoot to factory-like
I made the change to the editor's draft: http://dvcs.w3.org/hg/webcomponents/rev/e0dfe2ac8104 You can read the shiny new parts of the spec here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#extensions-to-element Please let me know if I goofed up something, preferably by filing bugs :) :DG<
Re: [webcomponents]: Changing API from constructable ShadowRoot to factory-like
Sounds good to me. :)
On Fri, Nov 9, 2012 at 12:30 PM, Maciej Stachowiak 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 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
> 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
> 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
> 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
> 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
> > wrote:
> >>
> >> Could you please provide equivalent code examples using both
> >> versions?
> >>
> >> Cheers,
> >> Maciej
> >>
> >> On Nov 7, 2012, at 10:36 AM, Dimitri Glazkov
> >> 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 });
>
Re: [webcomponents]: Changing API from constructable ShadowRoot to factory-like
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 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 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 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 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
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
> wrote:
>>
>> Could you please provide equivalent code examples using both
>> versions?
>>
>> Cheers,
>> Maciej
>>
>> On Nov 7, 2012, at 10:36 AM, Dimitri Glazkov
>> 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.
>>>
Re: [webcomponents]: Changing API from constructable ShadowRoot to factory-like
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 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 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 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
>> > 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
>> >> wrote:
>> >> >
>> >> > Could you please provide equivalent code examples using both
>> >> > versions?
>> >> >
>> >> > Cheers,
>> >> > Maciej
>> >> >
>> >> > On Nov 7, 2012, at 10:36 AM, Dimitri Glazkov
>> >> > 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.a
Re: [webcomponents]: Changing API from constructable ShadowRoot to factory-like
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 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 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
> 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
> wrote:
> >> >
> >> > Could you please provide equivalent code examples using both versions?
> >> >
> >> > Cheers,
> >> > Maciej
> >> >
> >> > On Nov 7, 2012, at 10:36 AM, Dimitri Glazkov
> >> > 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.
> >> >>
> >> >
> >
> >
>
Re: [webcomponents]: Changing API from constructable ShadowRoot to factory-like
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 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 wrote:
> >
> > Could you please provide equivalent code examples using both versions?
> >
> > Cheers,
> > Maciej
> >
> > On Nov 7, 2012, at 10:36 AM, Dimitri Glazkov
> 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.
> >>
> >
>
Re: [webcomponents]: Changing API from constructable ShadowRoot to factory-like
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 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 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 wrote:
>> >
>> > Could you please provide equivalent code examples using both versions?
>> >
>> > Cheers,
>> > Maciej
>> >
>> > On Nov 7, 2012, at 10:36 AM, Dimitri Glazkov
>> > 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.
>> >>
>> >
>
>
Re: [webcomponents]: Changing API from constructable ShadowRoot to factory-like
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 wrote:
>
> Could you please provide equivalent code examples using both versions?
>
> Cheers,
> Maciej
>
> On Nov 7, 2012, at 10:36 AM, Dimitri Glazkov 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.
>>
>
Re: [webcomponents]: Changing API from constructable ShadowRoot to factory-like
Could you please provide equivalent code examples using both versions?
Cheers,
Maciej
On Nov 7, 2012, at 10:36 AM, Dimitri Glazkov 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.
>
Re: [webcomponents]: Changing API from constructable ShadowRoot to factory-like
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 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.
>
>
[webcomponents]: Changing API from constructable ShadowRoot to factory-like
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.
