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] <https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=Pointer%20Lock&resolution=---&list_id=3760>


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.


Reply via email to