Re: pointerLock vendor prefixes, shims and usability

On Mon, Dec 24, 2012 at 9:31 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> That's fixed as of 3 days ago in Firefox nightlies, for what it's worth.
>
That's good to hear that more of this becomes shimable.


> Events already allocate a new object or ten, for what it's worth.
>
>  - vendorpointerlockchange events can likewise only be abstracted by
>> overriding HTMLElement's prototype which is a nogo.
>>
>
> Is this the same issue as above or something different?

It's related.

The movementX/movementY members of the event would need that something (for
every event) catches that event, assigns to event.movementX =
event.mozMovementX which you can only do if you override addEventListener
and override the passed in handler with a wrapper.

The vendorpointerlockchange event can only be shimed by overriding
addEventListener and adding vendor event name translation code.

I'm a bit concerned in doing these things to eventing because that stuff
gets called a lot and what's being done isn't straightforward (allocating
closures, regexing strings etc.) and that it could impact performance.


> That's a separate question.  I personally think prefixing has been
> over-used; this might be an instance of that over-use.

Imo yes. If you look at the documentation for this feature
https://developer.mozilla.org/en-US/docs/API/Pointer_Lock_API#example this
is so vendor prefix polluted it's barely readable at all.