RE: Why is the `touch-action` CSS property needed?

[Apologies for replying to the wrong thread earlier]



On Mon, Jun 24, 2013 at 7:54 AM, Rick Byers <rbyers@google.com<mailto:rbyers@google.com>> wrote:

>

> On Fri, Jun 21, 2013 at 7:06 PM, James Greene <james.m.greene@gmail.com<mailto:james.m.greene@gmail.com>> wrote:

>>

>> Thanks, Rick. Perusing through your links explained the situation well.

>>

>> Has there been any thought given to making `touch-action` an HTML element attribute rather than a CSS property? As I'm sure you're familiar, the CSS approach is very troublesome for polyfilling as browsers remove unrecognized CSS properties, and re-reading the stylesheets and implementing a CSS parser in JS is definitely suboptimal (though the "hand.js" polyfill makes a valiant effort in that regard). The other polyfills (Polymer, Points.js) already use an HTML element attribute instead because of this limitation.

>

> I don't think this WG has seriously discussed switching from CSS html attributes (although I think several of us agreed it's a reasonable thing for polyfills to do).  We imagine some scenarios where the power of CSS will be really helpful - eg. letting you apply touch-action: none to all elements of a given class.  But probably the main reason we haven't seriously debated the tradeoffs is for compatibility with the existing IE10 implementation (for the standard to be successful we know we can't change things so fundamentally that IE is left with a compat problem).  Perhaps Jacob can comment further on why IE10 went with CSS instead of HTML attributes.

>

> The difficulty of polyfilling is indeed a real problem.  But rather than avoid CSS because it's harder to polyfill, I think we should have a cross-browser effort to make CSS extensible through JavaScript.  Many new web platform features will continue to rely on CSS, and I don't think this 'don't use CSS for feature X because it makes it hard to polyfill' argument scales to the web at large.

>

> In the interim, mapping CSS properties to HTML attributes for partial polyfilling seems like a reasonable convention.



The ability to use selectors greatly enhances the flexibility and power of the API over just HTML attributes. It's common to want the same touch action on a class of elements.  Touch-action is also closely related to other CSS rules like overflow, scroll-snap-points, pointer-events, etc.. So it's convenient to keep related APIs in one place.



Definitely agree that polyfilling CSS is essentially impossible at the moment. That's something worth solving.  But, like Rick said, I don't think we should let the current state of CSS polyfilling influence how we design APIs.



>>

>> Having a DOM-based control for DOM events feels like a better separation of concerns to me than a CSS-based control for DOM events. Perhaps there is another problem with that approach that I'm unaware of, though, so please forgive my ignorance if that's the case.

>

> I agree that using CSS for this feels a little strange, as it's not strictly a presentation issue.  But this isn't really new.  The (confusingly named) pointer-events property (http://wiki.csswg.org/spec/css4-ui#pointer-events) which is already widely supported is similar in this respect.   It's also possible to use CSS properties like z-index to impact DOM events without otherwise changing presentation (eg. with transparent overlays).  There are other properties (eg. 'resize', 'nav-*', etc.) that aren't strictly about presentation.

>>

>> Sincerely,

>>    James Greene


-Jacob