Consider parsing CSS for touch-action

[RByers]

Since polyfilling CSS is hard, we look for touch-action as an HTML attribute instead of a CSS property. This is probably the right trade-off in most cases (until browsers have native support for at least parsing the touch-action CSS property).

But perhaps we should consider having an option (not included in the build by default?) to make a best effort at parsing from CSS like other CSS polyfills (eg. using http://www.glazman.org/JSCSSP/), just to have the ability to be maximally spec compliant.

[dfreedm]

I'm not confident that the complexity required to parse CSS will be worth the payoff, particularly if trying to capture any dynamism.
Currently, I emit a stylesheet that will match the touch-action attribute usage to the spec property values like so:

[touch-action="none"] {
  touch-action: none;
  -ms-touch-action: none;
}

This seems to have the most bang for my buck. As for JSCSSP in particular, it's almost 3x the size of PointerEvents, and requires me to feed it stylesheet's i've XHR'd, which may have CORS issues and other nasties.

[RByers]

Yeah, understood.
Another option to consider - CSS variables are designed to be useful for CSS polyfills (with 'var-' as sort of an author prefix) - see http://dev.w3.org/csswg/css-variables/#using. Supporting a 'var-touch-action' CSS property on browsers that support CSS variables could be valuable - eg. to allow a site to control the touch action of an entire class of elements at the same time (see this recent thread for discussion on why CSS was chosen over HTML attributes: http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0201.html)

[dfreedm]

That's a good idea, but I'm not aware of many browsers having variable support, or of any browsers supporting the CSSOM JS variable interface: http://dev.w3.org/csswg/css-variables/#the-CSSVariablesMap-interface.

There's no other way to access variables except via style attribute, but then I'm back to attribute watching again.