RE: RfC: Last Call Working Draft of Pointer Events; deadline December 4

Hi Josh,

Thanks for the exhaustive review.  In addition to Art's changes in the previous mail, I have responded to the remaining issues inline below, noting commits when applicable. 

-Jacob

On Sat, Nov 15, 2014 at 10:29 PM, <timeless@gmail.com> wrote:
> 7. step function
>
> http://www.w3.org/TR/2014/WD-pointerevents-20141113/#intro

>
> > However, that approach requires a step function in opportunity cost to authors when adding support for a new input type.
>
> This is an introduction, but i have no idea what a "step function" is here. Ideally your introduction should be in plain English. Note that I consider "opportunity cost" to be understandable.
>
> > A pointer can be any point of contact on the screen made by a mouse cursor, pen, touch (including multi-touch), or other pointing input device. 
>
> What if there is no point of contact?
>
> (Perhaps it's referential only)

I've changed this sentence to:  "However, that approach often incurs unnecessary duplication of logic and event handling overhead when adding support for a new input type."
https://dvcs.w3.org/hg/pointerevents/rev/fa10e316b85d 

> 8. necessary
>
> http://www.w3.org/TR/2014/WD-pointerevents-20141113/#intro

>
> > The primary goal is to provide a single set of events and interfaces that allow for easier authoring for cross-device pointer input while still allowing for device-specific handling when necessary.
>
> I object to "necessary", how about "when an author insists on being stubborn and not forward looking to the exclusion of other input methods". (It's ok to drop the end of this correction, but I'd hope that the spirit of my suggestion can be incorporated.)
>
> > only where necessary to get the best experience.
>
> s/the best/an augmented/

I can sympathize with your original suggestion. :-) That said, there are valid scenarios for augmenting your logic for a specific type.  I like your suggestion and have made this change: https://dvcs.w3.org/hg/pointerevents/rev/1fe2247f0df9 
> 12. unique
>
> http://www.w3.org/TR/2014/WD-pointerevents-20141113/#widl-PointerEvent-pointerId

>
> > This identifier must be unique from all other active pointers at the time.
>
> What is the scope of uniqueness here? Can two UAs on two unrelated devices share a pointerId? Can one UA assign the same pointerId to differrent objects when reporting to two disconnected web pages?

The answer comes from the linked definition of active pointers:
>> If it is possible for a given pointer (identified by a unique pointerId) to produce additional events [within the document], then that pointer is still considered active.

So then the transitive statement is true:
> This identifier must be unique from all other pointers capable of producing additional events [within the document].

So, in your examples, if a pointer "object" is capable of producing additional events on both of the two disconnected web pages, then they cannot share a pointerId. In the case of two unrelated devices, a pointer on one device isn't capable of producing events on the device and therefore the two devices have independent sets of active pointers, which means it's possible for a pointer on one device to share a pointerId with a pointer on the other device.

I think adding "within the document" to the definition of active pointers makes this clearer (as I indicated with the [ ] phrase above). So I have done so: https://dvcs.w3.org/hg/pointerevents/rev/ee526a2bdd39 

> 15. tiltX
>
> http://www.w3.org/TR/2014/WD-pointerevents-20141113/#widl-PointerEvent-tiltX

>
> > The plane angle (in degrees, in the range of [-90,90]) between the Y-Z plane and the plane containing both the transducer (e.g. pen stylus) axis and the Y axis.
>
> suppose i have a gyroscope and accelerometer augmented "air" pen (you could imagine turning a mobile phone into such a device). There's no "transducer", but it certainly has a tilt.

The transducer term comes from the HID standard for stylus devices, which uses a similar tilt reporting definition. The bounds of the tilt angle (a range of 180 degrees per axis) and the nature that it is relative to a digitizer somewhat preclude  an augmented "air" pen (where there is no digitizer plane and tilt is not bounded within one hemisphere). Considering how to support fully spherical devices is interesting, but not something we are really tackling with this spec. It'd also might need to be a new pointerType. So I've posted this to our V2 wiki: https://www.w3.org/wiki/PointerEvents/UseCasesAndRequirements#Requirements:_Pointer_Events_v.Next_Specification  

> 16. insufficiently labeled figure 2
>
> http://www.w3.org/TR/2014/WD-pointerevents-20141113/#fig-positive-tiltx.x

>
> the figure does not identifier "front" of the "transducer" (or any other orientation) -- it should label thins like "positive x" or "positive y".

Unfortunately, I produced these figures several years ago and I'm not sure that I have the originals to edit. However, I think the orientation is evident given the statement "a positive tiltX is to the right" and the location of the tiltX angle indicated in the diagram. I'd like to "won't fix" this issue. If I find the originals, I'll add sign labels to the axes. 

> 19. table comments
>
> http://www.w3.org/TR/2014/WD-pointerevents-20141113/#list-of-pointer-events

>
> > Trusted proximal event target types
> > Event object interface
>
> The values are the same in these columns for all rows. If this table is related to a table outside this document, there should be a reference to it.
> If there isn't such a table, can you remove the column?

The table format was borrowed from DOM L3 Events, but you're right--these two columns aren't useful in this case. Given the table is already non-normative and the columns don't add additional clarification, I just removed them: https://dvcs.w3.org/hg/pointerevents/rev/7bafeebccbef 

> > Varies: when the pointer is primary, all default actions of mouseover
>
> a. I don't understand what this means.

Primary pointers produce compatibility mouse events (https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#compatibility-mapping-with-mouse-events). So for those pointers, this is to say that mouseover & pointerover share their default actions (pointerover > mouseover > default action). It "varies" since only primary pointers have this default action. Keep in mind, this is just a non-normative table.

> b. This item doesn't end with a period.
>
> > Varies: when the pointer is primary, all default actions of the mousedown event. 
>
> This similar sounding item includes a period.
>
> > Cancelling this event also sets the PREVENT MOUSE EVENT flag for this pointerType, which prevents subsequent firing of certain compatibility mouse events.

I've made the period usage consistent in the above commit.

> 21. touch mismatch w/ mouse
>
> http://www.w3.org/TR/2014/WD-pointerevents-20141113/#the-pointerdown-event

>
> > For mouse, this is when the device transitions from no buttons depressed to at least one button depressed.
> > For touch, this is when physical contact is made with the digitizer. 
>
> Mouse is clearly not going to fire for the second button down.
> 
> If I put one finger to the digitizer, it will fire.
> If I put another finger to the digitizer, it appears that the instructions here will result in it firing, which seems to be different from mouse.
> 
> http://www.w3.org/TR/2014/WD-pointerevents-20141113/#the-pointerup-event

>
> > For mouse, this is when the device transitions from at least one button depressed to no buttons depressed.
> > For touch, this is when physical contact is removed from the digitizer.
>

Correct. See: https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#chorded-button-interactions 
A second finger represents a second pointer, however a second mouse button does not. There is one mouse pointer and the button state is just a modifier. Pressing two buttons on a single mouse shouldn't produce two separate pointers (e.g. like multi-touch). 

> 23. confusing
>
> http://www.w3.org/TR/2014/WD-pointerevents-20141113/#the-pointercancel-event

>
> > Examples of scenarios in which a user agent might determine that a pointer is unlikely to continue to produce events include:
>
> > The user inputs a greater number of simultaneous pointers than is supported by the device.
>
> How can a useragent discover this??

The OS provides this (e.g. it's an implementation detail on how to hook this up). On Windows, there's a flag on WM_POINTER* messages. On Android, it's ACTION_CANCEL on a MotionEvent. On iOS, it's UIResponder:touchesCancelled(). 

> 26. broken table
>
> http://www.w3.org/TR/2014/WD-pointerevents-20141113/#widl-Element-setPointerCapture-void-long-pointerId

>
> .prmNullFallse has a rule for text-align:center which cauess the x's to appear "centered" across a column.
>
> Unfortunately, nothing constrains the table width, and nothing constrains the column width. When the document is in a maximized browser, the x is so far away from the label (Nullable), or the next label (Optional), that it just appears to be floating.
>
> Fixes: Either constrain the width of the column, or don't use center as alignment. You could constrain the table, but I wouldn't suggest that.

Art and I did not repro this. The table is generated by ReSpec, so if there's a bug fix to be made, it should be made there (http://www.w3.org/respec/)

> 27. overly strong must
>
> http://www.w3.org/TR/2014/WD-pointerevents-20141113/#widl-Element-setPointerCapture-void-long-pointerId

>
> > Subsequent events for the pointer must always be targeted at this element. 
>
> This implies "forever", you need to say "until canceled" or "until {something}"

Indeed.  Fixed: https://dvcs.w3.org/hg/pointerevents/rev/45c0145ae825 

> 28. Too long, can't process
>
> http://www.w3.org/TR/2014/WD-pointerevents-20141113/#widl-Element-setPointerCapture-void-long-pointerId

>
> > Sets pointer capture for the pointer identified by the argument pointerId to the element on which this method is invoked.
> > Subsequent events for the pointer must always be targeted at this element.
> > The pointer must be in its active buttons state for this method to be effective, otherwise it fails silently.
> > Throws a DOMException with the name InvalidPointerId when the provided the method's argument does not match any of the active pointers.
>
> It's true that Pointer Capture defines this, but, this really isn't helpful. And the fact that what's important is hidden in an empty note ("See Pointer Capture") doesn't help either.
>
> There should be a link to h3_setting-pointer-capture

I've linked the text "Sets pointer capture" to h3_setting-pointer-capture (and similarly for releasePointerCapture): https://dvcs.w3.org/hg/pointerevents/rev/6e82a47ff2a4 

> 31. what happens if...
>
> http://www.w3.org/TR/2014/WD-pointerevents-20141113/#widl-Navigator-maxTouchPoints

>
> > The maximum number of simultaneous touch contacts supported by the device.
> > In the case of devices with multiple digitizers (e.g. multiple touchscreens),
> > the value must be the maximum of the set of maximum supported contacts by each individual digitizer.
>
> > maxTouchPoints is often used to ensure that the interaction model of the content can be recognized by the current hardware.
> > UI affordances can be provided to users with less capable hardware.
> > On platforms where the precise number of touch points is not known,
> > the minimum number guaranteed to be recognized is provided.
> > Therefore, it is possible for the number of recognized touch points to exceed the value of maxTouchPoints.
>
> Suppose a user has an attached touchpad which supports 5 touchpoints.
> Suppose the user only uses their mouse and is unaware of this touchpad (it could be physically obscured).
>
> There doesn't appear to be any authoring guidelines that they should be aware that just because some input method MAY support maxTouchPoints, doesn't mean that the user will be able to.
>
> Suppose that I have a phone which supports 5 touchpoints, and I'm using a screen reader.
>
> The mode of the screen reader involves replacing the standard input method with a method whereby there are at most 1 touch points accessible to the web page (I believe, I haven't actively investigated, but let's just suppose I'm right). Should the UA report 1 or 5 for maxTouchPoints? (The UA does know that the screen reader is active, and it knows how the screen reader controls the UA.)

You're right--this is good author guidance to add.  We discussed this briefly during this morning's telecon. I've added author guidance to this section: 
>> While a maxTouchPoints value of greater than 0 indicates the user's device is capable of supporting touch input, it does not necessarily mean the 
>> user *will* use touch input. Authors should be careful to also consider other input modalities that may be present on the system, such as mouse, pen, screen readers, etc.
https://dvcs.w3.org/hg/pointerevents/rev/af60ec71ceb3 

> 34. huh?
>
> http://www.w3.org/TR/2014/WD-pointerevents-20141113/#the-touch-action-css-property

>
> > During the execution of a behavior, the user agent must not fire subsequent pointer events for the pointer.
>
> I'm not sure what a "behavior" is here. Do you mean "an intrinsic user-agent behavior"?

The preceding context of this sentence explains what behavior is: " The touch-action CSS property determines whether touch input MAY trigger default behavior supplied by user agent." and goes on to provide more detailed descriptions of such behaviors in the definitions of the property's accepted values.
But just for extra clarity, I've  replaced "behavior" with "user agent touch behavior" to use the same language in the preceding text: https://dvcs.w3.org/hg/pointerevents/rev/ae192ac97a09 

> 36. missing conditional
>
> http://www.w3.org/TR/2014/WD-pointerevents-20141113/#implicit-release-of-pointer-capture

>
> > Immediately after firing the pointerup or pointercancel events,
> > a user agent must run the steps as if the releasePointerCapture()
> > method has been called with an argument equal to the pointerId
> > property of the pointerup orpointercancel event just dispatched.
>
> If I don't call Element.setPointerCapture() and a user clicks and releases, it sounds like the UA must process releasePointerCapture.
>
> Here are the steps:
>
> > 1. If the pointerId provided as the method's argument does not match any of the active pointers, then throw a DOMException with the name InvalidPointerId.
>
> It won't be active, I think. So now the UA must throw a DOMException?

Heh, yeah, the definition of active pointers is indeed strict such that invoking these steps "immediately after firing pointerup or pointercancel" would mean the pointer was no longer active.  I've bug fixed this by adding a conditional that skips throwing an exception if invoked via the implicit release of capture: https://dvcs.w3.org/hg/pointerevents/rev/7f2201dc58ac 

> 39. Document or document?
>
> http://www.w3.org/TR/2014/WD-pointerevents-20141113/#implicit-release-of-pointer-capture

>
> > If the pointer capture target override is removed from the document tree,
> > clear the pending pointer capture target override and pointer capture target override nodes and
> > fire a Pointer Event named lostpointercapture at the document.
>
> should `document` be a linked thing, or something something...

Ah yes, this should be "removed from its ownerDocument's tree" as discussed in previous sections. I've changed this and marked it up accordingly: https://dvcs.w3.org/hg/pointerevents/rev/1fd2b9bd8d85 

> 41. some cases
>
> http://www.w3.org/TR/2014/WD-pointerevents-20141113/#compatibility-mapping-with-mouse-events

>
> > The relative ordering of these high-level events (click, contextmenu, focus, blur, etc.)
> > with pointer events is undefined and varies between user agents. For example,
> > in some user agents contextmenu will often follow a pointerup,
> > in others it'll often precede a pointerup or pointercancel,
> > and in some situations it may be fired without any corresponding pointer event.
>
> Probably worth noting that it could be fired because of a keyboard key (the context menu key, or shift-f10). Yes somewhere else you mentioned keyboards, but it's worth mentioning it again.

Done. https://dvcs.w3.org/hg/pointerevents/rev/fb85c70bcb76

Received on Wednesday, 3 December 2014 00:39:48 UTC