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.