Re: Add 'manipulation' touch-action property?

On 11/03/2014 04:52, Jacob Rossi wrote:
> Resending (sent too soon!)
> With my implementer’s hat on, I see little value in the change for end
> developers. I don’t have an issue with changing our implementation, but
> it may be a while before I can get this fix prioritized just given its
> near zero impact.
> Arguably, if someone is specifying “manipulation pan-x”, then they do
> not properly understand the meaning of the values are on a failure path.
> In that light, it’s perhaps better that the rule fail outright signaling
> to the developer in testing that they’ve made a mistake.
> But, web APIs are, in general, more forgiving. So I see no real harm in
> allowing “manipulation pan-x” as it’s clear what touch behaviors the
> developer is asking for.
> Either way, I think arguments are weak since this is something >99% of
> developers will never encounter. So I’m happy to go with the consensus
> of the group on this one.

Personally, I'd like to see the wording/syntax of the spec being 
unambiguous and logical. How user agents then error-correct (e.g. IE's 
current implementation) combinations like "manipulation pan-x" can stay 
the same (giving the "forgiving" aspect of web APIs) without the need to 
explicitly spec that part?

In short: I'd be in favor of changing the syntax in the spec as per 
Rick's suggestion, but without requiring IE to change its 
error-correction mechanism, and without failing the rule outright 
(unless this is felt to be too "magic behavior" which could land devs 
into more trouble further down the line if browsers start 
error-correcting in different ways that aren't spec'd).


> *From:*Rick Byers []
> *Sent:* Monday, March 10, 2014 5:04 PM
> *To:* Jacob Rossi
> *Cc:*; ext Matt Brubeck; Patrick H. Lauke;
> Nikolay Lebedev
> *Subject:* RE: Add 'manipulation' touch-action property?
> If the compat risk is low, then perhaps we should consider using the
> more logical definition?  IE would of course be free to continue to
> implement a superset of the specd grammar.
> On Mar 10, 2014 4:37 PM, "Jacob Rossi" <
> <>> wrote:
>     On Fri, Mar 7, 2014 at 2:38 PM, Rick Byers <
>     <>> wrote:
>      >
>      > On Fri, Mar 7, 2014 at 5:30 PM, Jacob Rossi
>     < <>> wrote:
>      >>
>      >> The MSDN docs certainly don’t match our implementation (we’ll
>     fix that).  The spec’s current grammar does match our implementation.
>      >>
>      >>
>      >>
>      >> I agree it’s a tad quirky that “manipulation pan-x” works but
>     “pan-x pan-x” doesn’t (seeing as manipulation is essentially
>     shorthand for “pan-x pan-y other-goo”. “auto” / “none” are typically
>     never combinable with other values in any property though.
>      >>
>      >>
>      >>
>      >> While it is probably sub-optimal, It passes the “I can live with
>     it” test for me too.
>      >
>      >
>      > I assume changing this has a non-trivial risk of breaking some
>     website, right?  Do you have any data on this?  I can query the
>     google search index for sites that specify them together in CSS if
>     you think there's a chance we'd change the spec and IE behavior if
>     it was found to be sufficiently non-breaking.  If we can be
>     confident that it's unlikely to break anyone, then we might as well
>     make it right - no?  I.e. we should only apply the "I can live with
>     it" test if there's some reason to live with it :-)
>     The results I have from Bing yielded no known usage of
>     "touch-action: <something> manipulation;" or "touch-action:
>     manipulation <something>;". That only covers statically defined
>     properties; but in my experience with compat and touch-action this
>     has shown to be a sufficient measure. This also assumes my regex fu
>     was strong. :-)
>     touch-action:([\s]*[a-z-]+[\s]manipulation)|([\s]*manipulation[\s]+[a-z-]+)[\s]*;

Patrick H. Lauke
Accessibility consultant
The Paciello Group (UK office)

Received on Tuesday, 11 March 2014 08:28:17 UTC