[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.
[Bug 19917] Split fullscreenchange event into two separate events
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19917 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NEEDSINFO --- Comment #4 from Anne ann...@annevk.nl --- Yes, fullscreenElement is meant to address this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 14828] Import Hixie's tests?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14828 Anne ann...@annevk.nl 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 ann...@annevk.nl --- Not my problem. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Thu, Nov 8, 2012 at 9:26 PM, Boris Zbarsky bzbar...@mit.edu 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
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
