On Sat, 24 Oct 2015 05:57:06 +0900, Vincent Scheib <sch...@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
cha...@yandex-team.ru - - - Find more at http://yandex.com
