W3C home > Mailing lists > Public > public-pointer-events@w3.org > October to December 2012

RE: contact geometry definition improvement suggestion

From: Pierre Saslawsky <pierre.saslawsky@sencha.com>
Date: Fri, 21 Dec 2012 14:30:31 -0800
Message-Id: <6E1563B1-4A2B-4DDE-A4CE-8AA0852D0335@sencha.com>
To: public-pointer-events@w3.org
> 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.

If "reasonable ubiquity" and "pervasive support" were requirements in the development of specifications, we'd only write them in reaction to what is experienced each time as a mess in the marketplace, instead of acting as enablers of new applications and technologies.

Brush styluses are available; graphic artists and photographers are using them on tablets in association to apps that did not exist a year ago. A very distinctive feature of a brush is, of course, the shape. It cannot be conveyed through the parameters we have now in the PointerEvent and it would not take much effort at the spec level to support these devices. All is needed is the addition of a 'mask-image' (http://www.w3.org/TR/css-masking/#the-mask-image).

This change would not be a hinderance to the adoption of the spec (if the mask is not available, UAs can omit it or leave it blank). So could we include it now?

Received on Saturday, 22 December 2012 22:44:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:48:06 UTC