Re: [pointerlock] Oct 2015 Pointer Lock Status

[Chaals McCathie Nevile]

On Sat, 24 Oct 2015 05:57:06 +0900, Vincent Scheib 
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

Re: [pointerlock] Oct 2015 Pointer Lock Status

[Vincent Scheib]

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 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.
>

Thanks for clarifying. Basic usage is demonstrated in the wild but some
edge cases should have clear demonstration in the test suite. I will
generate those as other project priorities allow (and would of course
review any from others).

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.
>

Thanks. Accessibility should be addressed more explicitly in the
specification. I will reach out to the APA and solicit suggestions.

Re: [pointerlock] Oct 2015 Pointer Lock Status

[Florian Bösch]

On Sun, Nov 1, 2015 at 9:08 PM, Vincent Scheib  wrote:
>
> Thanks for clarifying. Basic usage is demonstrated in the wild but some
> edge cases should have clear demonstration in the test suite. I will
> generate those as other project priorities allow (and would of course
> review any from others).
>

One of the things that frequently go wrong with pointerlock in the wild is
that authors request it, but don't check the result of the authorization.
They then go on to write applications that only work right with pointerlock
(for example FPS controls), and UAs deny pointerlock (because the user
needs to click an allow button). The dialog to allow pointerlock is not
modal and it's also presented small at the top of the screen, so it's
frequently missed.

Re: [Web Components] proposing a f2f...

[Hayato Ito]

> 1. Clarify focus navigation
> 2. Clarify selection behavior (at least make it interoperable to JS)
> 3. Decide on the style cascading order
> 4. style inheritance (https://github.com/w3c/webcomponents/issues/314)

I'm happy to have the mentioned topics about Shadow DOM on the f2f if and
only if:

- We have well-defined one-or-more proposals other than the current spec
- We've discussed the pros and cons of each proposal (and the current spec)
well
- However, we can not reach the consensus.

Unless a well-defined proposal before the meeting, I'm afraid it would be
difficult to have a consensus in the meeting.

Topic 1)
I can see one proposal about this topic:
https://github.com/w3c/webcomponents/issues/126.
This proposal doesn't replace the current behavior. It just adds the new
feature to current behavior.

Topic 2)
This issue has been an unresolved problem for years. There is no proposal
at all.

Topic 3)
This is the summary I've written:
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Shadow-DOM-Cascade-Order-in-v1.md

Topic 4)
There is no well-defined proposal other than the current spec.

It wold be nice to make the situation clear before the meeting so that we
don't have additional topics other than Custom Elements on f2f meetings.


On Thu, Oct 29, 2015 at 3:07 PM Ryosuke Niwa  wrote:

> >
> > On Oct 29, 2015, at 9:47 AM, Chris Wilson  wrote:
> >
> > Or host in Seattle.  :)
> >
> > On Thu, Oct 29, 2015 at 9:20 AM, Travis Leithead <
> travis.leith...@microsoft.com> wrote:
> >> I would prefer a late January date so as to allow me to arrange travel.
> Otherwise, I’m happy to attend remotely anytime.
>
> I'm okay with either option with a slight preference on having it earlier
> since we didn't have much time discussing custom elements at TPAC.
>
> I would like to resolve the following issues for shadow DOM:
> 1. Clarify focus navigation
> 2. Clarify selection behavior (at least make it interoperable to JS)
> 3. Decide on the style cascading order
>
> And the following issues for custom elements:
> 4. Construction model. Do we do sync / almost-sync / dance?
> 5. Do we support upgrading?  If we do, how?
>
> Any other issues?
>
> - R. Niwa
>
>
>

Re: [pointerlock] Oct 2015 Pointer Lock Status

[Chaals McCathie Nevile]

On Mon, 02 Nov 2015 05:08:10 +0900, Vincent Scheib   
wrote:



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 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.


Thanks for clarifying. Basic usage is demonstrated in the wild but some
edge cases should have clear demonstration in the test suite. I will
generate those as other project priorities allow (and would of course
review any from others).


OK. We also don't want to let perfect be the enemy of good. If things are  
truly edge cases it might be worth letting them wait for a revision unless  
they are reasonably straightforward.



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.


Thanks. Accessibility should be addressed more explicitly in the
specification. I will reach out to the APA and solicit suggestions.


OK, thanks. You might as well prime them with the things I called out  
above…


I guess the other thing is how you deal with Zoom, but I guess the short  
answer is "there are bigger things on screen". In fact zoom for  
accessibility is probably a use case that this spec can help, although  
maybe the mouse event stuff breaks that. I'll have a think in the morning  
if I am lucky.


cheers

Chaals

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: [Web Components] proposing a f2f...

[Chaals McCathie Nevile]

On Fri, 30 Oct 2015 16:21:43 +0900, Domenic Denicola  wrote:

Maybe we could have separate meetings (or days) for shadow DOM and for  
custom elements? I am concerned that with this growing list of shadow  
DOM topics we will not have time for custom elements, which would be  
disappointing for those of us traveling specifically for that.


It seems we might have enough work to make this a good idea.

As for dates: If we go for late January, the 26th through 28th collide  
with TC39, but the 25th or 29th would be ideal for me, since it would  
allow travel consolidation. December also works, with no conflicts.


If we go for January, this seems like a good week. I presume Travis will  
be in Australia earlier at the TAG meeting, and I'll be there too.


For people traveling to both, it seems a big ask to split the week.

Would people prefer to have a two-day meeting covering saturday or sunday,  
have one meeting in december and one in january (preferences for which is  
which?), try to have one very long day (personally I strongly advise not  
trying that, but if it's what we get I'll work with it)?


I'll set up a doodle when I get to sit down for a minute, hopefully  
tomorrow. Feel free to add to the thread in the meantime.


cheers


From: "Takayoshi Kochi (河内 隆仁)" 
Sent: Oct 30, 2015 2:52 PM
To: Ryosuke Niwa
Cc: Cynthia Shelly; Chris Wilson; Travis Leithead; Dimitri Glazkov; Olli  
Pettay; Chaals McCathie Nevile; public-webapps WG

Subject: Re: [Web Components] proposing a f2f...



On Thu, Oct 29, 2015 at 3:04 PM, Ryosuke Niwa  
> wrote:


On Oct 29, 2015, at 9:47 AM, Chris Wilson  
> wrote:


Or host in Seattle.  :)

On Thu, Oct 29, 2015 at 9:20 AM, Travis Leithead  
>  
wrote:
I would prefer a late January date so as to allow me to arrange  
travel. Otherwise, I’m happy to attend remotely anytime.


I'm okay with either option with a slight preference on having it  
earlier since we didn't have much time discussing custom elements at  
TPAC.


I would like to resolve the following issues for shadow DOM:
1. Clarify focus navigation
2. Clarify selection behavior (at least make it interoperable to JS)
3. Decide on the style cascading order


In addition, I'd propose

+ Decide on style inheritance  
(https://github.com/w3c/webcomponents/issues/314)



And the following issues for custom elements:
4. Construction model. Do we do sync / almost-sync / dance?
5. Do we support upgrading?  If we do, how?

Any other issues?

- R. Niwa





--
Takayoshi Kochi



--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 cha...@yandex-team.ru - - - Find more at http://yandex.com