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
per
On Fri, Jan 4, 2013 at 4:49 AM, Arthur Barstow wrote:
> 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 f
- Original Message -
> From: "Florian Bösch"
> To: "Webapps WG"
> 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
&g
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]
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 wo
On Mon, Dec 24, 2012 at 9:31 PM, Boris Zbarsky 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 ca
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 d
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