Re: Can we change default radius to 0 in the touch events extensions

I agree this would be a good change - thanks Rob!

In my paint test app (http://www.rbyers.net/paint.html) I handle this by
considering radius as supported only if I ever see a radius value >1.  This
breaks down in multi-monitor scenarios.  Eg. if I hook up an external
touchscreen to my chromebook pixel and touch on the internal display then
it'll draw circles that match my finger sizes, but if I then move that
window to the external display all the touch points are tiny because the
radius reported by the external display is 1.  I'd much prefer to rely on a
reserved value like 0 to be mean not supported.

The downside is that apps may need to special-case 0, but I'd argue that
was almost certainly already the case for 1 (a radius of 1 css px is almost
certainly too small to be a useful radius for any default use case).

I'm guessing there's some history here around the choice of 1 (I probably
even heard it at one point, but have forgotten).  Perhaps Matt can
enlighten us.

While we're on the topic, I think radius should also be 'double' instead of
'long' - for the same reasons we're changing this in the pointer events
spec (https://www.w3.org/Bugs/Public/show_bug.cgi?id=25758).

If there's agreement on these points I'd be happy to make an edit to the
extensions doc and update blink's implementation to match.  In both cases I
think the risk of compat issues is pretty low (once Chrome 36 hits beta
I'll have usage stats on it, but I expect it's low and any reasonable
existing usage should be unaffected by this change).

Rick



On Thu, May 29, 2014 at 11:35 AM, Robert Flack <flackr@chromium.org> wrote:

> I noticed in the touch events extensions spec
> http://www.w3.org/TR/touch-events-extensions/ that the default radiusX
> and radiusY is 1 if no value is known.
>
> It seems odd to me to use a value that could be legitimately reported by
> supporting hardware. Would it be reasonable to change the default to 0?
> This way if users want to they can easily detect and set a sensible
> application default radius (i.e. var radiusX = event.touches[i].radiusX ||
> 15;) instead of risking ignoring a real radius of 1.
>
> It seems to me like force can already be treated this way as a force of 0
> doesn't feel like it would legitimately be reported by supporting hardware
> for an actual touch (assuming a touch always has some pressure).
>
> Unless it's common to divide by radius I imagine this wouldn't cause a
> problem for existing uses of radius.
>
> Thanks,
> Rob
>