diff --git a/tests/github/immersive-web/depth-sensing/index.html b/tests/github/immersive-web/depth-sensing/index.html index 2f2a6be2bd..699608d8d4 100644 --- a/tests/github/immersive-web/depth-sensing/index.html +++ b/tests/github/immersive-web/depth-sensing/index.html @@ -1137,6 +1137,7 @@

.log("Depth at normalized view coordinates (0.25, 0.75) is:", depthInMeters); } +

3.3. XRWebGLDepthInformation

@@ -1255,6 +1256,7 @@

// ... } +

The fragment shader that makes use of the depth buffer can be for example:

precision mediump float;
@@ -1279,6 +1281,7 @@ 
= ...;
 }
+

4. Interpreting the results

diff --git a/tests/github/jfbastien/papers/source/P0528r1.html b/tests/github/jfbastien/papers/source/P0528r1.html index 9f65fe0456..8aa7f7fded 100644 --- a/tests/github/jfbastien/papers/source/P0528r1.html +++ b/tests/github/jfbastien/papers/source/P0528r1.html @@ -2165,7 +2165,8 @@

2. expected value.

As a consequence, the following code is guaranteed to avoid spurious failure:

-
struct padded {
+
+struct padded {
   char c = 0x42;
   // Padding here.
   unsigned i = 0xC0DEFEFE;
@@ -2176,6 +2177,7 @@ 
2. padded expected, desired { 0, 0 };
   return pad.compare_exchange_strong(expected, desired);
 }
+
 

      
[Note:

      
Types which contain bits that sometimes participate in the object’s
@@ -2217,16 +2219,19 @@ 
2. memcpy(this, &desired, sizeof(*this));
 else
    memcpy(expected, this, sizeof(*this));
+

—end note]

[Example:

The expected use of the compare-and-exchange operations is as follows. The compare-and-exchange operations will update expected when another iteration of the loop is needed.

-
expected = current.load();
+
+expected = current.load();
 do {
   desired = function(expected);
 } while (!current.compare_exchange_weak(expected, desired));
+
 

     
—end example]

     
[Example:

@@ -2234,9 +2239,11 @@ 
2. expected value on success will work. E.g. list head
   insertion will act atomically and would not introduce a data race in the
   following code:

-
do {
+
+do {
   p->next = head; // make new list node point to the current head
 } while (!head.compare_exchange_weak(p->next, p)); // try to insert
+
 

     
—end example]

     
Implementations should ensure that weak compare-and-exchange operations do not
diff --git a/tests/github/jfbastien/papers/source/P0528r2.html b/tests/github/jfbastien/papers/source/P0528r2.html
index b0ba8e4d66..76ea09dce3 100644
--- a/tests/github/jfbastien/papers/source/P0528r2.html
+++ b/tests/github/jfbastien/papers/source/P0528r2.html
@@ -2200,16 +2200,19 @@ 
2. memcpy(this, &desired, sizeof(*this));
 else
    memcpy(expected, this, sizeof(*this));
+
 

     
—end note]

     
[Example:

     
The expected use of the compare-and-exchange operations is as follows. The
   compare-and-exchange operations will update expected when another iteration
   of the loop is needed.

-
expected = current.load();
+
+expected = current.load();
 do {
   desired = function(expected);
 } while (!current.compare_exchange_weak(expected, desired));
+
 

     
—end example]

     
[Example:

@@ -2217,9 +2220,11 @@ 
2. expected value on success will work. E.g. list head
   insertion will act atomically and would not introduce a data race in the
   following code:

-
do {
+
+do {
   p->next = head; // make new list node point to the current head
 } while (!head.compare_exchange_weak(p->next, p)); // try to insert
+
 

     
—end example]

     
Implementations should ensure that weak compare-and-exchange operations do not
@@ -2258,7 +2263,8 @@ 
2. Compare-and-exchange acts on an object’s value representation, ensuring that
   padding bits which never participate in the object’s representation are ignored.

      
As a consequence, the following code is guaranteed to avoid spurious failure:

-
struct padded {
+
+struct padded {
   char clank = 0x42;
   // Padding here.
   unsigned biff = 0xC0DEFEFE;
@@ -2269,6 +2275,7 @@ 
2. padded expected, desired { 0, 0 };
   return pad.compare_exchange_strong(expected, desired);
 }
+
 

      
—end note]

      
[Note:

diff --git a/tests/github/jfbastien/papers/source/P0907r0.html b/tests/github/jfbastien/papers/source/P0907r0.html
index 8382ac6291..9026b2d0da 100644
--- a/tests/github/jfbastien/papers/source/P0907r0.html
+++ b/tests/github/jfbastien/papers/source/P0907r0.html
@@ -2222,18 +2222,21 @@ 
2. int is [-32768, +32767], the implementation cannot rewrite this expression as
     

     
-
  a = ((a + b) + 32765);
+
+  a = ((a + b) + 32765);
 

     
     since if the values for a and b were, respectively, -32754 and -15, the sum a + b would produce an exception while the original expression would not; nor
 can the expression be rewritten either as
     
-
  a = ((a + 32765) + b);
+
+  a = ((a + 32765) + b);
 

     
     or
     
-
  a = (a + (b + 32765));
+
+  a = (a + (b + 32765));
 

     
     since the values for a and b might have been, respectively, 4 and -8 or -17
diff --git a/tests/github/jfbastien/papers/source/P0908r0.html b/tests/github/jfbastien/papers/source/P0908r0.html
index 19a3955771..2487ae2dcf 100644
--- a/tests/github/jfbastien/papers/source/P0908r0.html
+++ b/tests/github/jfbastien/papers/source/P0908r0.html
@@ -2122,7 +2122,8 @@ 
Table of Contents

 classes (and, conditionally, other classes) in C++, calculates the layout
 offset of a member within a class. offsetof is useful for calculating an
 object pointer given a pointer to one of its members:

-
struct link {
+
+struct link {
   ...
 };
 
@@ -2136,23 +2137,27 @@ 
Table of Contents

   size_t l_offset = offsetof(container, l);
   return reinterpret_cast<container*>(x_address - l_offset);
 }
+
 

    
This pattern is used in several implementations of intrusive containers, such
 as Linux kernel linked lists (struct list_head).

    
Unfortunately, although offsetof works for some unusual
 member-designators, it does not work for pointers to members. This won’t
 compile:

-
template <typename Container, typename Link, Link (Container::* member)>
+
+template <typename Container, typename Link, Link (Container::* member)>
 Container* generic_container_from_link(Link* x) {
   uintptr_t x_address = reinterpret_cast<uintptr_t>(x);
   size_t link_offset = offsetof(Container, member); // error!
   return reinterpret_cast<Container*>(x_address - link_offset);
 }
+
 

    
Programmers currently compute pointer-to-member offsets using nullptr casts
 (i.e., the incorrect folk implementation of offsetof, which invokes
 undefined behavior), or by jumping through other hoops:

-
template <typename Container, typename Link, Link (Container::* member)>
+
+template <typename Container, typename Link, Link (Container::* member)>
 Container* generic_container_from_link(Link* x) {
   ...
   alignas(Container) char container_space[sizeof(Container)] = {};
@@ -2161,23 +2166,28 @@ 
Table of Contents

       - reinterpret_cast<uintptr_t>(fake_container);
   ...
 }
+
 

    
offsetof with pointer-to-member member-designators should simply work.
 Modern compilers implement offsetof using an extension (__builtin_offsetof in GCC and LLVM), so implementation need not require library changes. To avoid
 ambiguity, we propose this syntax:

-
size_t link_offset = offsetof(Container, .*member);
+
+size_t link_offset = offsetof(Container, .*member);
+
 

    
1. Questions

    
Must a pointer-to-member expression in an offsetof member-designator be a
 constant expression (such as a template argument)? The C standard requires
 that “the expression &(t.member-designator) evaluates to an address
 constant,” which might make this code illegal:

-
struct container {
+
+struct container {
   char array[200];
 };
 
 int index = /* dynamic value */;
 size_t offset = offsetof(container, array[index]);  // questionable
+
 

    
But since several current compilers accept dynamic array indexes, the proposed
 wording allows any pointer to member.

diff --git a/tests/github/jfbastien/papers/source/P1152R1.html b/tests/github/jfbastien/papers/source/P1152R1.html
index fa318408ca..8741b11a9f 100644
--- a/tests/github/jfbastien/papers/source/P1152R1.html
+++ b/tests/github/jfbastien/papers/source/P1152R1.html
@@ -2718,12 +2718,12 @@ 
3.1
 

     
[...]

     
Tuple helper classes [tuple.helper]

-
template<class T> class tuple_size<const T>;
-
-emplate<class T> class tuple_size<volatile T>;
-
-emplate<class T> class tuple_size<const volatile T>;
-

+

+template<class T> class tuple_size<const T>;
+template<class T> class tuple_size<volatile T>;
+template<class T> class tuple_size<const volatile T>;
+
+

     
Let TS denote tuple_size<T> of the cv-unqualified type T. If the
   expression TS::value is well-formed when treated as an unevaluated operand,
   then each of the three templates shall satisfy the TransformationTrait requirements with a base characteristic of

@@ -2747,6 +2747,7 @@ 
3.1
 template<size_t I, class T> class tuple_element<I, const T>;
 template<size_t I, class T> class tuple_element<I, volatile T>;
 template<size_t I, class T> class tuple_element<I, const volatile T>;
+
 

     

      Let TE denote tuple_element_t<I, T> of the cv-unqualified type T.
@@ -2811,6 +2812,7 @@ 
3
 
template<class T> class variant_size<const T>;
 template<class T> class variant_size<volatile T>;
 template<class T> class variant_size<const volatile T>;
+
 

     

      Let VS denote variant_size<T> of the cv-unqualified type T. Then 
diff --git a/tests/github/jfbastien/papers/source/P1152R2.html b/tests/github/jfbastien/papers/source/P1152R2.html
index 944e1d946a..44ef691f1f 100644
--- a/tests/github/jfbastien/papers/source/P1152R2.html
+++ b/tests/github/jfbastien/papers/source/P1152R2.html
@@ -2817,10 +2817,12 @@ 
3.1
 

     
[...]

     
Tuple helper classes [tuple.helper]

-
 template<class T> class tuple_size<const T>;
- template<class T> class tuple_size<volatile T>;
- template<class T> class tuple_size<const volatile T>;
-

+

+ template<class T> class tuple_size<const T>;
+ template<class T> class tuple_size<volatile T>;
+ template<class T> class tuple_size<const volatile T>;
+
+

     
Let TS denote tuple_size<T> of the cv-unqualified type T. If the
   expression TS::value is well-formed when treated as an unevaluated operand,
   then each of the three templates shall satisfy the TransformationTrait requirements with a base characteristic of

@@ -2844,6 +2846,7 @@ 
3.1
 template<size_t I, class T> class tuple_element<I, const T>;
 template<size_t I, class T> class tuple_element<I, volatile T>;
 template<size_t I, class T> class tuple_element<I, const volatile T>;
+
 

     

      Let TE denote tuple_element_t<I, T> of the cv-unqualified type T.
@@ -2908,6 +2911,7 @@ 
3
 
template<class T> class variant_size<const T>;
 template<class T> class variant_size<volatile T>;
 template<class T> class variant_size<const volatile T>;
+
 

     

      Let VS denote variant_size<T> of the cv-unqualified type T. Then 
diff --git a/tests/github/jfbastien/papers/source/P1152R3.html b/tests/github/jfbastien/papers/source/P1152R3.html
index d5991e425b..5960bc5faa 100644
--- a/tests/github/jfbastien/papers/source/P1152R3.html
+++ b/tests/github/jfbastien/papers/source/P1152R3.html
@@ -2828,10 +2828,12 @@ 
3.1
 

     
[...]

     
Tuple helper classes [tuple.helper]

-
 template<class T> class tuple_size<const T>;
- template<class T> class tuple_size<volatile T>;
- template<class T> class tuple_size<const volatile T>;
-

+

+ template<class T> class tuple_size<const T>;
+ template<class T> class tuple_size<volatile T>;
+ template<class T> class tuple_size<const volatile T>;
+
+

     
Let TS denote tuple_size<T> of the cv-unqualified type T. If the
   expression TS::value is well-formed when treated as an unevaluated operand,
   then each of the three templates shall satisfy the TransformationTrait requirements with a base characteristic of

@@ -2855,6 +2857,7 @@ 
3.1
 template<size_t I, class T> class tuple_element<I, const T>;
 template<size_t I, class T> class tuple_element<I, volatile T>;
 template<size_t I, class T> class tuple_element<I, const volatile T>;
+
 

     

      Let TE denote tuple_element_t<I, T> of the cv-unqualified type T.
@@ -2919,6 +2922,7 @@ 
3
 
template<class T> class variant_size<const T>;
 template<class T> class variant_size<volatile T>;
 template<class T> class variant_size<const volatile T>;
+
 

     

      Let VS denote variant_size<T> of the cv-unqualified type T. Then 
diff --git a/tests/github/jfbastien/papers/source/P1831R0.html b/tests/github/jfbastien/papers/source/P1831R0.html
index fd4ac01e7a..07f46d971e 100644
--- a/tests/github/jfbastien/papers/source/P1831R0.html
+++ b/tests/github/jfbastien/papers/source/P1831R0.html
@@ -2173,10 +2173,12 @@ 
2.1.
 

     
[...]

     
Tuple helper classes [tuple.helper]

-
 template<class T> class tuple_size<const T>;
- template<class T> class tuple_size<volatile T>;
- template<class T> class tuple_size<const volatile T>;
-

+

+ template<class T> class tuple_size<const T>;
+ template<class T> class tuple_size<volatile T>;
+ template<class T> class tuple_size<const volatile T>;
+
+

     

      Let TS denote tuple_size<T> of the cv-unqualified type T. If the
   expression TS::value is well-formed when treated as an unevaluated operand,
@@ -2205,6 +2207,7 @@ 
2.1.
 template<size_t I, class T> class tuple_element<I, const T>;
 template<size_t I, class T> class tuple_element<I, volatile T>;
 template<size_t I, class T> class tuple_element<I, const volatile T>;
+
 

     

      Let TE denote tuple_element_t<I, T> of the cv-unqualified type T.
@@ -2272,6 +2275,7 @@ 
2.
 
template<class T> class variant_size<const T>;
 template<class T> class variant_size<volatile T>;
 template<class T> class variant_size<const volatile T>;
+
 

     

      Let VS denote variant_size<T> of the cv-unqualified type T. Then 
@@ -2469,8 +2473,10 @@ 
template<class T> class tuple_size<volatile T>;
+

+template<class T> class tuple_size<volatile T>;
 template<class T> class tuple_size<const volatile T>;
+
 

    
Let TS denote tuple_size<T> of the cv-unqualified type T. If the
   expression TS::value is well-formed when treated as an unevaluated operand,
@@ -2484,6 +2490,7 @@ 
  
 template<size_t I, class T> class tuple_element<I, volatile T>;
 template<size_t I, class T> class tuple_element<I, const volatile T>;
+
 

    
Let TE denote tuple_element_t<I, T> of the cv-unqualified type T. Then
   each of the two templates shall satisfy the TransformationTrait requirements
@@ -2512,6 +2519,7 @@ 
variant helper classes [depr.variant.helper]

 
template<class T> class variant_size<volatile T>;
 template<class T> class variant_size<const volatile T>;
+
 

    
Let VS denote variant_size<T> of the cv-unqualified type T. Then each
   of the two templates shall satisfy the UnaryTypeTrait requirements with a
diff --git a/tests/github/jfbastien/papers/source/P1831R1.html b/tests/github/jfbastien/papers/source/P1831R1.html
index e0e2462860..111765aa08 100644
--- a/tests/github/jfbastien/papers/source/P1831R1.html
+++ b/tests/github/jfbastien/papers/source/P1831R1.html
@@ -2192,10 +2192,12 @@ 
3.1.
 

     
[...]

     
Tuple helper classes [tuple.helper]

-
 template<class T> class tuple_size<const T>;
- template<class T> class tuple_size<volatile T>;
- template<class T> class tuple_size<const volatile T>;
-

+

+ template<class T> class tuple_size<const T>;
+ template<class T> class tuple_size<volatile T>;
+ template<class T> class tuple_size<const volatile T>;
+
+

     

      Let TS denote tuple_size<T> of the cv-unqualified type T. If the
   expression TS::value is well-formed when treated as an unevaluated operand,
@@ -2229,6 +2231,7 @@ 
3.1.
 template<size_t I, class T> class tuple_element<I, const T>;
 template<size_t I, class T> class tuple_element<I, volatile T>;
 template<size_t I, class T> class tuple_element<I, const volatile T>;
+
 

     

      Let TE denote tuple_element_t<I, T> of the cv-unqualified type T.
@@ -2296,6 +2299,7 @@ 
3.
 
template<class T> class variant_size<const T>;
 template<class T> class variant_size<volatile T>;
 template<class T> class variant_size<const volatile T>;
+
 

     

      Let VS denote variant_size<T> of the cv-unqualified type T. Then 
@@ -2493,8 +2497,10 @@ 
template<class T> class tuple_size<volatile T>;
+

+template<class T> class tuple_size<volatile T>;
 template<class T> class tuple_size<const volatile T>;
+
 

    
Let TS denote tuple_size<T> of the cv-unqualified type T. If the
   expression TS::value is well-formed when treated as an unevaluated operand,
@@ -2508,6 +2514,7 @@ 
  
 template<size_t I, class T> class tuple_element<I, volatile T>;
 template<size_t I, class T> class tuple_element<I, const volatile T>;
+

Let TE denote tuple_element_t<I, T> of the cv-unqualified type T. Then each of the two templates shall satisfy the TransformationTrait requirements @@ -2536,6 +2543,7 @@

variant helper classes [depr.variant.helper]

template<class T> class variant_size<volatile T>;
 template<class T> class variant_size<const volatile T>;
+

Let VS denote variant_size<T> of the cv-unqualified type T. Then each of the two templates shall satisfy the UnaryTypeTrait requirements with a diff --git a/tests/github/jfbastien/papers/source/p0528r3.html b/tests/github/jfbastien/papers/source/p0528r3.html index 389406cbc0..8176225b7e 100644 --- a/tests/github/jfbastien/papers/source/p0528r3.html +++ b/tests/github/jfbastien/papers/source/p0528r3.html @@ -2179,6 +2179,7 @@

2. memory_order order = memory_order::seq_cst) volatile noexcept; bool compare_exchange_strong(T& expected, T desired, memory_order order = memory_order::seq_cst) noexcept; +

❡17:

@@ -2232,16 +2233,19 @@

2. memcpy(this, &desired, sizeof(*this)); else memcpy(expected, this, sizeof(*this)); +

—end note]

[Example:

The expected use of the compare-and-exchange operations is as follows. The compare-and-exchange operations will update expected when another iteration of the loop is needed.

-
expected = current.load();
+
+expected = current.load();
 do {
   desired = function(expected);
 } while (!current.compare_exchange_weak(expected, desired));
+
 

     
—end example]

     
[Example:

@@ -2249,9 +2253,11 @@ 
2. expected value on success will work. E.g. list head
   insertion will act atomically and would not introduce a data race in the
   following code:

-
do {
+
+do {
   p->next = head; // make new list node point to the current head
 } while (!head.compare_exchange_weak(p->next, p)); // try to insert
+
 

     
—end example]

    
@@ -2303,7 +2309,8 @@ 
2. Because compare-and-exchange acts on an object’s value representation, padding
   bits that never participate in the object’s value representation are ignored.

      
As a consequence, the following code is guaranteed to avoid spurious failure:

-
struct padded {
+
+struct padded {
   char clank = 0x42;
   // Padding here.
   unsigned biff = 0xC0DEFEFE;
@@ -2314,6 +2321,7 @@ 
2. padded expected, desired { 0, 0 };
   return pad.compare_exchange_strong(expected, desired);
 }
+
 

      
—end note]

      
[Note:

@@ -2322,7 +2330,8 @@ 
2. 
      
As a consequence, the following code is not guaranteed to ever succeed:

-
union pony {
+
+union pony {
   double celestia = 0.;
   short luna; // padded
 };
@@ -2332,6 +2341,7 @@ 
2. pony expected;
   return princesses.compare_exchange_strong(expected, desired);
 }
+
 

      
—end note]

     
diff --git a/tests/github/jfbastien/papers/source/p1119r0.html b/tests/github/jfbastien/papers/source/p1119r0.html
index d6edb6f4e8..d22647cfb6 100644
--- a/tests/github/jfbastien/papers/source/p1119r0.html
+++ b/tests/github/jfbastien/papers/source/p1119r0.html
@@ -2135,13 +2135,15 @@ 
1. [P0154R1] introduced constexpr std::hardware_{constructive,destructive}_interference_size to C++17:

    
Header <new> synopsis [new.syn]:

    

-
namespace std {
+
+namespace std {
   // ...
   // 21.6.5, hardware interference size
   inline constexpr size_t hardware_destructive_interference_size = implementation-defined;
   inline constexpr size_t hardware_constructive_interference_size = implementation-defined;
   // ...
 }
+
 

    

    
Hardware interference size [hardware.interference]:

diff --git a/tests/github/w3c/css-houdini-drafts/css-animation-worklet-1/Overview.html b/tests/github/w3c/css-houdini-drafts/css-animation-worklet-1/Overview.html
index ca4e2009eb..977a701ce7 100644
--- a/tests/github/w3c/css-houdini-drafts/css-animation-worklet-1/Overview.html
+++ b/tests/github/w3c/css-houdini-drafts/css-animation-worklet-1/Overview.html
@@ -1644,7 +1644,8 @@ 
9. Examples

    
9.1. Example 1: Spring timing.

     Here we use Animation Worklet to create animation with a custom spring timing. 
-
<div id='target'></div>
+
+<div id='target'></div>
 
 <script>
 await CSS.animationWorklet.addModule('spring-animator.js');
@@ -1658,6 +1659,7 @@ 

 const animation = new WorkletAnimation('spring', effect, document.timeline, {k: 2, ratio: 0.7});
 animation.play();
 </script>
+
 

 
registerAnimator('spring', class SpringAnimator {
   constructor(options = {k: 1, ratio: 0.5}) {
@@ -1740,6 +1742,7 @@ 

 
 animation.play();
 </script>
+
 

 
// Inside AnimationWorkletGlobalScope.
 registerAnimator('twitter-header', class HeaderAnimator {
@@ -1785,6 +1788,7 @@ 

  return /* compute an return a physical movement curve based on scroll position, and per frame
            velocity and acceleration. */ ;
 }
+
 

    
9.3. Example 3: Parallax backgrounds.

     A simple parallax background example. 
@@ -1835,6 +1839,7 @@ 

 );
 fastParallax.play();
 </script>
+
 

 
// Inside AnimationWorkletGlobalScope.
 registerAnimator('parallax', class ParallaxAnimator {
diff --git a/tests/github/w3c/csswg-drafts/css-color-hdr/Overview.html b/tests/github/w3c/csswg-drafts/css-color-hdr/Overview.html
index 640e666b9d..9a50b6a06d 100644
--- a/tests/github/w3c/csswg-drafts/css-color-hdr/Overview.html
+++ b/tests/github/w3c/csswg-drafts/css-color-hdr/Overview.html
@@ -923,6 +923,7 @@ 
const c2 = 2413 / (2 ** 7);
 const c3 = 2392 / (2 ** 7);
 xPQ = (((c1 + (c2 * (x ** n))) / (1 + (c3 * (x ** n)))) ** m);
+
 

    
xPQ is the "gamma-corrected" (OETF-adjusted) signal [0, 1].

    
PQ encoded values are converted to linear-light as follows:

diff --git a/tests/github/w3c/csswg-drafts/css-contain-1/Overview.html b/tests/github/w3c/csswg-drafts/css-contain-1/Overview.html
index cb0b3e217c..e370c15f18 100644
--- a/tests/github/w3c/csswg-drafts/css-contain-1/Overview.html
+++ b/tests/github/w3c/csswg-drafts/css-contain-1/Overview.html
@@ -1628,7 +1628,8 @@ 
<img src="https://www.example.com/300x100.jpg">
+
+<img src="https://www.example.com/300x100.jpg">
 

     
If the aspect-ratio property had not been declared,
 		the image would have been 100px by 0px,
diff --git a/tests/github/w3c/csswg-drafts/css-contain-2/Overview.html b/tests/github/w3c/csswg-drafts/css-contain-2/Overview.html
index 4b04802455..e6bf5d78eb 100644
--- a/tests/github/w3c/csswg-drafts/css-contain-2/Overview.html
+++ b/tests/github/w3c/csswg-drafts/css-contain-2/Overview.html
@@ -1740,7 +1740,8 @@ 
<img src="https://www.example.com/300x100.jpg">
+
+<img src="https://www.example.com/300x100.jpg">
 

     
If the aspect-ratio property had not been declared,
 		the image would have been 100px by 0px,
diff --git a/tests/github/w3c/csswg-drafts/css-egg-1/Overview.html b/tests/github/w3c/csswg-drafts/css-egg-1/Overview.html
index 0e37b786ea..21f494fef7 100644
--- a/tests/github/w3c/csswg-drafts/css-egg-1/Overview.html
+++ b/tests/github/w3c/csswg-drafts/css-egg-1/Overview.html
@@ -1166,8 +1166,8 @@ 
</style>
-
+
+</style>
 

     
The following is a disappointingly small sample rendering (not at scale)
 	of what this would look like.
diff --git a/tests/github/w3c/csswg-drafts/css2/Overview.html b/tests/github/w3c/csswg-drafts/css2/Overview.html
index fa97b0d7bd..b151e19a34 100644
--- a/tests/github/w3c/csswg-drafts/css2/Overview.html
+++ b/tests/github/w3c/csswg-drafts/css2/Overview.html
@@ -13185,7 +13185,9 @@ 

    
16.6.2. Example of bidirectionality with white space collapsing

    
 Given the following markup fragment, taking special note of spaces (with varied backgrounds and borders for emphasis and identification): 

-
<ltr>A  rtl>>   /rtl>>C</ltr>
+

+<ltr>A <rtl> B </rtl> C</ltr>
+
 

    
 ...where the <ltr> element represents a left-to-right embedding and
 the <rtl> element represents a right-to-left embedding, and
diff --git a/tests/github/w3c/proximity/index.html b/tests/github/w3c/proximity/index.html
index c79d5174ab..ee30bf5866 100644
--- a/tests/github/w3c/proximity/index.html
+++ b/tests/github/w3c/proximity/index.html
@@ -839,6 +839,7 @@ 
2.
 sensor.onreading = () => console.log(sensor.distance);
 
 sensor.onerror = event => console.log(event.error.name, event.error.message);
+
 

    
    
3. Security and Privacy Considerations

diff --git a/tests/github/w3c/webappsec-trusted-types/spec/index.html b/tests/github/w3c/webappsec-trusted-types/spec/index.html
index d191fdf4aa..f4862306e4 100644
--- a/tests/github/w3c/webappsec-trusted-types/spec/index.html
+++ b/tests/github/w3c/webappsec-trusted-types/spec/index.html
@@ -1369,7 +1369,8 @@ 

      Library initialized with a policy allowing it to load additional scripts from
 a given host. 
-
const cdnScriptsPolicy = trustedTypes.createPolicy('cdn-scripts', {
+
+const cdnScriptsPolicy = trustedTypes.createPolicy('cdn-scripts', {
   createScriptURL(url) {
     const parsed = new URL(url, document.baseURI);
     if (parsed.origin == 'https://mycdn.example') {