Re: [w3c/gamepad] Add a model section (PR #220)

@nondebug commented on this pull request.



> +        list is ordered such that [=touch surfaces=] closer to the left side of
+        the [=gamepad=] appear closer to the start of the list.
+      </p>
+      <p>
+        A [=touch surface=] has an <dfn>active touch point list</dfn> [=input
+        value=], a [=list=] of zero or more [=touch points=] representing the
+        points of contact currently detected by the sensor, ordered such that
+        earlier [=touch points=] appear closer to the start of the [=list=]. A
+        <dfn>touch point</dfn> represents a single point of contact at a single
+        point in time. A [=touch point=] has a <dfn>touch x coordinate</dfn>
+        representing its position along the user's left-right axis and a
+        <dfn>touch y coordinate</dfn> representing its position along the
+        perpendicular axis.
+      </p>
+      <p>
+        A [=touch surface=] may have surface dimension [=input values=]. The

I went back and forth on this. In general I want to divide gamepad properties into "read when the gamepad is first connected and never changes" and "read each time inputs are read from the gamepad". We don't expect touch surface dimensions to change since they're supposed to represent the dimensions of the hardware touch sensor. But we never require that they *can't* change, so it seems safer to treat them as if they could change. What if it's a virtual gamepad that lets the user resize the touch surface area?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/pull/220#discussion_r2061137267
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/gamepad/pull/220/review/2795710272@github.com>