Skip to content
Permalink
Browse files

Remove normative references from informative sections

The only substantive change here is that [COMPAT] is now purely an informative, rather than normative, reference - which is correct, since [COMPAT] only contains additional touch-action values, and is
not required normatively for this spec. All other references that were changes are already normatively referenced outside of informative sections ([HTML5], [UIEVENTS])
  • Loading branch information...
patrickhlauke committed Nov 28, 2018
1 parent ec802c8 commit d2779fe71e3b1c26d6b4657ad0330bed378b8b69
Showing with 5 additions and 5 deletions.
  1. +5 −5 index.html
@@ -80,7 +80,7 @@

<section id="intro" class="informative">
<h1>Introduction</h1>
<p>Today, most [[HTML5]] content is used with and/or designed for mouse input. Those that handle input in a custom manner typically code to [[!UIEVENTS]] Mouse Events. Newer computing devices today, however, incorporate other forms of input, including touchscreens, pen input, etc. Event types have been proposed for handling each of these forms of input individually. However, that approach often incurs unnecessary duplication of logic and event handling overhead when adding support for a new input type. This often creates a compatibility problem when content is written with only one device type in mind. Additionally, for compatibility with existing mouse-based content, most <a data-lt="user agent">user agents</a> fire Mouse Events for all input types. This makes it ambiguous whether a Mouse Event represents an actual mouse device or is being produced from another input type for compatibility, which makes it hard to code to both device types simultaneously.</p>
<p>Today, most [[HTML5]] content is used with and/or designed for mouse input. Those that handle input in a custom manner typically code to [[UIEVENTS]] Mouse Events. Newer computing devices today, however, incorporate other forms of input, including touchscreens, pen input, etc. Event types have been proposed for handling each of these forms of input individually. However, that approach often incurs unnecessary duplication of logic and event handling overhead when adding support for a new input type. This often creates a compatibility problem when content is written with only one device type in mind. Additionally, for compatibility with existing mouse-based content, most <a data-lt="user agent">user agents</a> fire Mouse Events for all input types. This makes it ambiguous whether a Mouse Event represents an actual mouse device or is being produced from another input type for compatibility, which makes it hard to code to both device types simultaneously.</p>

<p>To reduce the cost of coding to multiple input types and also to help with the above described ambiguity with Mouse Events, this specifications defines a more abstract form of input, called a <a>pointer</a>. A pointer can be any point of contact on the screen made by a mouse cursor, pen, touch (including multi-touch), or other pointing input device. This model makes it easier to write sites and applications that work well no matter what hardware the user has. For scenarios when device-specific handling is desired, this specification also defines properties for inspecting the device type which produced the event. The primary goal is to provide a single set of events and interfaces that allow for easier authoring for cross-device pointer input while still allowing for device-specific handling only when necessary for an augmented experience.</p>
<p> An additional key goal is to enable multi-threaded user agents to handle default touch actions, such as scrolling, without blocking on script execution.</p>
@@ -228,10 +228,10 @@ <h1>Glossary</h1>
<li>If a touch contact or pen stylus is lifted beyond the range of the digitizer, then it is no longer considered active.</li>
</ul>
<div class="note">On some platforms, the set of active pointers includes all pointer input to the device, including any that are not targeted at the user agent (e.g. those targeted at other applications).</div>
<div class="note">Each active pointer should have the same id within the scope of the <a href="https://www.w3.org/TR/html5/browsers.html#top-level-browsing-context">top-level browsing context</a> (as defined by [[!HTML5]]). However, there is no such guarantee across multiple <a href="https://www.w3.org/TR/html5/browsers.html#top-level-browsing-context">top-level browsing contexts</a>. </div>
<div class="note">Each active pointer should have the same id within the scope of the <a href="https://www.w3.org/TR/html5/browsers.html#top-level-browsing-context">top-level browsing context</a> (as defined by [[HTML5]]). However, there is no such guarantee across multiple <a href="https://www.w3.org/TR/html5/browsers.html#top-level-browsing-context">top-level browsing contexts</a>. </div>
</dd>
<dt><dfn>canceled event</dfn></dt>
<dd>An event whose default action was prevented by means of <code>preventDefault()</code>, returning <code>false</code> in an event handler, or other means as defined by [[!UIEVENTS]] and [[!HTML5]].</dd>
<dd>An event whose default action was prevented by means of <code>preventDefault()</code>, returning <code>false</code> in an event handler, or other means as defined by [[UIEVENTS]] and [[HTML5]].</dd>
<dt><dfn>contact geometry</dfn></dt>
<dd>The bounding box of an input (most commonly, touch) on a digitizer. This typically refers to devices with coarser pointer input resolution than a single pixel. Some devices do not report this data at all.</dd>
<dt><dfn>digitizer</dfn></dt>
@@ -243,7 +243,7 @@ <h1>Glossary</h1>
<dt><dfn>user agent</dfn></dt>
<dd>A program, such as a browser or content authoring tool, normally running on a client machine, which acts on a user's behalf in retrieving, interpreting, executing, presenting, or creating content.</dd>
<dt><dfn>queue a task</dfn></dt>
<dd>Adding the task to events task queue of the relevant event loop, as defined in [[!HTML5]].</dd>
<dd>Adding the task to events task queue of the relevant event loop, as defined in [[HTML5]].</dd>
</dl>
</section>

@@ -767,7 +767,7 @@ <h2>Details of <code>touch-action</code> values</h2>
<dt>manipulation</dt>
<dd>The user agent MAY consider touches that begin on the element only for the purposes of scrolling and continuous zooming. Any additional behaviors supported by <code>auto</code> are out of scope for this specification.</dd>
</dl>
<div class="note">Additional <code>touch-action</code> values common in implementations <a href="https://compat.spec.whatwg.org/#touch-action">are defined</a> in [[!COMPAT]].</div>
<div class="note">Additional <code>touch-action</code> values common in implementations <a href="https://compat.spec.whatwg.org/#touch-action">are defined</a> in [[COMPAT]].</div>
<div class="note">The terms &quot;pan&quot; and &quot;scroll&quot; are considered synonymous. Defining an interaction or gesture for triggering panning or scrolling, or for triggering behavior for the <code>auto</code> or <code>none</code> values are out of scope for this specification.</div>
<div class="note">The <code>touch-action</code> property only applies to elements that support both the CSS <code>width</code> and <code>height</code> properties (see [[CSS21]]). This restriction is designed to facilitate user agent optimizations for <span>low-latency</span> touch actions. For elements not supported by default, such as <code>&lt;span&gt;</code> which is a <span>non-replaced inline element</span> (see [[HTML5]]), authors can set the <code>display</code> CSS property to a value, such as <code>block</code>, that supports <code>width</code> and <code>height</code>. Future specifications could extend this API to all elements.</div>
<div class="note">Disabling some default touch behaviors may allow user agents to respond to other behaviors more quickly. For example, with <code>auto</code> user agents typically add 300ms of delay before <code>click</code> to allow for double-tap gestures to be handled. In these cases, explicitly setting <code>touch-action: none</code> or <code>touch-action: manipulation</code> will remove this delay. Note that the methods for determining a tap or double-tap gesture are out of scope for this specification.</div>

0 comments on commit d2779fe

Please sign in to comment.
You can’t perform that action at this time.