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]
- Original Message -
From: Florian Bösch pya...@gmail.com
To: Webapps WG public-webapps@w3.org
Sent: Tuesday, December 25, 2012 8:01:47 AM
Subject: pointerLock vendor prefixes, shims and usability
The pointerlock API is currently prefixed with vendor prefixes. This
is fine
On Fri, Jan 4, 2013 at 4:49 AM, Arthur Barstow art.bars...@nokia.comwrote:
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
I should note that I do have an application in the oven that could serve as
a usecase study for non fullscreen pointerlock UX/issues (it uses
pointerlock in different portions of its functionality to improve
usability).
It's currently not ready for release, but upon request I can arrange for a
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
