Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Vincent Scheib]

On Wed, May 1, 2013 at 7:00 AM, Anne van Kesteren  wrote:

> On Thu, Apr 11, 2013 at 5:59 PM, Vincent Scheib  wrote:
> > I argue on that issue that we should not bubble the event and have the
> > handler on document only. Pointer lock doesn't have as much legacy spec
> > churn as fullscreen, but I think we're in a position to have both of
> them be
> > cleaned up before un-prefixing.
>
> Okay. Lets kill the bubbling and define the event handlers inline.
> Sorry for the delay.
>

Thanks, sounds good to me. I see and agree with your changes listed here
[1].

I have modified the pointer lock spec to not bubble the events.


> Fullscreen still depends on HTML for  and for
> HTML terminating fullscreen when navigating. Does pointer lock require
> something similar?
>

Pointer lock does use the concept of the sandboxed pointer lock browsing
context flag "allow-pointer-lock"[2], which has been included in whatwg
living HTML.

I'm neutral on the potential argument of defining the sandbox flag inline
as well, it is mentioned & referenced in the pointer lock specification.


This should conclude this thread, "onpointerlockchange/onpointerlockerror
properties defined in the spec".


[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20637#c10
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#sandboxed-pointer-lock-browsing-context-flag

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Anne van Kesteren]

On Thu, Apr 11, 2013 at 5:59 PM, Vincent Scheib  wrote:
> I argue on that issue that we should not bubble the event and have the
> handler on document only. Pointer lock doesn't have as much legacy spec
> churn as fullscreen, but I think we're in a position to have both of them be
> cleaned up before un-prefixing.

Okay. Lets kill the bubbling and define the event handlers inline.
Sorry for the delay.

Fullscreen still depends on HTML for  and for
HTML terminating fullscreen when navigating. Does pointer lock require
something similar?


--
http://annevankesteren.nl/

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Elliott Sprehn]

I'm not sure this makes sense to use futures exclusively. As a library
author you want to know when the page transitions into full screen mode
even if you didn't invoke the requestFullScreen call.

Futures are also not extensible. With an event we could always tack on more
information in the future. With Future we're stuck with that
boolean forever and can't add new information.

It seems like there's a bit too much Future worshiping going on right now.


On Thu, Apr 11, 2013 at 10:48 AM, Anne van Kesteren wrote:

> On Thu, Apr 11, 2013 at 6:38 PM, Boris Zbarsky  wrote:
> > Isn't the thing that matters whether _sites_ have it unprefixed?
>
> I don't know. I believe the browsers don't match each other exactly
> either so there's probably some wiggle room. I suspect transitioning
> at this point to be hard whatever we do, which is probably why it has
> not happened yet.
>
> Also, we dispatch fullscreenchange to more than just the requesting
> document. We could still get rid of fullscreenerror though and have
> the simple non-iframe case be much more friendly towards developers.
>
>
> --
> http://annevankesteren.nl/
>
>

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Vincent Scheib]

On Sat, Mar 16, 2013 at 8:05 AM, Anne van Kesteren  wrote:

> On Fri, Mar 15, 2013 at 6:57 PM, Vincent Scheib  wrote:
> > I have added onipointerlockchange and onpointerlockerror to the partial
> > document IDL in the pointer lock specification.
> >
> > Webkit currently only defines these event handler attributes on document.
> > Unless a reason is raised to add them elsewhere, I do not plan to add
> > additional attributes elsewhere, for reasons discussed in fullscreen
> > specification primarily regarding the confusing when releasing exiting
> due
> > to an element being removed from the DOM, and confusion over multiple
> > listener points.
> >
> > https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html
> > https://dvcs.w3.org/hg/pointerlock/diff/86bc101925d8/index.html
>
> FWIW, in https://www.w3.org/Bugs/Public/show_bug.cgi?id=20637 Ian
> argues for Window/ due to their bubbling nature.
>
> I argue on that issue that we should not bubble the event and have the
handler on document only. Pointer lock doesn't have as much legacy spec
churn as fullscreen, but I think we're in a position to have both of them
be cleaned up before un-prefixing.

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Anne van Kesteren]

On Thu, Apr 11, 2013 at 5:59 PM, Vincent Scheib  wrote:
> I argue on that issue that we should not bubble the event and have the
> handler on document only. Pointer lock doesn't have as much legacy spec
> churn as fullscreen, but I think we're in a position to have both of them be
> cleaned up before un-prefixing.

So how much can we still change fullscreen? It should really use futures.


--
http://annevankesteren.nl/

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Anne van Kesteren]

On Thu, Apr 11, 2013 at 6:38 PM, Boris Zbarsky  wrote:
> Isn't the thing that matters whether _sites_ have it unprefixed?

I don't know. I believe the browsers don't match each other exactly
either so there's probably some wiggle room. I suspect transitioning
at this point to be hard whatever we do, which is probably why it has
not happened yet.

Also, we dispatch fullscreenchange to more than just the requesting
document. We could still get rid of fullscreenerror though and have
the simple non-iframe case be much more friendly towards developers.


--
http://annevankesteren.nl/

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Boris Zbarsky]

On 4/11/13 1:29 PM, Anne van Kesteren wrote:

On Thu, Apr 11, 2013 at 6:23 PM, Anne van Kesteren  wrote:

So how much can we still change fullscreen? It should really use futures.


It seems Gecko and Chrome have it prefixed


Isn't the thing that matters whether _sites_ have it unprefixed?

-Boris

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Anne van Kesteren]

On Thu, Apr 11, 2013 at 6:23 PM, Anne van Kesteren  wrote:
> So how much can we still change fullscreen? It should really use futures.

It seems Gecko and Chrome have it prefixed, barring objections I'm
going to change fullscreen to use futures. That will be way better.


--
http://annevankesteren.nl/

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Anne van Kesteren]

On Fri, Mar 15, 2013 at 6:57 PM, Vincent Scheib  wrote:
> I have added onipointerlockchange and onpointerlockerror to the partial
> document IDL in the pointer lock specification.
>
> Webkit currently only defines these event handler attributes on document.
> Unless a reason is raised to add them elsewhere, I do not plan to add
> additional attributes elsewhere, for reasons discussed in fullscreen
> specification primarily regarding the confusing when releasing exiting due
> to an element being removed from the DOM, and confusion over multiple
> listener points.
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html
> https://dvcs.w3.org/hg/pointerlock/diff/86bc101925d8/index.html

FWIW, in https://www.w3.org/Bugs/Public/show_bug.cgi?id=20637 Ian
argues for Window/ due to their bubbling nature.


-- 
http://annevankesteren.nl/

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Vincent Scheib]

I have added onipointerlockchange and onpointerlockerror to the partial
document IDL in the pointer lock specification.

Webkit currently only defines these event handler attributes on document.
Unless a reason is raised to add them elsewhere, I do not plan to add
additional attributes elsewhere, for reasons discussed in fullscreen
specification primarily regarding the confusing when releasing exiting due
to an element being removed from the DOM, and confusion over multiple
listener points.

https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html
https://dvcs.w3.org/hg/pointerlock/diff/86bc101925d8/index.html



On Thu, Mar 14, 2013 at 12:05 PM, Simon Pieters  wrote:

> On Thu, 10 Jan 2013 18:24:52 +0100, Boris Zbarsky 
> wrote:
>
>  And if so, which objects should they be on?  Window?  Documents?
>>  Elements?
>>
>
> Currently event handlers are available on all of Window, Document and
> HTMLElement even if the relevant event just fires on one of them, so I
> suggest we do that.
>
> --
> Simon Pieters
> Opera Software
>
>

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Simon Pieters]

On Thu, 10 Jan 2013 18:24:52 +0100, Boris Zbarsky  wrote:

And if so, which objects should they be on?  Window?  Documents?   
Elements?


Currently event handlers are available on all of Window, Document and  
HTMLElement even if the relevant event just fires on one of them, so I  
suggest we do that.


--
Simon Pieters
Opera Software

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Boris Zbarsky]

On 1/18/13 5:35 AM, Anne van Kesteren wrote:

I'm not sure that
though that all the splintering is useful long term as you lose track
of what is going on.


This is actually a fairly serious concern, to be honest.  When I was 
recently working on WebIDL bindings for document, I ended up with 
http://hg.mozilla.org/mozilla-central/file/b52c02f77cf5/dom/webidl/Document.webidl#l6 
and even then I have no guarantees that I got them all (though I _did_ 
compare to out existing Gecko IDL for Document and seem to have gotten 
everything that covers).


If I were implementing a UA from scratch, just based on specs and 
without trying to reverse-engineer existing UAs, I would be pretty 
screwed in terms of finding all the bits and interdepedencies, I suspect


The problem is I'm not sure what a good solution to that problem is.  :(

-Boris

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Anne van Kesteren]

On Fri, Jan 18, 2013 at 11:44 AM, Jonas Sicking  wrote:
> This seems like a weird case to optimize for. Refactoring the whole
> event system implementation isn't something that implementors are
> going to do very often. Much less often than implementing new
> specifications hopefully. And definitely not something that reviewers
> or authors will do.

Fair enough. Does not change that HTML is needed anyway for new HTML
attributes and their interaction with other HTML features.

But if we put aside where it is defined, the much more interesting
question still is what we should define. Do we want to follow the HTML
model of exposing these on Window/Document/HTMLElement, or should we
just put them on Document? (And if the latter, how does that compare
to other events that only dispatch on certain objects yet have event
handler attributes everywhere?)


-- 
http://annevankesteren.nl/

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Jonas Sicking]

On Fri, Jan 18, 2013 at 2:35 AM, Anne van Kesteren  wrote:
> On Fri, Jan 18, 2013 at 4:34 AM, Jonas Sicking  wrote:
>> On Thu, Jan 10, 2013 at 1:28 PM, Anne van Kesteren  wrote:
>>> I think HTML should maintain the registry and policy for on*
>>> attributes insofar they concern Window/Document/HTMLElement objects.
>>> http://fullscreen.spec.whatwg.org/ only fires on Document, fwiw.
>>
>> That doesn't seem either scalable or documentation/implementation
>> friendly. It means that someone reading the X feature spec (to
>> implement it, to use it or to review it) will have to also go look at
>> the HTML spec. And know that he/she needs to do so. And it means that
>> the development of the X feature spec is blocked on getting the
>> attention of the HTML spec authors.
>
> Well the other perspective is that someone looking to refactor event
> handlers (as has happened in e.g. Gecko in recent history) has just
> one place to look through.

This seems like a weird case to optimize for. Refactoring the whole
event system implementation isn't something that implementors are
going to do very often. Much less often than implementing new
specifications hopefully. And definitely not something that reviewers
or authors will do.

/ Jonas

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Anne van Kesteren]

On Fri, Jan 18, 2013 at 4:34 AM, Jonas Sicking  wrote:
> On Thu, Jan 10, 2013 at 1:28 PM, Anne van Kesteren  wrote:
>> I think HTML should maintain the registry and policy for on*
>> attributes insofar they concern Window/Document/HTMLElement objects.
>> http://fullscreen.spec.whatwg.org/ only fires on Document, fwiw.
>
> That doesn't seem either scalable or documentation/implementation
> friendly. It means that someone reading the X feature spec (to
> implement it, to use it or to review it) will have to also go look at
> the HTML spec. And know that he/she needs to do so. And it means that
> the development of the X feature spec is blocked on getting the
> attention of the HTML spec authors.

Well the other perspective is that someone looking to refactor event
handlers (as has happened in e.g. Gecko in recent history) has just
one place to look through. Currently HTML defines the allowfullscreen
attribute too and how it interacts with the various other sandboxing
features. Untangling that cleanly is hard and I do not think there is
an obvious right way to do it.


> Isn't this the reason we adding "partial interface" to WebIDL?

One of the main reasons I recall was separating obsoleted features
from non-obsoleted features in HTML. It is of course useful as well
for self-contained extensions drafted elsewhere. I'm not sure that
though that all the splintering is useful long term as you lose track
of what is going on.


-- 
http://annevankesteren.nl/

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Jonas Sicking]

On Thu, Jan 10, 2013 at 1:28 PM, Anne van Kesteren  wrote:
> On Thu, Jan 10, 2013 at 7:19 PM, Vincent Scheib  wrote:
>> Pending agreement to add properties to the fullscreen specification, I agree
>> this should be included in the specification.
>
> I think HTML should maintain the registry and policy for on*
> attributes insofar they concern Window/Document/HTMLElement objects.
> http://fullscreen.spec.whatwg.org/ only fires on Document, fwiw.

That doesn't seem either scalable or documentation/implementation
friendly. It means that someone reading the X feature spec (to
implement it, to use it or to review it) will have to also go look at
the HTML spec. And know that he/she needs to do so. And it means that
the development of the X feature spec is blocked on getting the
attention of the HTML spec authors.

Isn't this the reason we adding "partial interface" to WebIDL?

/ Jonas

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Anne van Kesteren]

On Thu, Jan 10, 2013 at 7:19 PM, Vincent Scheib  wrote:
> Pending agreement to add properties to the fullscreen specification, I agree
> this should be included in the specification.

I think HTML should maintain the registry and policy for on*
attributes insofar they concern Window/Document/HTMLElement objects.
http://fullscreen.spec.whatwg.org/ only fires on Document, fwiw.


-- 
http://annevankesteren.nl/

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Boris Zbarsky]

On 1/10/13 2:02 PM, Vincent Scheib wrote:

I'm confused why HTML should include the properties, and not the
respective specifications.


Other than scope creep?

I am too; see the bug I linked to.

-Boris

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Vincent Scheib]

What objects should these be exposed on? In previous discussions, if I
recall correctly, arguments were made for ~"the spec states the event is
dispatched to the document"~ but also e.g. webkit's implementation of
fullscreen bubbles from the target element, so perhaps you sould be able to
listen on everything. In the webkit pointer lock implementation events go
only to the document.

I suggest we expose the properties only on document, unless someone can
communicate the value of also including them on other elements.

I'm confused why HTML should include the properties, and not the respective
specifications.


On Thu, Jan 10, 2013 at 10:29 AM, Boris Zbarsky  wrote:

> On 1/10/13 1:19 PM, Vincent Scheib wrote:
>
>> The pointer lock specification intentionally mimics the fullscreen
>> specification to provide consistency for developers, as they are similar
>> and expected to be commonly used in the same apps. Neither specification
>> mention event properties.
>>
>
> But HTML5 mentions onfullscreenchange/**onfullscreenerror.  Right now it
> only puts it on window/body/frameset, but not on document or any other
> node.  See 
> https://www.w3.org/Bugs/**Public/show_bug.cgi?id=20637that
>  I filed earlier today.
>
>
>  Mozilla and Chrome implement
>> document.on**fullscreenchange
>> document.on**fullscreenerror
>> document.on**pointerlockchange
>> document.on**pointerlockerror
>>
>
> Mozilla currently puts these properties on all HTML elements and on
> Document and Window, for what it's worth.
>
>
>  Pending agreement to add properties to the fullscreen specification, I
>> agree this should be included in the specification.
>>
>
> Please!
>
> -Boris
>
>

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Boris Zbarsky]

On 1/10/13 1:19 PM, Vincent Scheib wrote:

The pointer lock specification intentionally mimics the fullscreen
specification to provide consistency for developers, as they are similar
and expected to be commonly used in the same apps. Neither specification
mention event properties.


But HTML5 mentions onfullscreenchange/onfullscreenerror.  Right now it 
only puts it on window/body/frameset, but not on document or any other 
node.  See https://www.w3.org/Bugs/Public/show_bug.cgi?id=20637 that I 
filed earlier today.



Mozilla and Chrome implement
document.onfullscreenchange
document.onfullscreenerror
document.onpointerlockchange
document.onpointerlockerror


Mozilla currently puts these properties on all HTML elements and on 
Document and Window, for what it's worth.



Pending agreement to add properties to the fullscreen specification, I
agree this should be included in the specification.


Please!

-Boris

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Vincent Scheib]

[Including Anne & Tantek due to their work on Fullscreen]

The pointer lock specification intentionally mimics the fullscreen
specification to provide consistency for developers, as they are similar
and expected to be commonly used in the same apps. Neither specification
mention event properties.

Mozilla and Chrome implement
document.onfullscreenchange
document.onfullscreenerror
document.onpointerlockchange
document.onpointerlockerror

Pending agreement to add properties to the fullscreen specification, I
agree this should be included in the specification.

On Thu, Jan 10, 2013 at 9:24 AM, Boris Zbarsky  wrote:

> And if so, which objects should they be on?  Window?  Documents?  Elements?
>
> -Boris
>
>

[PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Boris Zbarsky]

And if so, which objects should they be on?  Window?  Documents?  Elements?

-Boris