RE: Touch-action to SVG elements

Maybe it’s just me, but as a non-native speaker, I had to think twice to parse the word “but”. I’d suggest using “, except” instead.
- Cathy.

From: ext Jacob Rossi [mailto:Jacob.Rossi@microsoft.com]
Sent: Tuesday, March 25, 2014 2:59 PM
To: Rick Byers
Cc: public-pointer-events@w3.org; gnanasekar.s@samsung.com; Douglas Schepers
Subject: RE: Touch-action to SVG elements

Spec has been updated:

https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#the-touch-action-css-property


-Jacob

From: Rick Byers [mailto:rbyers@google.com]
Sent: Tuesday, March 25, 2014 9:24 AM
To: Jacob Rossi
Cc: public-pointer-events@w3.org<mailto:public-pointer-events@w3.org>; gnanasekar.s@samsung.com<mailto:gnanasekar.s@samsung.com>; Douglas Schepers
Subject: Re: Touch-action to SVG elements

Thanks Jacob!

To re-iterate what I said on the call today: this definition seems fine to me, we'll update our implementation to match after the draft spec has been updated.  Blink bug: https://crbug.com/356215


Thanks,
  Rick

On Fri, Mar 21, 2014 at 3:09 PM, Jacob Rossi <Jacob.Rossi@microsoft.com<mailto:Jacob.Rossi@microsoft.com>> wrote:
Following up on this thread (and action 65).

From: Rick Byers <rbyers@google.com<mailto:rbyers@google.com>>
Date: Fri, 17 Jan 2014 11:17:47 -0500

> *Jacob, *do you agree that the behavior we see in IE is what we want the
spec to describe (touch-action supported on <svg> elements, but not other
types of SVG elements)?

Yes.

> *Jacob/Doug*, what's the right wording to convey this precisely?  My
reading of the SVG spec is that "SVG elements" includes things like <path>,
etc.
>
> In addition, it seems IE applies touch-action on inline-block elements
(which I think makes sense).  My reading of the CSS spec is that
inline-block isn't necessarily included with "block level elements".  Is
there a more precise term to encompass display: block and display:
inline-block?
>
> What about the other display types that establish a BOX but aren't
themselves BLOCKS (eg. table-row, table-cell), what's the expected behavior
for them?  Sorry I'm not enough of a CSS expert to know the precise terms
we're looking for here (and it wasn't obvious to me from the CSS spec).

I consulted with some of our CSS WG reps and also did testing to confirm IE's behavior. It looks like <svg> shouldn't be a special case. It is no different than <img>, which is a replaced inline element (not block-level) and supports touch-action. So the current spec text is incorrect.

The correct definition should match that of the intersection of the height and width properties from CSS2.1 [1,2]:
     Applies to:  all elements but non-replaced inline elements, table rows, row groups, table columns, and column groups

Put another way, it applies to any element that *both* width and height apply to in CSS. Note table rows only accept height and table cols only accept width, therefore touch-action applies to neither by this definition (also cols are effectively display: none; so they were already irrelevant).

This means block elements (like div), inline-block elements (like button), replaced inline elements (like img, svg, canvas, video), tables, and table cells/headers/captions are supported. But non-replaced inline elements (like span), table col/row elements, and table col/row groups are not supported.

I propose we change the spec to match the applies to text above. Testing briefly [3] Chrome, it looks like the replaced inline elements (img, svg, canvas, etc) and input controls aren't supported but should be. Firefox has the same issue as Chrome, except that <img> is already correctly supported. We should probably convert this page into an actual test case.

-Jacob

[1] http://www.w3.org/TR/CSS21/visudet.html#the-width-property

[2] http://www.w3.org/TR/CSS21/visudet.html#the-height-property

[3] http://jsfiddle.net/S9C5Y/3/embedded/result/