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

Re: [pointerlock] Oct 2015 Pointer Lock Status

From: Chaals McCathie Nevile <chaals@yandex-team.ru>
Date: Sun, 01 Nov 2015 20:42:11 +0900
To: "Webapps WG" <public-webapps@w3.org>, "Vincent Scheib" <scheib@google.com>
Message-ID: <op.x7fs0lens7agh9@widsith.local>
On Sat, 24 Oct 2015 05:57:06 +0900, Vincent Scheib <scheib@google.com>

> Pointer lock reached Candidate Recommendation in Dec 2013. [CR]
> Implementation status:
[Looks like enough that if the implementations work - i.e. do the same
things - we are ready]

> Testharness tests are not currently able to test the core Pointer Lock
> features, which would require user gesures (mouse clicks) and  
> synthesizing mouse movement. No progress is seen here for this
> specification, but the challenge is present for several.
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 page and do
this and then this and then this, and determine whether you see this or
that". A set of tests of this nature that collectively cover the spec's  
features should be enough. And it is a Good Thing™ to use content found in  
the wild as the basis for this.

We are required to show that implementors reading the spec will get it
right, and that there is a reasonably broad interest in implementing.

> Specification:
>   https://w3c.github.io/pointerlock/
>   Minor changes in last year (small IDL fixes, typos/grammar):
>     https://github.com/w3c/pointerlock/commits/gh-pages
>   Feature Requests page moved to github:
>     https://github.com/w3c/pointerlock/blob/gh-pages/FeatureRequests.md
> Next Steps:
> In the Candidate Recommendation Call for Comments [CR-CfC] Arthur Barstow
> proposed exit criteria:
> """
> During the Candidate Recommendation period, which ends @T+3months, the
> WG will complete its test suite. Before this specification exits
> Candidate Recommendation, two or more independent implementations must
> pass each test, although no single implementation must pass each test.
> The group will also create an Implementation Report.
> """
> Robust cross browser testing, as mentioned above, is challenging and I
> question if browser vendors will implement sufficient support, e.g. via  
> Web Driver or other means. This leaves a discussion of how much testing
> is practical vs implicit demonstration of implementation consistency
> via application use.

As noted above, we "only" need to show that the features defined in the
spec work right when implemented in the wild.

Good practice would suggest that this includes developers using them
"right" - if the spec isn't clear enough for authors to do this, we
still have a problem.

> Feature use exists in typically smaller projects. For example
> http://a-way-to-go.com/.

> Working group questions:
>   * How much testing is practically required to move to Proposed?
>   * Ready for 'wider' review?

If it is implemented in multiple browsers, is used by websites "in the
wild", and you can show that it has been looked over to see if concerns
were indentified relating to accessibility, API design,
internationalisation, privacy, and security, we probably have sufficiently
wide review to request Proposed Rec.

A lot of that is already reflected in the spec. The cases of accessibility  
that strike me as relevant are being able to generate synthetic mouse  
events, e.g. with keyboard, escape pointer lock, and making sure that  
users understand when they have been put into it - especially for users  
with cognitive disabilities.

All these issues are addressed, but I would feel more comfortable  
requesting PR *knowing* that e.g. the APA group who do accessibility  
review have had a look at it. I'm happy to arrange that if it hasn't  
already happened. (I'm flying and not in a position to do the archaeology  
support for my memory).



Charles McCathie Nevile - web standards - CTO Office, Yandex
    chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Sunday, 1 November 2015 19:42:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:58 UTC