These are in addition to those reported in bug 2655 and bug 2656.
- In 9.4.6.10 "[[Delete]] (P)", the steps are numbered 1, 6, 7, 2.
- In 20.3.2.2 "Date ( value )", the list starts with step 6.
- In the next section, 20.3.2.3 "Date ( )", the list starts with step 11.
- In 24.1.1.4 "GetValueFromBuffer ( arrayBuffer, byteIndex, type, isLittleEndian )", after step 9, the next step is numbered 1.
- In 24.1.4.1 "get ArrayBuffer.prototype.byteLength", the list starts with step 9.
- In 24.2.4.3 "get DataView.prototype.byteOffset", the list starts with step 16.
- In 24.3.2.4 "Runtime Semantics: JA Abstract Operation", the list starts with step 5.
- In 25.4.4.5 "Promise.resolve ( x )", the first two steps are both numbered 1.
And lastly, several instances of a common issue:
- In 26.1.4 "Reflect.get ( target, propertyKey [ , receiver ])", under step 5, the substep is numbered "1." It should be "a."
- Same thing in 26.1.12 "Reflect.set ( target, propertyKey, V [ , receiver ] )".
- And in 26.2.3.4 "get Reflect.Realm.prototype.intrinsics" under step 6.
- And in 26.2.3.5 "get Reflect.Realm.prototype.stdlib" under step 6. (Also, the first substep there has two periods at the end of the sentence; and step 6 contains an extra comma.)
- And in 26.3.3.7 "Reflect.Loader.prototype.has ( name )" under step 7.
- And in 26.3.3.12 "Reflect.Loader.prototype.newModule ( obj )" under step 4, but that section has more substantive problems...
- And in 26.3.3.14 "Reflect.Loader.prototype.set ( name, module )" under step 8.
- And in 26.3.5.2.1 "%LoaderIteratorPrototype%.next ( )" under step 10.
Oops, found another:
- In 13.2.3.3 "Static Semantics: HasInitializer", all four lists only have a single step, but in three of them it's numbered "2."
But I'm pretty sure that's all.
Fixed in rev24 editor's draft
basically almost all the algorithms in clause 26 had the wrong list style.
It show up in Word with them having the wrong left margin.
fixed in rev24
fixed in rev24