I've discussed more with Xiaoqian and Léonie and support a CR now with this
proposal:
Move to a CR for the v1 Pointer Lock specification without Shadow DOM
changes, and a note on accessibility. Implementations are nearly consistent
for v1 and it can move to a published status sooner. We can
Shadow dom concepts will also be incorporated.
On Thu, Jun 16, 2016 at 1:43 PM, Chaals McCathie Nevile <
cha...@yandex-team.ru> wrote:
> On Thu, 16 Jun 2016 12:33:30 +0200, Vincent Scheib <sch...@google.com>
> wrote:
>
> An accessibility review and handling of this
An accessibility review and handling of this [accessibility issue #1] are
still needed and will likely cause a CR cycle. To avoid unnecessary work I
propose CR to be deferred until that work is complete.
[accessibility issue #1] https://github.com/w3c/pointerlock/issues/1
On Tue, Jun 14, 2016 at
On Sun, Nov 1, 2015 at 3:42 AM, Chaals McCathie Nevile <
cha...@yandex-team.ru> wrote:
> Yes. You are *not* required to use testharness tests. While it would be
> good to get the automation of stuff like this landed, it is perfectly
> reaonable to write some interop tests in the form "load this
On Thu, Oct 29, 2015 at 12:18 AM, Michael[tm] Smith <m...@w3.org> wrote:
> Hi Vincent,
>
> Vincent Scheib <sch...@google.com>, 2015-10-23 13:57 -0700:
> > Testharness tests are not currently able to test the core Pointer Lock
> > features, which would r
Pointer lock reached Candidate Recommendation in Dec 2013. [CR]
Implementation status: (Edge and Opera have changed status since October
2014)
Chrome: Implemented.
Firefox: Implemented with prefix.
Edge: Implemented in Preview Build 10532+ (Edge 13) [Edge]
Opera: Implemented.
Safari: No
be good to note
any other developers who would find that useful, especially if they have a
deployed product.
On Thu, Feb 26, 2015 at 8:21 PM, Vincent Scheib sch...@google.com wrote:
Thanks, Philip, changes made.
On Thu, Feb 26, 2015 at 10:58 AM, Philip Jägenstedt phil...@opera.com
wrote
Thanks, Philip, changes made.
On Thu, Feb 26, 2015 at 10:58 AM, Philip Jägenstedt phil...@opera.com
wrote:
Also, the EventHandler type should not be nullable, it's already
typedef'd to be nullable in https://html.spec.whatwg.org/#eventhandler
On Fri, Feb 27, 2015 at 1:56 AM, Philip
I could use more information here.
http://www.w3.org/TR/DOM-Level-3-Events/#interface-MouseEvent specifies
MouseEvent attributes with the attribute keyword. WebIDL description of
attribute seems to apply here http://www.w3.org/TR/WebIDL/#idl-attributes.
Why shouldn't the attribute keyword be used?
Thank you again:
https://dvcs.w3.org/hg/pointerlock/rev/25ad122a8000
On Tue, Dec 2, 2014 at 6:43 PM, timeless timel...@gmail.com wrote:
1. w3c is en-us
https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#abstract
modelling - modeling
Done.
2. Xlib
Thank you for the detailed comments, I will incorporate and reply back.
On Tue, Dec 2, 2014 at 6:43 PM, timeless timel...@gmail.com wrote:
1. w3c is en-us
https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#abstract
modelling - modeling
2. Xlib
Implementation status:
(Chrome and IE have changed status since April)
Chrome: Implemented without prefix, in stable version.
Firefox: Implemented with prefix, in stable version.
IE: Implementation active. Issue:
On Thu, Sep 4, 2014 at 1:50 PM, Florian Bösch pya...@gmail.com wrote:
Well, the motivation to ask for permission up front is so that you later
don't have to pester the user. Everytime you poll a user, there's a
possibility he'll not see the prompt (happens to me pretty frequently in
chrome
Chrome is renewing work toward a Bluetooth API for websites to communicate
with devices. We have started work reviewing existing APIs, use cases, and
security concerns.
[1] has a start of that work focusing on minimizing the device attack
surface exposed to malicious websites, possibly by
Implementation status:
Chrome: Implemented with prefix, in stable version.
Firefox: Implemented with prefix, in stable version.
IE: No implementation progress known. Issue:
http://connect.microsoft.com/IE/feedback/details/793718/ie11-feature-request-support-for-pointer-lock-api
Safari: No
Perhaps I'm missing some context. What issue are you raising that isn't
handled by the gamepad API [1]?
[1] https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html
On Fri, Mar 14, 2014 at 1:35 AM, Patrick H. Lauke re...@splintered.co.ukwrote:
No takers on the idea of having some form of
Thank you Ian for the clear use case write up (and to Artillery for
progress on a great product), Florian Brandon and Glenn for discussion
contributions.
As Florian mentioned, we did discuss this use case in 2011 and at that time
I attempted to summarize the situation in the pointer lock spec
On Mon, Feb 24, 2014 at 10:37 AM, Florian Bösch pya...@gmail.com wrote:
On Mon, Feb 24, 2014 at 7:07 PM, Vincent Scheib sch...@google.com wrote:
Windows has ClipCursor() and Linux has XGrabPointer(). Once we know we
can implement the functionality, we can discuss how to express
I also saw no comments or bugs filed.
On Sat, Nov 30, 2013 at 8:09 AM, Arthur Barstow art.bars...@nokia.comwrote:
Hi Vincent, All,
I didn't notice any comments or bugs. Did I miss anything? If not, I'll
start a CfC to publish a Candidate Recommendation.
-Thanks, AB
On 10/31/13 3:32 PM,
wrote:
On Thu, 03 Oct 2013 22:50:21 +0100, Vincent Scheib
sch...@google.com(mailto:
sch...@google.com)
wrote:
Pointer lock is tricky to automate tests for. Consider some examples:
- Upon lock, no pointer should be visible.
That might be tested using a reftest[1].
- A user gesture
On Wed, Oct 2, 2013 at 9:30 AM, Arthur Barstow art.bars...@nokia.comwrote:
Hi Vincent,
If any of the data for the Pointer Lock spec in [PubStatus] is not
accurate, please provide corrections.
Pointer Lock is no longer blocked on mozilla security review. Firefox
stable now implements
Pointer lock is tricky to automate tests for. Consider some examples:
- Upon lock, no pointer should be visible.
- A user gesture is required to lock when not in fullscreen.
- Transitioning to fullscreen and pointer lock then exiting fullscreen
should maintain pointer lock. (User gesture required
On Wed, May 1, 2013 at 7:00 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Apr 11, 2013 at 5:59 PM, Vincent Scheib sch...@google.com wrote:
I argue on that issue that we should not bubble the event and have the
handler on document only. Pointer lock doesn't have as much legacy spec
On Sat, Mar 16, 2013 at 8:05 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Mar 15, 2013 at 6:57 PM, Vincent Scheib sch...@google.com wrote:
I have added onipointerlockchange and onpointerlockerror to the partial
document IDL in the pointer lock specification.
Webkit currently
On Sat, Mar 16, 2013 at 7:51 AM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Mar 15, 2013 at 5:24 PM, Vincent Scheib sch...@google.com wrote:
After discussion with Olli Pettay I have clarified portions of the
pointer lock specification.
https://dvcs.w3.org/hg/pointerlock/raw-file/default
I have added onipointerlockchange and onpointerlockerror to the partial
document IDL in the pointer lock specification.
Webkit currently only defines these event handler attributes on document.
Unless a reason is raised to add them elsewhere, I do not plan to add
additional attributes elsewhere,
After discussion with Olli Pettay I have clarified portions of the pointer
lock specification.
https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html
https://dvcs.w3.org/hg/pointerlock/diff/6543d83c0b74/index.html
When requesting pointer lock, this paragraph replaces previous statements
[Including Anne Tantek due to their work on Fullscreen]
The pointer lock specification intentionally mimics the fullscreen
specification to provide consistency for developers, as they are similar
and expected to be commonly used in the same apps. Neither specification
mention event properties.
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
Thanks, updated to use the nullable type.
http://dvcs.w3.org/hg/pointerlock/rev/ecf0846c2f8f
On Tue, Nov 27, 2012 at 2:41 PM, Boris Zbarsky bzbar...@mit.edu wrote:
The IDL at http://dvcs.w3.org/hg/**pointerlock/raw-file/default/**
Chrome supports Fullscreen with keyboard enabled. We use a notification
that persists until a user notices and dismisses it. We may modify it in
the future to make this more noticeable, e.g. dimming page contents similar
to FireFox.
I personally think it would be unfortunate to support multiple
forward to real feature completion ;)
Rick
On Wed, Oct 3, 2012 at 12:08 AM, Vincent Scheib sch...@google.com wrote:
I agree that pointer lock is quite useful outside of fullscreen, but
before attempting to codify that in the specification I would want buy
in from other browser vendors. I can
I agree that pointer lock is quite useful outside of fullscreen, but
before attempting to codify that in the specification I would want buy
in from other browser vendors. I can appreciate an argument to remain
restricted to fullscreen.
Application developers can automatically escalate to
On Wed, Sep 26, 2012 at 7:27 AM, Arthur Barstow art.bars...@nokia.com wrote:
The upcoming TPAC meeting week (Oct 29-Nov2) provides an opportunity for
joint WG meetings and lots of informal information sharing. As such, it can
be useful to make new publications before TPAC.
There is a
On Wed, Sep 26, 2012 at 9:17 AM, Arthur Barstow art.bars...@nokia.com wrote:
On 9/26/12 11:46 AM, ext Vincent Scheib wrote:
On Wed, Sep 26, 2012 at 7:27 AM, Arthur Barstow art.bars...@nokia.com
wrote:
* Pointer Lock - Vincent - what's the status of the spec and its
implementation?
Firefox
Thank you Adam, ROC, Anne. I commented on issue.
On Wed, Aug 1, 2012 at 2:05 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Aug 1, 2012 at 11:04 AM, Anne van Kesteren ann...@annevk.nl
wrote:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17838
I did not want to define new HTML
I'm currently implementing Pointer Lock [1] in WebKit, which was adjusted
recently to mimic Fullscreen [2].
Why does the Fullscreen specification use an iframe attribute
allowfullscreen to permit/restrict iframe capabilities instead of using
iframe sandbox=allow-fullscreen?
[1]
[correcting Anne van Kesteren's email]
On Tue, Jul 31, 2012 at 3:03 PM, Vincent Scheib sch...@google.com wrote:
I'm currently implementing Pointer Lock [1] in WebKit, which was adjusted
recently to mimic Fullscreen [2].
Why does the Fullscreen specification use an iframe attribute
On Tue, Jun 5, 2012 at 1:06 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Jun 4, 2012 at 11:13 PM, Jer Noble jer.no...@apple.com wrote:
Actually, in WebKit, we explicitly also message the document from which the
element was removed in that case. I don't see why this behavior couldn't
I'm currently implementing Pointer Lock [1] in WebKit, which was
adjusted recently to mimic Fullscreen [2].
The Fullscreen specification calls for events to be dispatched to the
document, but the WebKit implementation dispatches fullscreenchange
and fullscreenerror events to the context element
Mounir, I ran into the same confusion regarding how does the API expose
locking?. May I suggest that you explicitly state in the abstract that the
API is pending?
On Wed, Feb 15, 2012 at 8:34 AM, Paul Bakaus pbak...@zynga.com wrote:
Cool, thanks for the update!
Am 15.02.12 13:21 schrieb
Pointer lock spec[1] has been updated as I described, with the exception of
allowpointerlock which still needs to be added.
http://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html
Feedback welcome.
On Fri, Jan 27, 2012 at 9:06 PM, Vincent Scheib sch...@google.com wrote:
The spec
On Tue, Feb 7, 2012 at 5:24 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Feb 7, 2012 at 9:58 AM, Vincent Scheib sch...@google.com wrote:
Pointer lock spec[1] has been updated as I described, with the exception
of
allowpointerlock which still needs to be added.
http://dvcs.w3.org/hg
The spec for Pointer Lock has been moved[1]. It was also renamed from the
previous Mouse Lock.
While landing the initial implementation in WebKit Darin Fisher pointed out
that the Fullscreen API[2] had strong overlap with the pointer lock spec in
dealing with entering and exiting a state
On Thu, Dec 15, 2011 at 6:16 AM, Olli Pettay olli.pet...@helsinki.fiwrote:
Hi all,
few comments about the API
(1)
currently http://dvcs.w3.org/hg/**webevents/raw-file/default/**
mouse-lock.htmlhttp://dvcs.w3.org/hg/webevents/raw-file/default/mouse-lock.htmluses
VoidCallback which isn't
WebEvents WG is taking up this spec. I've created a new Mouse Lock
thread on public-webevents:
http://lists.w3.org/Archives/Public/public-webevents/2011OctDec/0066.html
, Sep 12, 2011 at 2:11 PM, Vincent Scheib sch...@google.com wrote:
I've updated the draft spec http://goo.gl/9G8pd with these points.
- Removed Touch related components to simplify initial version of
specification and because they do not add the same level of new application
capability as mouse
A Mouse Lock API has been under discussion on the W3 public-webapps list
Mouse Lock[1] and earlier Mouse Capture for Canvas[2].
The primary goal is to enable use cases such as first person perspective 3D
applications. This is done by providing scripted access to mouse movement
data while locking
But do you agree with me that post ballistics, accelerated and low
resolution is exactly what you don't want for most use cases? Why should it
not be possible to specify the units I described in my last mail:
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0978.html.
That
PM, Vincent Scheib sch...@google.com wrote:
Continuing the discussion of some of the open issues I'm aware of:
-- If MouseEvent types are returned under mouse lock, what should
.clientX/Y and screenX/Y be? --
Spec as drafted states they should be the center of the target element.
That's
Continuing the discussion of some of the open issues I'm aware of:
-- If MouseEvent types are returned under mouse lock, what should .clientX/Y
and screenX/Y be? --
Spec as drafted states they should be the center of the target element.
That's likely a poor idea, as discussed, and a better
Re Rob:
Is there a need to provide mouse-locking on a per-element basis? It seems
to
me it would be enough for mouse-locking to be per-DOM-window (or
per-DOM-document) and deliver events to the focused element. This
simplifies
the model a little bit by not having to define new state for the
And what if the device in question is just a touchscreen with no
keyboard, mouse or hardware buttons?
From the draft spec: Touch devices may also choose to reserve a portion of
the touch interface for an unlock gesture.
Mouse lock seems irrelevant on a touchscreen...
I've added
John Villar and I have produced a draft specification:
https://docs.google.com/document/d/1uV4uDVIe9-8XdVndW8nNGWBfqn9ieeop-5TRfScOG_o/edit?hl=en_USauthkey=CM-dw7QG
Some additional notes included in that draft not yet discussed here:
- .deltaX conflicts with WheelEvent, I've used .movementX/Y
is the
security model for mouse lock? (Please feel free to point me to a
message in the archive if this has already been discussed.)
Thanks,
Adam
On Thu, Jun 16, 2011 at 3:21 PM, Vincent Scheib sch...@google.com wrote:
[Building on the Mouse Capture for Canvas
thread:
http://lists.w3
[Building on the Mouse Capture for Canvas thread:
http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/thread.html#msg437
]
I'm working on an implementation of mouse lock in Chrome, and would
appreciate collaboration on refinement of the spec proposal. Hopefully
webapps is willing to
56 matches
Mail list logo