RE: Bug 20109 - Permitted values for pressure

On Wed, Feb 6, 2013 at 3:56 AM, Arthur Barstow <art.barstow@nokia.com> wrote:
>
> On 2/5/13 7:58 PM, ext Rick Byers wrote:
>>
>> On Monday, February 4, 2013, Jacob Rossi wrote:
>>
>>     Hey folks,
>>
>>     We took a second look at this issue and have a suggested tweak to
>>     the change we made [1]. In most pen enabled applications, mouse
>>     generally emulates /half/ the maximum pressure of pen. As an
>>
>>     example, Paint provides half the stroke width when using a mouse
>>     as compared with maximum pressure of a pen. This is generally in
>>     line with guidance Microsoft has given for pen drawing for quite
>>     some time: minimum pressure should be 50% stroke width, half-way
>>     pressure is 100% (e.g. what mouse should produce), and maximum
>>     pressure is 150% [2].
>>
>>     Given that, I reactivated this bug for us to consider making the
>>     value 0.5 rather than 1 when the device is in the active buttons
>>     state.
>>
>>
>> Having the default be intermediate between minimum and maximum makes sense to me, and will probably result in better behaving apps in general.
>>
>>     Similar to the pressure issue, the spec currently allows
>>     implementations to provide a width/height that's "typical of the
>>     device type" when the hardware doesn't support contact geometry
>>     [3]. But it doesn't require it. IE10 does not simulate
>>     width/height for devices that do not provide geometry. But I think
>>     we'd probably make IE do so in our next release, similar to
>>     emulating pressure. I'd like to consider making the MAY (optional)
>>     a SHOULD (recommended) in the spec for emulating width/height. I
>>     think the emulation we'd use in IE is:
>>
>>     Mouse, Pen - 1x1 width
>>
>>     Touch without hw support for geometry - about 40x40 CSS pixels ***
>>
>>
>> Yes, I like this change (the less UA-defined-behavior the better). Are you aware of any sites today that treat no-radius differently from some reasonable default radius (eg. I could imagine some UI features changing slightly when it's known that radius information is available)? If so then we may need to consider some mechanism to determine pointer capabilities, but without a compelling use case it's probably not worth the complexity.
>
>
> Thanks Rick.
>
> Jacob - I think we now have sufficient support for your proposal,so please implement it.
>
> -Thanks, Art
>

Done: https://dvcs.w3.org/hg/pointerevents/rev/f8d79fb0835c

Thanks!

-Jacob

Received on Thursday, 7 February 2013 02:10:57 UTC