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
On 12/24/12 11:01 AM, Florian Bösch wrote:
- vendorRequestPointerLock is on the prototype to HTMLElement which you
cannot modify in Firefox
You mean applying HTMLElement.prototype.mozRequestPointerLock to
particular elements throws (which is not the same thing at all)?
That's fixed as of 3
On Mon, Dec 24, 2012 at 9:31 PM, Boris Zbarsky bzbar...@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.
-
On 12/24/12 12:44 PM, Florian Bösch wrote:
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.
OK, that's fair.
For what it's
