Re: Last Call comments

Hi Charles - Rick's reply means the WG has replied to all five of your 
comments. For the purposes of our Last Call comment tracking, please let 
us know your thoughts on the group's resolutions and replies for these 
points.

The group's next meeting is April 2 at 15:00 UTC. If you can please 
reply before then, we would appreciate it.

-Thanks, ArtB

On 3/28/13 2:40 AM, ext Rick Byers wrote:
> On Wed, Mar 27, 2013 at 5:31 AM, Arthur Barstow <art.barstow@nokia.com 
> <mailto: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>
>     (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>.
>
>
>         cheers
>
>         Chaals
>
>
>
>

Received on Monday, 1 April 2013 13:23:00 UTC