Editorial: remove remaining UTF-8 and UTF-16 references

Infra already explains the relevant details and ByteString is not at all suitable for UTF-8 data.

Also hyphenate "x bit" throughout.

Author: annevk

index.bs

@@ -5738,15 +5738,15 @@ tokens.
 <h4 oldids="dom-float" id="idl-float" interface>float</h4>
 
 The {{float}} type is a floating point numeric
-type that corresponds to the set of finite single-precision 32 bit
+type that corresponds to the set of finite single-precision 32-bit
 IEEE 754 floating point numbers. [[!IEEE-754]]
 
 {{float}} constant values in IDL are
 represented with <emu-t class="regex"><a href="#prod-decimal">decimal</a></emu-t>
 tokens.
 
 <p class="warning">
-    Unless there are specific reasons to use a 32 bit floating point type,
+    Unless there are specific reasons to use a 32-bit floating point type,
     specifications should use
     {{double}} rather than {{float}},
     since the set of values that a {{double}} can
@@ -5756,7 +5756,7 @@ tokens.
 <h4 oldids="dom-unrestrictedfloat" id="idl-unrestricted-float" interface>unrestricted float</h4>
 
 The {{unrestricted float}} type is a floating point numeric
-type that corresponds to the set of all possible single-precision 32 bit
+type that corresponds to the set of all possible single-precision 32-bit
 IEEE 754 floating point numbers, finite, non-finite, and special "not a number" values (NaNs). [[!IEEE-754]]
 
 {{unrestricted float}} constant values in IDL are
@@ -5766,7 +5766,7 @@ tokens.
 <h4 oldids="dom-double" id="idl-double" interface>double</h4>
 
 The {{double}} type is a floating point numeric
-type that corresponds to the set of finite double-precision 64 bit
+type that corresponds to the set of finite double-precision 64-bit
 IEEE 754 floating point numbers. [[!IEEE-754]]
 
 {{double}} constant values in IDL are
@@ -5776,7 +5776,7 @@ tokens.
 <h4 oldids="dom-unrestricteddouble" id="idl-unrestricted-double" interface>unrestricted double</h4>
 
 The {{unrestricted double}} type is a floating point numeric
-type that corresponds to the set of all possible double-precision 64 bit
+type that corresponds to the set of all possible double-precision 64-bit
 IEEE 754 floating point numbers, finite, non-finite, and special "not a number" values (NaNs). [[!IEEE-754]]
 
 {{unrestricted double}} constant values in IDL are
@@ -5794,18 +5794,12 @@ The {{bigint}} type is an arbitrary integer type, unrestricted in range.
 
 The {{DOMString}} type corresponds to [=strings=].
 
-Note: Note also that <emu-val>null</emu-val>
-is not a value of type {{DOMString}}.
-To allow <emu-val>null</emu-val>, a
-[=nullable type|nullable=] {{DOMString}},
-written as <code>DOMString?</code> in IDL, needs to be used.
+Note: <emu-val>null</emu-val> is not a value of type {{DOMString}}. To allow
+<emu-val>null</emu-val>, a [=nullable type|nullable=] {{DOMString}}, written as
+<code>DOMString?</code> in IDL, needs to be used.
 
-Nothing in this specification requires a {{DOMString}}
-value to be a valid UTF-16 string.  For example, a {{DOMString}}
-value might include unmatched [=surrogate=] [=code points=].  However, authors
-of specifications using Web IDL might want to obtain a sequence of
-[=scalar values=] given a particular sequence of
-[=code units=].
+Note: A {{DOMString}} value might include unmatched [=surrogate=] [=code points=]. Use {{USVString}}
+if this is not desirable.
 
 There is no way to represent a constant {{DOMString}}
 value in IDL, although {{DOMString}} [=dictionary member=] [=dictionary member/default values=]
@@ -5815,10 +5809,7 @@ can be set to [=value of string literal tokens|the value=] of a
 
 <h4 oldids="dom-ByteString" id="idl-ByteString" interface>ByteString</h4>
 
-The {{ByteString}} type
-corresponds to [=byte sequences=].
-Such sequences might be interpreted as UTF-8 encoded strings [[!RFC3629]]
-or strings in some other 8-bit-per-code-unit encoding, although this is not required.
+The {{ByteString}} type corresponds to [=byte sequences=].
 
 There is no way to represent a constant {{ByteString}}
 value in IDL, although {{ByteString}} [=dictionary member=] [=dictionary member/default values=]
@@ -5833,10 +5824,10 @@ can be set to [=value of string literal tokens|the value=] of a
     strings should be represented with
     {{DOMString}} values, even if it is expected
     that values of the string will always be in ASCII or some
-    8 bit character encoding. [=sequence types|Sequences=] or
+    8-bit character encoding. [=sequence types|Sequences=] or
     [=frozen array type|frozen arrays=] with {{octet}} or {{byte}}
     elements, {{Uint8Array}}, or {{Int8Array}} should be used for holding
-    8 bit data rather than {{ByteString}}.
+    8-bit data rather than {{ByteString}}.
 </p>
 
 
@@ -6354,7 +6345,7 @@ data.  The table below lists these types and the kind of buffer or view they rep
             <dfn id="idl-BigUint64Array" interface>BigUint64Array</dfn></td>
         <td>A view on to an {{ArrayBuffer}} that exposes it as an array of unsigned integers of the given size in bits</td></tr>
     <tr><td><dfn id="idl-Uint8ClampedArray" interface>Uint8ClampedArray</dfn></td>
-        <td>A view on to an {{ArrayBuffer}} that exposes it as an array of unsigned 8 bit integers with clamped conversions</td></tr>
+        <td>A view on to an {{ArrayBuffer}} that exposes it as an array of unsigned 8-bit integers with clamped conversions</td></tr>
     <tr><td><dfn id="idl-Float32Array" interface>Float32Array</dfn>,<br/>
             <dfn id="idl-Float64Array" interface>Float64Array</dfn></td>
         <td>A view on to an {{ArrayBuffer}} that exposes it as an array of IEEE 754 floating point numbers of the given size in bits</td></tr>
@@ -7302,7 +7293,7 @@ In effect, where <var ignore>x</var> is a Number value,
 Note: Since there is only a single ECMAScript <emu-val>NaN</emu-val> value,
 it must be canonicalized to a particular single precision IEEE 754 NaN value.  The NaN value
 mentioned above is chosen simply because it is the quiet NaN with the lowest
-value when its bit pattern is interpreted as an unsigned 32 bit integer.
+value when its bit pattern is interpreted as an unsigned 32-bit integer.
 
 <div id="unrestricted-float-to-es" algorithm="convert an unrestricted float to an ECMAScript value">
 
@@ -7358,7 +7349,7 @@ value when its bit pattern is interpreted as an unsigned 32 bit integer.
 Note: Since there is only a single ECMAScript <emu-val>NaN</emu-val> value,
 it must be canonicalized to a particular double precision IEEE 754 NaN value.  The NaN value
 mentioned above is chosen simply because it is the quiet NaN with the lowest
-value when its bit pattern is interpreted as an unsigned 64 bit integer.
+value when its bit pattern is interpreted as an unsigned 64-bit integer.
 
 <div id="unrestricted-double-to-es" algorithm="convert an unrestricted double to an ECMAScript value">