fastclick

[wheresrhys]

As mobile browser vendors now universally(?) implement something like fastclick's behaviour natively, is there a case for adding fastclick as a polyfill? It's a bit of a weird case as it's not a spec, and would be better described as normalisation rather than polyfilling, but thought I'd float the idea. The advantage is it gives access to polyfill service's robust mechanism for selectively applying fastclick only to browsers that need it

[wheresrhys]

and it goes without saying it shouldn't be part of the default set

[triblondon]

Hmm. It's not a JS API. We do have precedent for polyfilling non JS stuff, like ~html-elements for the HTML5shiv, but is fastclick comparable to HTML5Shiv?

[wheresrhys]

I wouldn't say so, but worth considering on its own merits.

[triblondon]

Have you asked Rowan about it?

[rowanbeentje]

Interesting. Mixed feelings about this but on old mobile browsers I'd agree on balance that this is now the expected behaviour.

However as well as only applying to older mobile UAs, the polyfill service would also have to take care to apply only where the document meta tags match the current native patterns (eg viewport <= device-width). Are there any precedents for doing this?

[callumlocke]

is fastclick comparable to HTML5Shiv?

The only significant difference I can see is that html5shiv makes something 'work' whereas fastclick makes something 'work normally'. But I don't think that difference is a strong argument against.

And this is a strong pro, imo:

The advantage is it gives access to polyfill service's robust mechanism for selectively applying fastclick only to browsers that need it

I didn't like the idea from the headline but now I like it. As a non-default feature.

[triblondon]

@rowanbeentje no, the service can only distinguish based on UA, so it would need to err to the false positive and read the meta tags within the polyfill. Does it do this, or does it apply fastclick behaviour by default regardless of the meta tag values?

[rowanbeentje]

fastclick will currently trust the user to apply it to sites which benefit from it; enabling it in a default polyfill may result in a serious loss of accessibility for sites expecting support for double-tap-to-zoon. It won't enable itself where UA+meta suggest the browser will supply that behaviour itself, but that also means it'll be included needlessly in the polyfill download for (say) Chrome 49 where it won't be needed.

[wheresrhys]

... which is no worse than current behaviour e.g. on next every browser gets a copy of fastclick. This will enable us to stop sending it to any browser released in the past year or so

[gajus]

What about adding a polyfill for the the touch-action CSS property (https://twitter.com/kuizinas/status/698443022338547712)?

Specifically, the polyfill would need to check if browser supports touch-action property and if it does not, then it would scan loaded css documents, see those style declarations that include touch-action property and use https://github.com/ftlabs/fastclick to handle event within the target elements?

[triblondon]

OK, I'd accept a PR for this.

[wheresrhys]

I'm tidying up all my old open issues. Reopen if this is still needed, which I sincerely doubt