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
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
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 eith
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:
> addShadowRoo
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.
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_
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
> tre
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 difficul
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);
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
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
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 the
12 matches
Mail list logo
