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 dglaz...@google.comwrote: 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
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 a...@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 espr...@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 dglaz...@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 espr...@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 dglaz...@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 m...@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 dglaz...@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:
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 m...@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 a...@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 espr...@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 dglaz...@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 espr...@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 dglaz...@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 m...@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 dglaz...@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
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 dglaz...@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.
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 m...@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 dglaz...@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.
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 espr...@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 dglaz...@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 m...@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 dglaz...@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.
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 dglaz...@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 m...@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 dglaz...@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.
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 dglaz...@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 espr...@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 dglaz...@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 m...@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 dglaz...@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.
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 espr...@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 dglaz...@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 espr...@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 dglaz...@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 m...@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 dglaz...@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
[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.
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 dglaz...@google.comwrote:
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.
