Re: Pointer Lock status. Was: pointerLock vendor prefixes, shims and usability

[Florian Bösch]

I should note that I do have an application in the oven that could serve as
a usecase study for non fullscreen pointerlock UX/issues (it uses
pointerlock in different portions of its functionality to improve
usability).

It's currently not ready for release, but upon request I can arrange for a
personal preview, and I plan to make a first release soon.


On Fri, Jan 4, 2013 at 7:04 PM, Vincent Scheib  wrote:

> On Fri, Jan 4, 2013 at 4:49 AM, Arthur Barstow wrote:
>
>> Hi Vincent,
>>
>> Seeing this discussion, and noting two open [Bugz], I was wondering about
>> the plan to get this spec to a feature complete status (and hence ready for
>> Last Call Working Draft). Would you please provide a short status/plan for
>> Pointer Lock spec vis-à-vis LCWD?
>>
>> -Thanks, AB
>>
>> [Bugz] > WebAppsWG&component=Pointer%**20Lock&resolution=---&list_id=**3760
>> >
>
>
> The discussion about how easily javascript shims can be created is
> orthogonal to the pointer lock spec. I'll leave that discussion on that
> thread, which I note has concluded in "pointer lock has apparently already
> been shimmed".
>
> Of the two open issues, one [1] was already resolved (adding
> allow-pointer-lock to HTML). I've closed the issue.
>
> The other [2] is blocked on Mozilla's security review [3].
>
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18647
> [2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19297
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=822654
>
>

Pointer Lock status. Was: pointerLock vendor prefixes, shims and usability

[Vincent Scheib]

On Fri, Jan 4, 2013 at 4:49 AM, Arthur Barstow wrote:

> Hi Vincent,
>
> Seeing this discussion, and noting two open [Bugz], I was wondering about
> the plan to get this spec to a feature complete status (and hence ready for
> Last Call Working Draft). Would you please provide a short status/plan for
> Pointer Lock spec vis-à-vis LCWD?
>
> -Thanks, AB
>
> [Bugz]  WebAppsWG&component=Pointer%**20Lock&resolution=---&list_id=**3760
> >


The discussion about how easily javascript shims can be created is
orthogonal to the pointer lock spec. I'll leave that discussion on that
thread, which I note has concluded in "pointer lock has apparently already
been shimmed".

Of the two open issues, one [1] was already resolved (adding
allow-pointer-lock to HTML). I've closed the issue.

The other [2] is blocked on Mozilla's security review [3].

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18647
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19297
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=822654

Re: pointerLock vendor prefixes, shims and usability

[Chris Pearce]

- Original Message -

> From: "Florian Bösch" 
> To: "Webapps WG" 
> Sent: Tuesday, December 25, 2012 8:01:47 AM
> Subject: pointerLock vendor prefixes, shims and usability

> The pointerlock API is currently prefixed with vendor prefixes. This
> is fine in principle since it is an experimental API that lacks
> consistency and consensus and that's what vendor prefixes are for.

> A vendor prefix should serve to inform a developer that he's using
> non-standard functionality that may break or change, I get it,
> that's fine.

> It is however inconvenient to write out moz/o/msie/webkit/etc.
> everywhere in your code. Shims are one solution to this issue which
> enjoys some popularity (other people call it polyfill).

> You cannot write a shim/polyfill for pointerlock for the following
> reasons:

> - vendorRequestPointerLock is on the prototype to HTMLElement which
> you cannot modify in Firefox
> - vendorMovementX etc. are set by the event construction to
> mousemove, one cannot override and wrap the HTMLElement prototypes
> addEventListener. Even if one could, one would not want to allocate
> an object for every event in JS userspace (GCing being hurtful to
> realtime applications)
> - vendorpointerlockchange events can likewise only be abstracted by
> overriding HTMLElement's prototype which is a nogo.
> - document.mozPointerLockElement cannot be shimmed at all obviously
> (you cannot listen to document property changes)
Toji Game Shim seems to shim pointer lock fine in Firefox and Chrome release 
builds. 

https://github.com/toji/game-shim 

Chris Pearce. 

Re: pointerLock vendor prefixes, shims and usability

[Arthur Barstow]

Hi Vincent,

Seeing this discussion, and noting two open [Bugz], I was wondering 
about the plan to get this spec to a feature complete status (and hence 
ready for Last Call Working Draft). Would you please provide a short 
status/plan for Pointer Lock spec vis-à-vis LCWD?


-Thanks, AB

[Bugz] 




On 12/24/12 2:01 PM, ext Florian Bösch wrote:
The pointerlock API is currently prefixed with vendor prefixes. This 
is fine in principle since it is an experimental API that lacks 
consistency and consensus and that's what vendor prefixes are for.


A vendor prefix should serve to inform a developer that he's using 
non-standard functionality that may break or change, I get it, that's 
fine.


It is however inconvenient to write out moz/o/msie/webkit/etc. 
everywhere in your code. Shims are one solution to this issue which 
enjoys some popularity (other people call it polyfill).


You cannot write a shim/polyfill for pointerlock for the following 
reasons:


- vendorRequestPointerLock is on the prototype to HTMLElement which 
you cannot modify in Firefox
- vendorMovementX etc. are set by the event construction to mousemove, 
one cannot override and wrap the HTMLElement prototypes 
addEventListener. Even if one could, one would not want to allocate an 
object for every event in JS userspace (GCing being hurtful to 
realtime applications)
- vendorpointerlockchange events can likewise only be abstracted by 
overriding HTMLElement's prototype which is a nogo.
- document.mozPointerLockElement cannot be shimmed at all obviously 
(you cannot listen to document property changes)


Is it really necessary to attach those prefixes everywhere and pollute 
our code with them? It makes it positively painful to write, maintain 
and move forward with the code. Perhaps that is the intention, I don't 
know, but I don't approve.


Please for the love of not making web developers suffer, do come up 
with an alternative to this madness. It was already bad when it was 
done in CSS, but in JS it gets really really bad.


Thank you.

Re: pointerLock vendor prefixes, shims and usability

[Boris Zbarsky]

On 12/24/12 12:44 PM, Florian Bösch wrote:

I'm a bit concerned in doing these things to eventing because that stuff
gets called a lot and what's being done isn't straightforward
(allocating closures, regexing strings etc.) and that it could impact
performance.


OK, that's fair.

For what it's worth, the current trend inside Mozilla is exactly what 
you say: avoiding vendor prefixes by either turning things off before 
shipping or shipping them unprefixed if they're stable enough.  At least 
as a general policy; specific cases might merit exceptions.


-Boris

Re: pointerLock vendor prefixes, shims and usability

[Florian Bösch]

On Mon, Dec 24, 2012 at 9:31 PM, Boris Zbarsky  wrote:

> That's fixed as of 3 days ago in Firefox nightlies, for what it's worth.
>
That's good to hear that more of this becomes shimable.


> Events already allocate a new object or ten, for what it's worth.
>
>  - vendorpointerlockchange events can likewise only be abstracted by
>> overriding HTMLElement's prototype which is a nogo.
>>
>
> Is this the same issue as above or something different?

It's related.

The movementX/movementY members of the event would need that something (for
every event) catches that event, assigns to event.movementX =
event.mozMovementX which you can only do if you override addEventListener
and override the passed in handler with a wrapper.

The vendorpointerlockchange event can only be shimed by overriding
addEventListener and adding vendor event name translation code.

I'm a bit concerned in doing these things to eventing because that stuff
gets called a lot and what's being done isn't straightforward (allocating
closures, regexing strings etc.) and that it could impact performance.


> That's a separate question.  I personally think prefixing has been
> over-used; this might be an instance of that over-use.

Imo yes. If you look at the documentation for this feature
https://developer.mozilla.org/en-US/docs/API/Pointer_Lock_API#example this
is so vendor prefix polluted it's barely readable at all.

Re: pointerLock vendor prefixes, shims and usability

[Boris Zbarsky]

On 12/24/12 11:01 AM, Florian Bösch wrote:

- vendorRequestPointerLock is on the prototype to HTMLElement which you
cannot modify in Firefox


You mean applying HTMLElement.prototype.mozRequestPointerLock to 
particular elements throws (which is not the same thing at all)?


That's fixed as of 3 days ago in Firefox nightlies, for what it's worth.


one cannot override and wrap the HTMLElement prototypes
addEventListener.


This will take another few weeks to fix, but it's being fixed.


Even if one could, one would not want to allocate an
object for every event in JS userspace (GCing being hurtful to realtime
applications)


Events already allocate a new object or ten, for what it's worth.


- vendorpointerlockchange events can likewise only be abstracted by
overriding HTMLElement's prototype which is a nogo.


Is this the same issue as above or something different?


- document.mozPointerLockElement cannot be shimmed at all obviously (you
cannot listen to document property changes)


It can be shimmed in Firefox, for sure.  Like so works fine, in a 
current nightly (but not in realease, where Document is not on WebIDL 
bindings yet):


  var desc = Object.getOwnPropertyDescriptor(Document.prototype,
 "mozPointerLockElement");
  Object.defineProperty(Document.prototype, "pointerLockElement", desc);

This should also work in IE9/10, for attributes they implement.


Is it really necessary to attach those prefixes everywhere and pollute
our code with them?


That's a separate question.  I personally think prefixing has been 
over-used; this might be an instance of that over-use.


-Boris

pointerLock vendor prefixes, shims and usability

[Florian Bösch]

The pointerlock API is currently prefixed with vendor prefixes. This is
fine in principle since it is an experimental API that lacks consistency
and consensus and that's what vendor prefixes are for.

A vendor prefix should serve to inform a developer that he's using
non-standard functionality that may break or change, I get it, that's fine.

It is however inconvenient to write out moz/o/msie/webkit/etc. everywhere
in your code. Shims are one solution to this issue which enjoys some
popularity (other people call it polyfill).

You cannot write a shim/polyfill for pointerlock for the following reasons:

- vendorRequestPointerLock is on the prototype to HTMLElement which you
cannot modify in Firefox
- vendorMovementX etc. are set by the event construction to mousemove, one
cannot override and wrap the HTMLElement prototypes addEventListener. Even
if one could, one would not want to allocate an object for every event in
JS userspace (GCing being hurtful to realtime applications)
- vendorpointerlockchange events can likewise only be abstracted by
overriding HTMLElement's prototype which is a nogo.
- document.mozPointerLockElement cannot be shimmed at all obviously (you
cannot listen to document property changes)

Is it really necessary to attach those prefixes everywhere and pollute our
code with them? It makes it positively painful to write, maintain and move
forward with the code. Perhaps that is the intention, I don't know, but I
don't approve.

Please for the love of not making web developers suffer, do come up with an
alternative to this madness. It was already bad when it was done in CSS,
but in JS it gets really really bad.

Thank you.