W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: pointerLock vendor prefixes, shims and usability

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 24 Dec 2012 12:31:33 -0800
Message-ID: <50D8BBA5.3000107@mit.edu>
To: public-webapps@w3.org
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 days ago in Firefox nightlies, for what it's worth.

> one cannot override and wrap the HTMLElement prototypes
> addEventListener.

This will take another few weeks to fix, but it's being fixed.

> Even if one could, one would not want to allocate an
> object for every event in JS userspace (GCing being hurtful to realtime
> applications)

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?

> - document.mozPointerLockElement cannot be shimmed at all obviously (you
> cannot listen to document property changes)

It can be shimmed in Firefox, for sure.  Like so works fine, in a 
current nightly (but not in realease, where Document is not on WebIDL 
bindings yet):

   var desc = Object.getOwnPropertyDescriptor(Document.prototype,
   Object.defineProperty(Document.prototype, "pointerLockElement", desc);

This should also work in IE9/10, for attributes they implement.

> Is it really necessary to attach those prefixes everywhere and pollute
> our code with them?

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

Received on Monday, 24 December 2012 20:32:03 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:50 UTC