Re: pointerLock vendor prefixes, shims and usability

----- Original Message -----

> From: "Florian Bösch" <pyalot@gmail.com>
> To: "Webapps WG" <public-webapps@w3.org>
> 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.