Re: Tweak wording in introduction?

On 2/14/13 11:31 PM, ext Jacob Rossi wrote:
> On Thu, Feb 14, 2013 at 12:28 PM, Hans Muller <> wrote:
>> On 2/14/13 10:59 AM, "Rick Byers" <> 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.
>> 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?).

Since the Introduction section and all examples are explicitly 
non-normative, any changes to either or both those would not be 
considered substantive and thus would not prevent the spec from 
advancing along the Recommendation track.

(The spec must return to Working Draft if normative text is changed and 
the change(s) could affect an implementation.)

I support the proposed changes to the Introduction and I think it would 
be OK if the changes to the Introduction were made now, i.e. before the 
LC is published on February 19 (assuming of course that Jacob or Matt 
can make the change by Feb 18). But this is certainly not a showstopper 
for the LC and we can consider Rick and Hans' feedback as "LC comments".


Received on Friday, 15 February 2013 13:08:38 UTC