RE: Tweak wording in introduction?

On Thu, Feb 14, 2013 at 12:28 PM, Hans Muller <hmuller@adobe.com> wrote:
> On 2/14/13 10:59 AM, "Rick Byers" <rbyers@google.com> wrote:
>
> >Hey,
> >I just re-read the introduction (it's been awhile) and realized it
> >deviates a little from how we've talked about PE in the group.  In
> >particular:
> >
> >>This model makes it easy to write sites and applications that work well
> >>no matter what hardware the user has.
> >...
> >>So authors can easily code to Pointer Events and their content just
> >>works no matter what input hardware is being used.
> The specification's scope seems to be focused on touch, pen, and mouse
> input. Is it really necessary to lay claim to all input hardware?

Touch, pen, and mouse are the examples given. But it is certainly a goal to have compatibility/extensibility for other devices. 

> >
> >I'm concerned that these may help perpetuate the misconception that if
> >you design for pointers, you don't need to think explicitly about how
> >to design your UI for different input types.  There are still lots of
> >challenges to designing a UI that works well with both touch and
> >mouse, for example, appropriate target size, gesture support (you'd
> >never 'swipe' with the mouse), etc.  I propose we change "easy" to
> >"easier", and replace the second sentence with something like:
> >
> >>So authors can easily code to Pointer Events to share logic between
> >>different input types where it makes sense, and customize for a
> >>particular type of input only where necessary to get the best experience.
>
> I agree.

I'm fine with this change. I'd also like to update Example 6 to better encourage authors to provide a default code path (e.g. a comment like "basic generic pointing device support" in the default: case)

> If a single non-trivial application supports touch/pen/mouse input well,
> it's likely to recognize different gestures and support different
> interactions, depending on the input device. Are there some examples that
> show how this would be done with Pointer Events? I'm wondering how much
> shared code could actually be factored out of such an application.

Example 5 in the spec shows a scenario (Canvas painting) where differentiating by pointer type is not needed.
Example 6 in the spec shows how differentiating by pointer type is possible, should you wish.

In the very general sense, the events that a pointing device produces do not differ by device (e.g. all devices have "down", "move", "up", etc. scenarios). In practice, I see developers differentiate per device for two reasons:

1) Varied UI (e.g. larger targets for touch)
Generally speaking, this is done outside of events (e.g. either with the pointer/hover CSS media queries or in script via something like navigator.maxTouchPoints).  

2) Varied gestures 
Gestures are really a level above what pointer events deal with. Gestures are out of scope for this working group. But as an example, IE10's MSGesture object takes in pointer events (for any device type) and outputs gestures relevant to that device. 
http://blogs.msdn.com/b/ie/archive/2012/06/20/10322287.aspx 

> Also, if we're tweaking the introduction, I'd suggest we also add a
> sentence or two around the threaded scrolling implications (to me
> that's an even more important property than unifying different input
> types).  Perhaps after the "primary goal" sentence we can say
> something like "An additional key goal is to enable multi-threaded
> user agents to handle default touch actions such as scrolling without
> blocking on JavaScript".

Yes, that would be good to add as well.

> I don't think any of this would qualify as a "substantive change"
> (since it's just editorial), so shouldn't impact the last call, right?

An editorial change like this would not alter anyone's review/analysis of the spec. Therefore, it shouldn't impact last call. Adding Art just to verify.

I've already staged the LC doc. So we'd make these changes in the next Editor's Draft (which I probably won't get to until after W3Conf--perhaps Matt could make this change?).

-Jacob

Received on Friday, 15 February 2013 04:31:51 UTC