RE: Spec feedback

On Tue, Feb 12, 2013 at 7:27 AM, Alex Russell <slightlyoff@google.com> wrote:
>
> Hi all,
>
> I had a chance to sit down with Rick Byers while he's been visiting London and review the current draft of the spec from a JS/layering perspective. What follows is are non-linear comments from the discussion.

Thanks. Apologies for my late response.

> The spec should lead with examples, i.e., move Section 9 to where Section 2 is now.

That seems like fair editorial feedback. It'll mean more scrolling down to the interesting bits for us browser folk. :-)  But I think you're right that leading with the examples is best for most readers.

> pointerId is very strange. 3.1 suggests that mouses must have an ID of 1, but there's no other reasonable scenario for using integer values (what does zero mean? 30?). Having an opaque object instead feels like it'll satisfy the needs for identity comparison and for passing through to setPointerCapture()

I'll join the ongoing conversation on the other thread.  I think there are a number of useful qualities that integers bring to the table. The fact that mouse must be 1 is more of an implementation detail, though. 

> I'm concerned about the extensibility storay (see below for a related discussion of the layering question): if someone plumbs a new, exotic type of input device through an OS and browser to the page, it's natural for pre-standards additions to the ecosystem to want to pass extra metadata along. The current spec doesn't have an advertised slot for "extra metadata goes here!". This is dangerous in the long-run as it suggests that the objects/events either shouldn't be extended (likely wrong) or extended on the event object directly, creating naming collision hazards later. I'd like to see an extraData slot specified on these event objects, defaulting to null, that can be used for this. When new pointer types become prevalent, this group can observe fields from these objects and standardize them in the primary event object.

"extra metadata goes here"  -- I would expect UAs to extend the object, but with vendor prefixes to avoid the name collisions, such as what was done for Mozilla's mozInputSource property on MouseEvent.

> The buttons field is painful as bitfield math is anything but natural in JS. That it's pre-existing on MouseEvent seems the only virtue. Consider this a note that users are likely to cringe, not an objection or suggestion.

I'm not the world's biggest fan either. But I think there's value in bringing forward from MouseEvent to aid in migration, a particular goal for this spec. I wouldn't be opposed to adding a new way to read button state in the V2 spec though (keeping the buttons field intact, though).

> The new touch-action CSS property seems to have conceptual overlap with the pointer-events property. If nothing else, the naming (and explicit callout to "touch" in the naming) creates huge ambiguity. Anyone who wants to allow some clicks through, but not dragging, is likely to find themselves wading through multiple properties who interaction is ambiguious at best. I haven't though hard enough about this to know if the properties can (or should) be merged, but it seems like an exercise the WG should attempt, if only to identify a strong argument against merging them.

I agree with Tab's response here:
>> They shouldn't be merged, as they do substantially different things.
>> One controls what parts of the element are opaque/transparent to hit detection at all.  The other controls, once a hit has been registered, what that hit should do.


> navigator.maxTouchPoints seems deeply touch-specific. Also, is it dynamic? If I plug in a touchpad that support 5 or 6 (and I've only had 1 or 2 before), what (if anything) happens? Also, isn't this a fingerprinting risk? Why not make this a property of the events to solve both?

It is touch specific. In IE10, it is not dynamic (cached on document load) as changes are rare. I think the fingerprinting risk is low. The presence of touch hardware is generally already available from touch events via detecting ontouchstart. I'm not a fan of putting it on the event because:

(a) it's not meta data about the event at hand, whereas all the other properties on the event are.
(b) I don't think it changes the fingerprinting risk much, anyway. The chances of the user loading a document and never interacting with it are pretty low.

> Section 8 makes me terribly nervous that, for all the clarity in the introduction about the event funnel in the introduction, the WG does not have  firm conceptual model for wether or not the spec is describing a high-level or low-level event source. In particular:
> Synthesizing mouse events, while possibly a reasonable thing to do in an event sink like the implicit controller that Pointer Events defines, seems to imply that mouse events are not a lower-level event type out of which pointer events are created.
> The hover generation in 8.2 is particularly disturbing. If pointer events are conceptually a high-level synthesis of lower-level event sources (a filter, if you will), then perhaps there is room to generate high-level (synthesized) mouse events, but the MouseEvent spec conflates very low-level events (down, move, up) with high-level synthesized events (click, enter, out). To get some sanity here, splitting mouse (and other types of pointer) events into low-level synthesized events and specifiying how pointer events layer into this world seems like the only reasonable thing to do.
> We may need to continue to specify that pointer events syntesize other sorts of events, but it should be possible to generate low-level events in JS and have Pointer Events synthesize these events for them too.

Sorry, I'm not quite sure I groked your issue or change proposal here. But perhaps I can try to clarify the positioning of this spec.

The pointer event spec does not require other device events be supported (e.g. mouse events, touch events, etc.). Further, the spec does not define pointer events as being generated from some other set of events. A user agent could support pointer events without supporting any other device events. It's an "input sink" really, rather than an "event" sink. Hence why the funnel in the introduction says "touch," "mouse," and "pen"-not "TouchEvent," "MouseEvent," and "PenEvent" (sic).

That said, the spec is pragmatic that web browsers are the primary targeted user agents and they have a significant compatibility issue because the  current web codes to mouse events. So other device types synthesize mouse events for the sake of compatibility with this content. This section is optional and only intended for user agents that have this compatibility problem, which most will.

Received on Monday, 4 March 2013 00:05:33 UTC