Re: Last Call comments

On Wed, Mar 27, 2013 at 5:31 AM, Arthur Barstow <art.barstow@nokia.com>wrote:

> Hi Charles,
>
> In addition to various WG member responses to this thread, the Pointer
> Events WG also discussed the comments from you and Sergey during our March
> 26 call. The minutes from that call are <http://www.w3.org/2013/03/26-**
> pointerevents-minutes.html#**item04<http://www.w3.org/2013/03/26-pointerevents-minutes.html#item04>>
> (NB: we discussed the points in reverse order).
>
> Below, I insert the group's 1-line consensus (Resolution) for 4 of the 5
> points (please see the minutes for details). For one point (#3), the group
> decided to do some additional work before we are able to judge consensus so
> we will followup separately on that point.
>
> For the purposes of our Last Call comment tracking, please let us know
> your thoughts on the resolutions for points #1, #2, #4 and #5.
>
> -Thanks, ArtB
>
> #Trackbot: this e-mail addresses Action-29
>
>
> On 3/18/13 5:22 AM, ext Charles McCathie Nevile wrote:
>
>> Hi, these comments are from people at Yandex who implemented Pointer
>> Events for our services...
>>
>> The pointer system works well when you have only one input device (one
>> mouse, one pen or single-touch-capable screen) and saves some code
>> comparing to the Safari Mobile event model. But if you have more than one
>> input device, the pointer-oriented code becomes far more complex and less
>> obvious compared to the touch-oriented code for Safari Mobile because you
>> have to deal with event streams on your own. We should simplify the tough
>> case (multi-touch), not just the already simple one (single input device).
>>
>
> #1. RESOLUTION: an API to return active pointers is out of scope for v1,
> but will be tackled in v2
>
>
>  Why should the mouse have pointerId == 1? There is no need for this,
>> since we have a pointerType for detecting input device type, and it makes
>> it impossible to use two mouse devices simultaneously.
>>
>
> #2. RESOLUTION: supporting multi-mouse is out of scope for v1, will tackle
> in v2. The primary mouse having id 1 won't prevent this.


Note that many of us feel that having 1 be special is weird and unnecessary
(i.e. the concern here is indeed legitimate in my view), but it doesn't
seem to be enough of a problem at this stage in the spec to warrant making
a substantive change.

 The capturing system is a meaningless artifact of IE6, why implement it
>> again?
>>
>
> #3. We will reply separately about this point.


I spoke with our web components experts about this (Dimitry Glazkov, Darin
Fisher, Erik Arvidsson).  In particular I asked if they saw any issue with
composability of components and preserving encapsulation in the face of an
API like this that effective hijacked events that could otherwise go to
other components (and referenced this thread).  Their response was
essentially:  some form of capture is essential, and relying on capturing
events on the document is a hack that's actually bad for composition.  True
web components should never need to reach outside their scope and touch
elements like document.  All three of them independently expressed that
they preferred having the explicit capture API as part of pointer events.

I also agree with Jacob's points that this API is much easier to use and
read then relying on capturing events at the document.  I also think
getting explicit lost-capture notification is valuable for composition
(less likely to trigger bugs between components than relying on
stopPropagation).

On the call yesterday we agreed that if Google's web components experts
didn't have concerns with this API, then we'd plan to leave it as spec'd.

 Tilt angles are very difficult to work with, why not use standard
>> spherical coordinates?
>>
>
> #4. RESOLUTION: keep tiltX/tiltY units as defined
>
>
>  Preventing browser reaction via a custom css property contradicts both
>> the css paradigm (css is not designed to handle user input) and the DOM
>> Event paradigm (preventDefault is the normal way to prevent browser
>> behavior); furthermore, the idea that browser may have different reactions
>> on mouse and touch actions ruins the whole proposal.
>>
>
> #5. RESOLUTION: declarative-only control over browser default action
> (touch-action property) will remain the only mechanism for now
>
> FYI, UCs and requirements we are deferring for v.Next are listed in <
> http://www.w3.org/wiki/**PointerEvents/**UseCasesAndRequirements#**
> Requirements:_Pointer_Events_**v.Next_Specification<http://www.w3.org/wiki/PointerEvents/UseCasesAndRequirements#Requirements:_Pointer_Events_v.Next_Specification>
> >.
>
>
>  cheers
>>
>> Chaals
>>
>>
>
>