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]: Making Shadow DOM Subtrees Traversable
On Thu, Nov 8, 2012 at 9:26 PM, Boris Zbarsky wrote: > On 11/8/12 9:28 AM, Elliott Sprehn wrote: >> >> If you're worried about malicious attacks on your widget, shadows being >> private is not enough. You need a whole new scripting context. > > Er... yes, you do. Do widgets not get that? If not, that's pretty > broken... Having a separate scripting context is certainly useful for a certain class of widgets (see Like/+1 button discussion). That's why we have this whole notion of the "isolated" shadow trees. This is also a fundamental requirement for enabling UA controls to be built with script (I _just_ had a discussion with a fellow WebKit engineer who asked for that). However, for a large class of use cases, mostly represented by the libraries/frameworks, the separate scripting context is an unnecessary barrier. Libraries like bootstrap, quickui, and x-tags are eager to start using shadow DOM to delineate lightweight, purely functional boundaries between composable bits in the same document. For these developers, where things like: a) examining (and sometimes modifying), say a currently selected tab in an tab manager; b) having a central state stored in the document; c) nesting and reusing bits across different libraries; are all expected and counted upon. Adding a scripting context boundary here is just a "WTF!" stumbling block. :DG<
[Bug 14828] Import Hixie's tests?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14828 Anne changed: What|Removed |Added CC||public-webapps@w3.org Component|DOM |Test suite Assignee|ann...@annevk.nl|dave.n...@w3.org --- Comment #2 from Anne --- Not my problem. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 19917] Split fullscreenchange event into two separate events
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19917 Anne changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NEEDSINFO --- Comment #4 from Anne --- Yes, fullscreenElement is meant to address this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 19917] New: Split fullscreenchange event to two separate events
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19917 Priority: P2 Bug ID: 19917 CC: m...@w3.org, public-webapps@w3.org Assignee: ann...@annevk.nl Summary: Split fullscreenchange event to two separate events QA Contact: public-webapps-bugzi...@w3.org Severity: normal Classification: Unclassified OS: All Reporter: jh.jing...@huawei.com Hardware: PC Status: NEW Version: unspecified Component: Fullscreen Product: WebAppsWG We have defined fullscreenchange event to capture the change of fullscreen (http://www.w3.org/TR/fullscreen/), but in some cases web app needs to know if the document is entering fullscreen or exiting fullscreen. For example, the web app wants to do some operation such as hide some elements or pop up an alert dialog to user when the document is exiting fullscreen , but only applying fullscreenchange event cannot make the app to be sure the document is exiting fullscreen unless web developer provide a trick, such as set a flag to mark the document's status(in fullscreen or out of fullscreen). Therefore, can we split the "fullscreenchange" event to two separate events? One is "fullscreenenter" event which will be invoked when the document is entering fullscreen, another is "fullscreenexit" event which will be invoked when the document is exiting fullscreen. With those two events web developer can create app easily to distinguish condition of entering or exiting fullscreen. -- You are receiving this mail because: You are on the CC list for the bug.
