Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editorial: drop Use cases and Requirements section #159

Merged
merged 2 commits into from
May 7, 2024
Merged

Editorial: drop Use cases and Requirements section #159

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
37c17c8
Editorial: drop Use cases and Requirements section
marcoscaceres May 2, 2024
cdb03ac
Merge branch 'main' into use_cases
marcoscaceres May 4, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 0 additions & 30 deletions index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -686,36 +686,6 @@ There are two user needs that can arise, which would likely be managed by the us
- For example: whilst the shake-to-undo feature can provide a natural and thoughtful interaction for some, for people with tremors, it may present a barrier. This could be managed by declining permission, or more likely by changing a browser or OS setting, coupled with the web app providing alternative input means.
* It is also important that the device's orientation can be locked - a primary use case being someone who is interacting with a touch device, such as a phone, non-visually. They may have built up 'muscle memory' as to where elements are on the screen in a given orientation, and having the layout shift would break their ability to navigate. Again, this would most likely be done at the operating system level.

Use-Cases and Requirements {#use-cases-and-requirements}
========================================================

<h3 id="use-cases">Use-Cases</h3>
<em>This section is non-normative.</em>

<h4 class="no-toc" id="controlling-a-game">Controlling a game</h4>
<em>This section is non-normative.</em>

A gaming Web application monitors the device's orientation and interprets tilting in a certain direction as a means to control an on-screen sprite.

<h4 class="no-toc" id="gesture-recognition">Gesture recognition</h4>
<em>This section is non-normative.</em>

A Web application monitors the device's acceleration and applies signal processing in order to recognize certain specific gestures. For example, using a shaking gesture to clear a web form.

<h4 class="no-toc" id="mapping">Mapping</h4>
<em>This section is non-normative.</em>

A mapping Web application uses the device's orientation to correctly align the map with reality.

<h3 id="requirements">Requirements</h3>
<em>This section is non-normative.</em>

* The specification must provide data that describes the physical orientation in space of the device.
* The specification must provide data that describes the motion in space of the device.
* The specification must allow Web applications to register for changes in the device's orientation.
* The specification must be agnostic to the underlying sources of orientation and motion data.
* The specification must use the existing DOM event framework.

Automation {#automation}
==========

Expand Down
Loading