Re: pointerLock vendor prefixes, shims and usability

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.

Received on Friday, 4 January 2013 12:49:30 UTC