Re: Spec feedback

On Wed, Feb 13, 2013 at 9:51 PM, Tab Atkins <tabatkins@google.com> wrote:

> On Tue, Feb 12, 2013 at 7:27 AM, Alex Russell <slightlyoff@google.com>
> wrote:
> > 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.
>
> 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.
>

Right (although I'd say "what that hit _may_ do" since it just
enables/disable actions which are controlled via other mechanisms such as
overflow).

Also touch-action is specific to touch input because there is more
ambiguity around user intent there than with other pointer types (due to
touch scrolling), and it's more important to reduce latency for
direct-contact.  The closest scenario with mouse is mousewheel input -
should mousewheel cause scrolling or send events to the page which it
handles.   I suppose one could make an argument that touch-action should be
generalized into some sort of pointer-action, but I think the extra value
is small and additional conceptual complexity fairly high.


> ~TJ
>