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

On Monday, February 4, 2013, Jacob Rossi wrote:

> From: Rick Byers [mailto:rbyers@google.com <javascript:;>]
> Sent: Monday, February 4, 2013 11:30 AM
>
> On Wed, Jan 30, 2013 at 8:46 AM, Arthur Barstow <art.barstow@nokia.com<javascript:;>>
> 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.
>

Makes sense, except that we'd probably add either '-myvendor-no-rotate' (to
opt out of rotate if it's a default action) or '-myvendor-rotate' (to
opt-in when it's not default), right?  Presumably supporting both would
also allow us (with the same compat caveats) to change our mind about what
is a default action from one version to the next.

It was this positive vs. negative convention I was wondering if we should
try to plan ahead for. but it probably doesn't really matter - even if
different vendors use different conventions, we could always use a unified
convention in the PEv2 standard.

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