Now that iOS exposes touch radius to applications (https://developer.apple.com/library/prerelease/ios/documentation/UIKit/Reference/UITouch_Class/#//apple_ref/occ/instp/UITouch/majorRadius), Safari should expose this to the web as well. There's a definition for Touch.radiusX/radiusY here: https://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html, and Chrome has implemented this (with webkit prefixes) for a long time. Test page: http://www.rbyers.net/paint.html We've been discussing improvements to the definition in the touch-events community group: http://lists.w3.org/Archives/Public/public-touchevents/2014Jun/0004.html, see my latest draft here: https://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html#widl-Touch-radiusX. One change not yet applied in the above version is changing the unit semantics from being based on screenX to pageX. In theory both are useful, but the most common scenario (drawing) really needs page units. Implementing this properly (eg. in the face if iframes under arbitrary CSS 3d transforms) is potentially difficult though. In any real world scenario the difference is unlikely to matter in practice so probably shouldn't block implementation. Chrome is considering unprefixing our radius properties (https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/rjLM4KvRrjk), so I'd encourage Safari to consider unprefixed properties as well.
Yep, this is worth looking into. I agree with the rationale for pageX instead of screenX. A drawing/annotation widget could appear anywhere on a page, at any scale factor, and it should be all the same from JavaScript. How should this affect Document.createTouch()? Is it specified?
The change to createTouch is not specified but should be (in practice we see barely any use of this API, so I haven't invested much in it). The blink implementation here is unchanged from WebKit (except that I just changed all our 'long' co-ordinates to 'double'), so WebKit already has the same API a blink here, eg: https://trac.webkit.org/browser/trunk/Source/WebCore/dom/Document.idl#L335 [ReturnNewObject, RaisesException] Touch createTouch([Default=Undefined] optional DOMWindow window, [Default=Undefined] optional EventTarget target, [Default=Undefined] optional long identifier, [Default=Undefined] optional long pageX, [Default=Undefined] optional long pageY, [Default=Undefined] optional long screenX, [Default=Undefined] optional long screenY, [Default=Undefined] optional long webkitRadiusX, [Default=Undefined] optional long webkitRadiusY, [Default=Undefined] optional unrestricted float webkitRotationAngle, [Default=Undefined] optional unrestricted float webkitForce);
Sounds good.
<rdar://problem/26798647>
I see iOS 10.3 exposes radiusX/radiusY now (and from http://rbyers.net/paint.html it seems to be hooked up to the native radius). Should this be marked Fixed now? Was 10.3 the first version or was it there previously before I noticed?