RE: contact geometry definition improvement suggestion

From: Pierre Saslawsky
Sent: ‎December‎ ‎22‎, ‎2012 ‎2‎:‎44‎ ‎PM
To: public-pointer-events@w3.org
Subject: RE: contact geometry definition improvement suggestion
[..]

> 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.
For a spec that deals with reporting of hardware events, it’s important to demonstrate feasibility.  Otherwise, you might end up with APIs that can’t reliably be used (our principle goal for standards is to promote interoperability). Worse yet, APIs designed in the absence of well demonstrated implementability often result in flaws. For example, an API might be inherently slow because it doesn’t have good parity with the functionality hardware natively provides, thus requiring a lot of software adjustment to fit what the hardware provides to the API shape that the spec dictates.

> 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 is a great example of my point above. What you’re proposing is clearly a useful feature in the general sense. In fact, we experimented with complex geometry support at one point. But what we found was that:
(a) almost no hardware was capable of actually reporting this data
(b) on hardware that does support this, you generally have to do software curve fitting to make the data useful, which is very slow when you consider many touch devices provide input at 200Hz

As hardware advances, implementing this attractive scenario might become more realistic. When good hardware support exists, we can ultimately design a better API that’s designed to leverage the hardware more fully.

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

Actually, it could be. For every feature, we need to demonstrate 2 interoperable implementations. Based on my reasons above, I do not believe this could be achieved for your proposal (in the current schedule chartered for this spec), which could block its progress.

That said, I totally get your scenario and think it’s something worth considering. We’re starting a list of  possible “Version 2” features and this is probably a great one to add.