Editorial: Unify spelling of 'behaviour' (#1856)

Author: rkirsling

spec.html

@@ -18068,7 +18068,7 @@ <h1>EnumerateObjectProperties ( _O_ )</h1>
         </ul>
 
         <emu-note>
-          <p>Hosts are not required to implement the algorithm in <emu-xref href="#sec-%foriniteratorprototype%.next"></emu-xref> directly. They may choose any implementation whose behavior will not deviate from that algorithm unless one of the constraints in the previous paragraph is violated.</p>
+          <p>Hosts are not required to implement the algorithm in <emu-xref href="#sec-%foriniteratorprototype%.next"></emu-xref> directly. They may choose any implementation whose behaviour will not deviate from that algorithm unless one of the constraints in the previous paragraph is violated.</p>
           <p>The following is an informative definition of an ECMAScript generator function that conforms to these rules:</p>
           <pre><code class="javascript">
             function* EnumerateObjectProperties(obj) {
@@ -18090,13 +18090,13 @@ <h1>EnumerateObjectProperties ( _O_ )</h1>
           </code></pre>
         </emu-note>
         <emu-note>
-          The list of exotic objects for which implementations are not required to match CreateForInIterator was chosen because implementations historically differed in behavior for those cases, and agreed in all others.
+          The list of exotic objects for which implementations are not required to match CreateForInIterator was chosen because implementations historically differed in behaviour for those cases, and agreed in all others.
         </emu-note>
       </emu-clause>
 
       <emu-clause id="sec-for-in-iterator-objects">
         <h1>For-In Iterator Objects</h1>
-        <p>A For-In Iterator is an object that represents a specific iteration over some specific object. For-In Iterator objects are never directly accessible to ECMAScript code; they exist soley to illustrate the behavior of EnumerateObjectProperties.</p>
+        <p>A For-In Iterator is an object that represents a specific iteration over some specific object. For-In Iterator objects are never directly accessible to ECMAScript code; they exist solely to illustrate the behaviour of EnumerateObjectProperties.</p>
 
         <emu-clause id="sec-createforiniterator" aoid="CreateForInIterator">
           <h1>CreateForInIterator ( _object_ )</h1>
@@ -28695,7 +28695,7 @@ <h1>Date Time String Format</h1>
 
         <emu-clause id="sec-expanded-years" oldids="sec-extended-years">
           <h1>Expanded Years</h1>
-          <p>Covering the full time value range of approximately 273,790 years forward or backward from 01 January, 1970 (<emu-xref href="#sec-time-values-and-time-range"></emu-xref>) requires representing years before 0 or after 9999. ISO 8601 permits expansion of the year representation, but only by mutual agreement of the partners in information interchange. In the simplified ECMAScript format, such an expanded year representation shall have 6 digits and is always prefixed with a + or - sign. The year 0 is considered positive and hence prefixed with a + sign. Strings matching the <emu-xref href="#sec-date-time-string-format">Date Time String Format</emu-xref> with expanded years representing instants in time outside the range of a time value are treated as unrecognizable by <emu-xref href="#sec-date.parse">`Date.parse`</emu-xref> and cause that function to return *NaN* without falling back to implementation-specific behavior or heuristics.</p>
+          <p>Covering the full time value range of approximately 273,790 years forward or backward from 01 January, 1970 (<emu-xref href="#sec-time-values-and-time-range"></emu-xref>) requires representing years before 0 or after 9999. ISO 8601 permits expansion of the year representation, but only by mutual agreement of the partners in information interchange. In the simplified ECMAScript format, such an expanded year representation shall have 6 digits and is always prefixed with a + or - sign. The year 0 is considered positive and hence prefixed with a + sign. Strings matching the <emu-xref href="#sec-date-time-string-format">Date Time String Format</emu-xref> with expanded years representing instants in time outside the range of a time value are treated as unrecognizable by <emu-xref href="#sec-date.parse">`Date.parse`</emu-xref> and cause that function to return *NaN* without falling back to implementation-specific behaviour or heuristics.</p>
           <emu-note>
             <p>Examples of date-time values with expanded years:</p>
             <figure>