RE: contact geometry definition improvement suggestion

From: Brandon Wallace <brandon.wallace@yahoo.com> 
Date: Wed, 26 Sep 2012 09:18:29 -0700 (PDT)
Message-ID: <1348676309.43061.YahooMailNeo@web113618.mail.gq1.yahoo.com> 
To: "public-pointer-events@w3.org" <public-pointer-events@w3.org> 

> According to http://www.w3.org/Submission/2012/SUBM-pointer-events-20120907/, the contact geometry of a PointerEvent is represented only as > a { width, height } which implies a geometry that can only be an axis-aligned rectangle (or ellipse I suppose).  What about hardware which supports > more accurate contact geometry information?  For example, with the current specification, I cannot easily tell if a user puts a finger on the screen > and then rotates the finger, even though my hardware supplies this information. Can more information be added to more fully specify the contact > area?  At a minimum, adding a rotation angle would allow for the geometry to not be aligned with the screen.
> Brandon

I think basic axis-aligned rectangular geometry will satisfy the vast majority of scenarios (e.g. detecting if the contact overlaps an element, comparing relative sizes of touches, adjusting paint brush widths based on contact size, etc.).  Hardware support for non-retangular or non-axis-aligned geometry exists is extremely limited (to the best of my knowledge). On Windows, the standard device protocol only supports axis-aligned rects [1]. When drafting our spec proposal, we intended to scope it to the device properties that we thought could achieve reasonable interoperability/ubiquity, which I'm skeptical could be achieved with complex geometry.

If there are compelling use cases and backed hardware support, though, pointer events could certainly support this. For example, IE10 actually has an additional PointerEvent property called rotation which isn't included in our initial proposal [2].  In our implementation, rotation only applies to pen stylus rotation about its major axis (e.g. "twisting" the pen). But as it turns out, hardware support is very limited for that as well (thus we left it out of our initial proposal). That property could certainly due double-duty and be a contact rotation when the input is touch.  But again, I think it's only worth consideration if we think there'd be pervasive hardware support.

-Jacob

[1] http://msdn.microsoft.com/en-us/library/windows/hardware/br259100.aspx 
[2] http://msdn.microsoft.com/en-US/library/ie/hh772103.aspx *

*Errata:  the intermediatePoints and currentPoint properties are not available in IE10, this is a documentation error.

Received on Friday, 28 September 2012 01:13:30 UTC