RE: Issues blocking Last Call Working Draft [Was: Re: Draft minutes: 29 January 2013 call]

From: Rick Byers [mailto:rbyers@google.com] 
Sent: Monday, February 4, 2013 11:30 AM

On Wed, Jan 30, 2013 at 8:46 AM, Arthur Barstow <art.barstow@nokia.com> wrote:
>On 1/29/13 12:56 PM, ext Arthur Barstow wrote:
>>The draft minutes from the January 29 voice conference are available at <http://www.w3.org/2013/01/29-pointerevents-minutes.html> and copied below.
>>
>>Hi Rick,
>>
>>The last topic of the meeting was a discussion about moving Pointer Events to Last Call WD [LC]. The gist of the conversation is that LC is blocked on agreeable resolutions to:
>>
>>1. Bug 20217 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=20217>
>>
>> RESOLUTION: Pending feedback from Rick Byers, the group
>> tentatively concludes that there is not a sufficient use case
>> for adding a "zoom" value for the touch-action property.
>>
> I concur.  Thanks for the details of why IE has this.  
> If something like IE's content zooming is standardized then I think we might end up wanting zoom here too.  Jacob, you were going to do some thinking around extensibility of touch-action, right?  How do we design it now such that we can add things in the future without breaking sites and (ideally) without it being obviously discontinuous?
 
When the time comes for us to remove our -ms prefix from touch-action, we'll add -ms prefix to any values that aren't in the spec (e.g.  touch-action: -ms-some-touch-behavior). A similar approach should work for any other extensions a UA might add.

As for breaking impact, the question depends on what the touch behavior is that you're adding. Touch-action deals only with default touch behaviors. So a UA would have to assess the impact of adding the particular touch behavior. I'm not sure there's much we can do in defining touch-action to help reduce the impact of additional touch behaviors a UA may later decide to support.

For example, let's say you wanted to add some touch behavior that lets the user rotate the page (not sure why you would want to.just an example). If you wanted this to be a default touch behavior, then you'd need to understand the compatibility impact of rotating pages that might not otherwise have expected it. If that impact was acceptable to you, then you'd make it a default behavior and provide a prefixed touch-action value to opt-out for the folks who didn't want it (e.g. touch-action: -myvendor-rotate). If instead the impact was too great, then you wouldn't make this a default touch behavior.

>> 2. Bug 20222 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=20222>; see also <http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0041.html>
>>
>>JR: There's been some discussion on the list about this.
   ... Since we don't have great consensus on how to solve the
   "hover menu" problem interoperably,
   ... for this version of the spec it might just be appropriate
   for us to put some leeway into the compatibility mouse events
   section regarding mouseover/mouseout events.
   ... like, "Implementations MAY do something different in
   specific cases like :hover menus"
   ... and just make sure the spec is forward-compatible with
   changes we might make to address this in a future version.

> I'm OK with this, but I agree with Matt's concerns about leaving things unspecified.  
> Jacob has mostly convinced me that solving this problem really must be an 'opt-in' mechanism (there probably is no good general solution that doesn't involve opt-in).  In that case, are we OK with the idea that some implementations (and ideally some future version of PE) augment the rules here to define a different behavior when a site explicitly asks for it?  In particular, IE10 has this: http://msdn.microsoft.com/en-us/library/ie/jj152135(v=vs.85).aspx.  If we're OK with such implementation-specific extensions to the standard and with the idea of adding such an extension in the future, then I'd probably prefer we keep the current strict wording.

I agree, we should just keep the current wording for V1. Folks are still exploring this space and I don't think we have a solution to specify for this problem in V1. But some sort of extension in V2 to solve this would be a great addition.

>> 3. Making click/contextmenu use PointerEvent interface; <http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0024.html>
>>
>> I agreed to followup with you to make sure you know we want your feedback on these issues (via the list and/or directly in the bugs).
>
>Will reply to the thread.
>
>
> -Thanks, Art
>
> [LC] <http://www.w3.org/2013/01/29-pointerevents-minutes.html#item05>

Received on Monday, 4 February 2013 22:10:15 UTC