Bug 20109 - Permitted values for pressure
Summary: Permitted values for pressure
Status: RESOLVED FIXED
Alias: None
Product: PointerEventsWG
Classification: Unclassified
Component: Pointer Events specification (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Jacob Rossi [MSFT]
QA Contact: This bug has no owner yet - up for the taking
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-28 01:16 UTC by Jacob Rossi [MSFT]
Modified: 2013-02-07 02:08 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jacob Rossi [MSFT] 2012-11-28 01:16:15 UTC
Opening on behalf of François Remy.

Current spec text defines pressure as a normalized value where 0 is no pressure and 1 is maximum pressure.  This creates a potential issue where more capable devices are penalized such to work on the same range of values, meaning a user may have to apply more pressure on one device to achieve the same result as another.  

Detailed discussion:
http://lists.w3.org/Archives/Public/public-pointer-events/2012OctDec/0018.html
Comment 1 Jacob Rossi [MSFT] 2012-12-09 19:57:25 UTC
12/4 telecon resolution:

-For devices that do not support pressure (e.g. a mouse), pressure must be 1 when in the active buttons state and 0 otherwise.
-Pressure will remain normalized (e.g. in the range of [0,1]) (no change)

http://lists.w3.org/Archives/Public/public-pointer-events/2012OctDec/0091.html

Change: http://dvcs.w3.org/hg/pointerevents/rev/47212a0ea91c
Comment 2 Jacob Rossi [MSFT] 2013-02-05 04:52:43 UTC
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. 

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 ***

This “smart default” approach should also apply to tiltX/tiltY, but the existing default of 0 seems appropriate for those (e.g. the stylus is normal to the screen).

-Jacob

*** Adjusted for zoom. 40 CSS pixels is approximately 11mm, the average width of a touch contact [4].

[1] http://dvcs.w3.org/hg/pointerevents/rev/47212a0ea91c
[2] http://msdn.microsoft.com/en-us/subscriptions/cc300776.aspx#S11 
[3] https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#widl-PointerEvent-width 
[4] http://bit.ly/win8touchguidance