Tweaks for publishing.
--- a/midi/specification.html Fri Oct 19 14:54:26 2012 +0300
+++ b/midi/specification.html Fri Oct 19 10:54:25 2012 -0700
@@ -127,7 +127,7 @@
event handler event types</a></dfn> are defined in [[!HTML5]].
</p>
<p>
- The term <dfn><a href="http://www.khronos.org/registry/typedarray/specs/latest/#7">Uint8Array</a></dfn>
+ The term <dfn><a href="http://www.khronos.org/registry/typedarray/specs/latest/#TYPEDARRAYS">Uint8Array</a></dfn>
is defined in [[!TYPED-ARRAYS]].
</p>
<p>
@@ -150,7 +150,7 @@
<li>Additionally, combined access to input and output ports on a given device (the ability to send <b>and</b> receive system exclusive messages, in particular) might allow sophisticated developers to query and test for particular MIDI-connected devices, such as samplers, and either using the presence of those devices for more precise fingerprinting, destroying data (erasing samples or patches on the devices), attempting to capture data from the devices (e.g. downloading samples from samplers, then uploading to the network), or simply initiating malicious action (e.g. sending MIDI commands to a lighting control system to turn lights on and off). </li>
</ol>
<p>
- These issues will be further explored prior to this specification becoming a Recommendation. In the meantime, the <a href="#idl-def-NavigatorMIDIAccess">suggested security model</a> explicitly allows user agents to require the user's approval before giving access to MIDI devices, although it is not currently required to prompt the user for this approval. It is noted that some web systems (e.g. Java) give access to MIDI interfaces without prompting, although this may not be the security model that this specification eventually uses.
+ These issues will be further explored prior to this specification becoming a Recommendation. In the meantime, the <a href="#NavigatorMIDIAccess">suggested security model</a> explicitly allows user agents to require the user's approval before giving access to MIDI devices, although it is not currently required to prompt the user for this approval. It is noted that some web systems (e.g. Java) give access to MIDI interfaces without prompting, although this may not be the security model that this specification eventually uses.
</p>
</section>
@@ -254,14 +254,9 @@
<li><p>
Let <var>error</var> be a new <code>
- <a
- href="#idl-def-NavigatorMIDIAccessError">NavigatorMIDIAccessError</a>
- </code> object whose <code
- title="dom-NavigatorMIDIAccessError-code">
- <a href="#dom-navigatormidiaccesserror-code">code</a>
- </code> attribute has the numeric value 1 (<code
- title="dom-NavigatorMIDIAccessError-PERMISSION_DENIED">
- <a
+ <a href="#NavigatorMIDIAccessError">NavigatorMIDIAccessError</a>
+ </code> object whose <code><a href="#dom-navigatormidiaccesserror-code">code</a>
+ </code> attribute has the numeric value 1 (<code><a
href="#dom-navigatormidiaccesserror-PERMISSION_DENIED">PERMISSION_DENIED</a>
</code>).
</p></li>
@@ -307,12 +302,12 @@
</section>
<section>
- <h2>
+ <h2 id="NavigatorMIDIAccessError">
NavigatorMIDIAccessError and
NavigatorMIDIAccessErrorCallback
</h2>
- <dl class="idl"
+ <dl id="dom-navigatormidiaccesserror-PERMISSION_DENIED" class="idl"
title="[NoInterfaceObject] interface NavigatorMIDIAccessError">
<dt>const unsigned short PERMISSION_DENIED = 1</dt>
@@ -325,9 +320,7 @@
<dd>
Returns the current error's error code. At this time, this will
- always be 1, for which the constant <code
- title="dom-NavigatorMIDIAccessError-PERMISSION_DENIED">
- <a
+ always be 1, for which the constant <code><a
href="#dom-navigatormidiaccesserror-PERMISSION_DENIED">PERMISSION_DENIED</a>
</code> is defined.
</dd>