W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: pointerLock vendor prefixes, shims and usability

From: Chris Pearce <cpearce@mozilla.com>
Date: Fri, 4 Jan 2013 05:31:35 -0800 (PST)
To: Florian Bösch <pyalot@gmail.com>
Cc: Webapps WG <public-webapps@w3.org>
Message-ID: <1788228040.7497739.1357306295094.JavaMail.root@mozilla.com>
----- 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. 
Received on Friday, 4 January 2013 13:32:02 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:57 GMT