- 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>
On Sat, 24 Oct 2015 05:57:06 +0900, Vincent Scheib <scheib@google.com> wrote: > 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). cheers Chaals -- 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