Re: maxTouchPoints on platforms that have less granular information

That sounds perfect, thanks Jacob!


On Thu, Oct 31, 2013 at 2:29 PM, Jacob Rossi <Jacob.Rossi@microsoft.com>wrote:

> Given a platform that has less granular information than required, I think
> your approach (minimum guaranteed) is the best.  I'm OK with adding a note.
> But a non-normative note cannot use RFC2119 keywords, like "should." [1]
>  Here's an alternative:
>
> "Note: maxTouchPoints is often used to ensure that the interaction model
> of the content can be recognized by the current hardware. UI affordances
> can be provided to users with less capable hardware. On platforms where the
> precise number of touch points is not known, the minimum number guaranteed
> to be recognized is provided. Therefore, it is possible for the number of
> recognized touch points to exceed the value of maxTouchPoints."
>
> -Jacob
>
> [1] http://www.w3.org/TR/pointerevents/#conformance
>
> On Thu, Oct 10, 2013 at 3:36 PM, Rick Byers <rbyers@google.com> wrote:
> I just learned that Android doesn't have an API to report the exact number
> of touch points supported.  Instead it has a few levels (1, 2+, 5+).  See
> http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_TOUCHSCREEN
> .
>
> Should we consider adding a non-normative note or something suggesting how
> such platforms should implement this API?  Eg:
>
> Note: some platforms may not report the precise number of touch points
> available.  On such platforms, this API should return the minimum
> guaranteed number of points that an application can rely on being
> available.  For example, on Android systems
> reporting FEATURE_TOUCHSCREEN_MULTITOUCH_DISTINCT (but not
> FEATURE_TOUCHSCREEN_MULTITOUCH_JAZZHAND) this should return 2.
>
> I.e. this API should be used to control the addition of additional UI to
> compensate for the lack of sufficient touch points (such as showing zoom
> controls on a single-finger device), not as a limit on the number of touch
> points that should actually be handled by the application.
>
> Sorry I wasn't aware of this as a potential issue sooner.
>
> Rick
>