- From: Rick Byers <notifications@github.com>
- Date: Sun, 03 Apr 2016 05:24:31 -0700
- To: w3c/touch-events <touch-events@noreply.github.com>
- Message-ID: <w3c/touch-events/issues/62/204958597@github.com>
FWIW, I disagree with the reasoning (though not necessarily the conclusion) here. Apple doesn't participate in this group, but they do care about interoperability on this API. All vendors implement features they feel are most valuable given the cost. So, for example, when the iPhone got force touch, Apple implemented the `force` property as we specified (rather than add a new API that matched the iOS API). They also [implemented cancelable](https://bugs.webkit.org/show_bug.cgi?id=141456) when we changed the spec. They've also shown [interest](https://bugs.webkit.org/show_bug.cgi?id=133180) in implementing some of the other small features done by this group. I don't mean to defend Apple, they really should be involved in this group and their lawyers really did hurt the standardization process. But if there's a feature of touch events that would be really useful to developers then we should totally discuss it here, ship it in other browsers, and encourage Apple to add it to Safari. But I agree the bar is rather high as most browsers are focused on PointerEvents for the future of input. In this case, [GeomteryUtils](https://drafts.csswg.org/cssom-view/#the-geometryutils-interface) should achieve the same benefit, right? So since all browsers are already talking about adding that, there's probably not much value in augmenting `Touch`. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/touch-events/issues/62#issuecomment-204958597
Received on Sunday, 3 April 2016 12:25:26 UTC