Update datestamps and generate chapters

src/templates/en/2019/chapters/mobile-web.html

@@ -143,8 +143,12 @@ <h3 id="pages-bloated-with-javascript"><a href="#pages-bloated-with-javascript"
 <p>The state of JavaScript on the mobile web is terrifying. According to HTTP Archive's <a href="https://httparchive.org/reports/state-of-javascript?start=2016_05_15&amp;end=2019_07_01&amp;view=list#bytesJs">JavaScript report</a>, the median mobile site requires phones to download 375 KB of JavaScript. Assuming a 70% compression ratio, this means that phones have to parse, compile, and execute 1.25 MB of JavaScript at the median.</p>
 <p>Why is this a problem? Because sites loading this much JS take upwards of <a href="https://httparchive.org/reports/loading-speed?start=earliest&amp;end=2019_07_01&amp;view=list#ttci">10 seconds</a> to become consistently interactive. Or in other words, your page may appear fully loaded, but when a user clicks any of your buttons or menus, the user may experience some slowdown because the JavaScript hasn't finished executing. In the worst case scenario, users may be forced to keep clicking the button for upwards of 10 seconds, just waiting for that magical moment where something actually happens. Think about how confusing and frustrating that can be.</p>
 <figure id="fig-2">
-  <iframe class="fig-mobile fig-desktop" width="560" height="315" src="https://www.youtube.com/embed/Lx1cYJAVnzA" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen="" loading="lazy"></iframe>
-  <figcaption><a href="#fig-2" class="anchor-link">Figure 2.</a> Example of how painful of an experience waiting for JS to load can be.</figcaption>
+  <iframe class="fig-mobile fig-desktop video-embed" width="560" height="315" src="https://www.youtube.com/embed/Lx1cYJAVnzA" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen="" aria-labelledby="fig2-caption" aria-describedby="fig2-description" loading="lazy"></iframe>
+  <a class="video-fallback-image" href="https://www.youtube.com/embed/Lx1cYJAVnzA">
+    <img src="/static/images/2019/mobile-web/fig2.png" alt="Figure 2. Example of how painful of an experience waiting for JS to load can be." aria-labelledby="fig2-caption" aria-describedby="fig2-description" width="600" height="343" loading="lazy" />
+  </a>
+  <div id="fig2-description" class="visually-hidden">Video showing two web pages loading and each page has a figure tapping repeatedly on a button throughout the video, to no effect. There is a clock ticking up from 0 seconds at the top, and an initial happy emoji face for each website, that starts to turn less happy as clock passes 6 seconds, wide-eyed at 8 seconds, angry at 10 seconds, really angry at 13 seconds and crying at 19 seconds shortly after which the video ends.</div>
+  <figcaption id="fig2-caption"><a href="#fig-2" class="anchor-link">Figure 2.</a> Example of how painful of an experience waiting for JS to load can be.</figcaption>
 </figure>
 <p>Let's delve deeper and look at another metric that focuses more on <em>how well</em> each page utilizes JavaScript. For example, does it really need as much JavaScript as it's loading? We call this metric the <em>JavaScript Bloat Score</em>, based on the <a href="https://www.webbloatscore.com/">web bloat score</a>. The idea behind it is this:</p>
 <ul>
@@ -201,7 +205,7 @@ <h3 id="color-contrast"><a href="#color-contrast" class="anchor-link">Color cont
   <a href="/static/images/2019/mobile-web/example-of-good-and-bad-color-contrast-lookzook.png">
     <img src="/static/images/2019/mobile-web/example-of-good-and-bad-color-contrast-lookzook.png" alt="Figure 4. Example of what text with insufficient color contrast looks like. Courtesy of LookZook" aria-labelledby="fig4-caption" aria-describedby="fig4-description" width="650" height="300" loading="lazy" />
   </a>
-  <div id="fig4-description" class="visually-hidden">Four colored boxes of orange and gray shades with white text overlaid inside creating two columns, one where the background color is too lightly colored compared to the white text and one where the background color is recommended compared to the white text. The hex code of each color is displayed, white is #FFFFFF, the light shade of orange background is #FCA469, and the recommended shade of orange background is #F56905. Image courtesy of LookZook</div>
+  <div id="fig4-description" class="visually-hidden">Four colored boxes of orange and gray shades with white text overlaid inside creating two columns, one where the background color is too lightly colored compared to the white text and one where the background color is recommended compared to the white text. The hex code of each color is displayed, white is <code>#FFFFFF</code>, the light shade of orange background is <code>#FCA469</code>, and the recommended shade of orange background is <code>#F56905</code>. Image courtesy of LookZook</div>
   <figcaption id="fig4-caption"><a href="#fig-4" class="anchor-link">Figure 4.</a> Example of what text with insufficient color contrast looks like. Courtesy of LookZook</figcaption>
 </figure>
 <p>For colorblindness stats for other demographics, see <a href="https://web.archive.org/web/20180304115406/http://www.allpsych.uni-giessen.de/karl/colbook/sharpe.pdf">this paper</a>.</p>
@@ -294,9 +298,7 @@ <h3 id="pasting-into-password-fields"><a href="#pasting-into-password-fields" cl
 <p>Enabling users to copy and paste their passwords into your page is one way that allows them to use password managers. Password managers help users generate (and remember) strong passwords and fill them out automatically on web pages. Only 0.02% of web pages tested disable this functionality.</p>
 <p class="note">Note: While this is very encouraging, this may be an underestimation due to the requirement of our <a href="./methodology">Methodology</a> to only test home pages. Interior pages, like login pages, are not tested.</p>
 <h2 id="conclusion"><a href="#conclusion" class="anchor-link">Conclusion</a></h2>
-<p>
-  For over 13 years we've been treating the <em>mobile</em> web as an afterthought, like a mere exception to desktop. But it's time for this to change. The mobile web is now <em><em>the</em></em> web, and desktop is becoming the legacy one. There are now 4 billion active smartphones in the world, covering 70% of all potential users. What about desktops? They currently sit at 1.6 billion, and account for less and less of web usage every month.
-</p>
+<p>For over 13 years we've been treating the <em>mobile</em> web as an afterthought, like a mere exception to desktop. But it's time for this to change. The mobile web is now <em>the</em> web, and desktop is becoming the legacy one. There are now 4 billion active smartphones in the world, covering 70% of all potential users. What about desktops? They currently sit at 1.6 billion, and account for less and less of web usage every month.</p>
 <p>How well are we doing catering to mobile users? According to our research, even though 71% of sites make some kind of effort to adjust their site for mobile, they're falling well below the mark. Pages take forever to load and become unusable thanks to an abuse of JavaScript, text is often impossible to read, engaging with sites via clicking links or buttons is error-prone and infuriating, and tons of great technologies invented to mitigate these problems (Service Workers, autocomplete, zooming, new image formats, etc) are barely being used at all.</p>
 <p>The mobile web has now been around long enough for there to be an entire generation of kids where this is the only internet they've ever known. And what kind of experience are we giving them? We're essentially taking them back to the dial-up era. (Good thing I hear AOL still sells those CDs providing 1000 hours of free internet access!)</p>
 <figure id="fig-9">

src/templates/en/2019/ebook.html

@@ -5003,8 +5003,12 @@ <h3 id="mobile-web-pages-bloated-with-javascript"><a href="#mobile-web-pages-blo
     <p>The state of JavaScript on the mobile web is terrifying. According to HTTP Archive's <a href="https://httparchive.org/reports/state-of-javascript?start=2016_05_15&amp;end=2019_07_01&amp;view=list#bytesJs">JavaScript report</a>, the median mobile site requires phones to download 375 KB of JavaScript. Assuming a 70% compression ratio, this means that phones have to parse, compile, and execute 1.25 MB of JavaScript at the median.</p>
     <p>Why is this a problem? Because sites loading this much JS take upwards of <a href="https://httparchive.org/reports/loading-speed?start=earliest&amp;end=2019_07_01&amp;view=list#ttci">10 seconds</a> to become consistently interactive. Or in other words, your page may appear fully loaded, but when a user clicks any of your buttons or menus, the user may experience some slowdown because the JavaScript hasn't finished executing. In the worst case scenario, users may be forced to keep clicking the button for upwards of 10 seconds, just waiting for that magical moment where something actually happens. Think about how confusing and frustrating that can be.</p>
     <figure id="mobile-web-fig-2">
-      <iframe class="fig-mobile fig-desktop" width="560" height="315" src="https://www.youtube.com/embed/Lx1cYJAVnzA" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen="" loading="lazy"></iframe>
-      <figcaption><a href="#mobile-web-fig-2" class="anchor-link">Figure 2.</a> Example of how painful of an experience waiting for JS to load can be.</figcaption>
+      <iframe class="fig-mobile fig-desktop video-embed" width="560" height="315" src="https://www.youtube.com/embed/Lx1cYJAVnzA" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen="" aria-labelledby="fig2-caption" aria-describedby="fig2-description" loading="lazy"></iframe>
+      <a class="video-fallback-image" href="https://www.youtube.com/embed/Lx1cYJAVnzA">
+        <img src="/static/images/2019/mobile-web/fig2.png" alt="Figure 2. Example of how painful of an experience waiting for JS to load can be." aria-labelledby="fig2-caption" aria-describedby="fig2-description" width="600" height="343" loading="lazy" />
+      </a>
+      <div id="mobile-web-fig2-description" class="visually-hidden">Video showing two web pages loading and each page has a figure tapping repeatedly on a button throughout the video, to no effect. There is a clock ticking up from 0 seconds at the top, and an initial happy emoji face for each website, that starts to turn less happy as clock passes 6 seconds, wide-eyed at 8 seconds, angry at 10 seconds, really angry at 13 seconds and crying at 19 seconds shortly after which the video ends.</div>
+      <figcaption id="mobile-web-fig2-caption"><a href="#mobile-web-fig-2" class="anchor-link">Figure 2.</a> Example of how painful of an experience waiting for JS to load can be.</figcaption>
     </figure>
     <p>Let's delve deeper and look at another metric that focuses more on <em>how well</em> each page utilizes JavaScript. For example, does it really need as much JavaScript as it's loading? We call this metric the <em>JavaScript Bloat Score</em>, based on the <a href="https://www.webbloatscore.com/">web bloat score</a>. The idea behind it is this:</p>
     <ul>
@@ -5061,7 +5065,7 @@ <h3 id="mobile-web-color-contrast"><a href="#mobile-web-color-contrast" class="a
       <a href="https://almanac.httparchive.org/static/images/2019/mobile-web/example-of-good-and-bad-color-contrast-lookzook.png">
         <img src="/static/images/2019/mobile-web/example-of-good-and-bad-color-contrast-lookzook.png" alt="Figure 4. Example of what text with insufficient color contrast looks like. Courtesy of LookZook" aria-labelledby="fig4-caption" aria-describedby="fig4-description" width="650" height="300" loading="lazy" />
       </a>
-      <div id="mobile-web-fig4-description" class="visually-hidden">Four colored boxes of orange and gray shades with white text overlaid inside creating two columns, one where the background color is too lightly colored compared to the white text and one where the background color is recommended compared to the white text. The hex code of each color is displayed, white is #FFFFFF, the light shade of orange background is #FCA469, and the recommended shade of orange background is #F56905. Image courtesy of LookZook</div>
+      <div id="mobile-web-fig4-description" class="visually-hidden">Four colored boxes of orange and gray shades with white text overlaid inside creating two columns, one where the background color is too lightly colored compared to the white text and one where the background color is recommended compared to the white text. The hex code of each color is displayed, white is <code>#FFFFFF</code>, the light shade of orange background is <code>#FCA469</code>, and the recommended shade of orange background is <code>#F56905</code>. Image courtesy of LookZook</div>
       <figcaption id="mobile-web-fig4-caption"><a href="#mobile-web-fig-4" class="anchor-link">Figure 4.</a> Example of what text with insufficient color contrast looks like. Courtesy of LookZook</figcaption>
     </figure>
     <p>For colorblindness stats for other demographics, see <a href="https://web.archive.org/web/20180304115406/http://www.allpsych.uni-giessen.de/karl/colbook/sharpe.pdf">this paper</a>.</p>
@@ -5154,9 +5158,7 @@ <h3 id="mobile-web-pasting-into-password-fields"><a href="#mobile-web-pasting-in
     <p>Enabling users to copy and paste their passwords into your page is one way that allows them to use password managers. Password managers help users generate (and remember) strong passwords and fill them out automatically on web pages. Only 0.02% of web pages tested disable this functionality.</p>
     <p class="note">Note: While this is very encouraging, this may be an underestimation due to the requirement of our <a href="#methodology">Methodology</a> to only test home pages. Interior pages, like login pages, are not tested.</p>
     <h2 id="mobile-web-conclusion"><a href="#mobile-web-conclusion" class="anchor-link">Conclusion</a></h2>
-    <p>
-      For over 13 years we've been treating the <em>mobile</em> web as an afterthought, like a mere exception to desktop. But it's time for this to change. The mobile web is now <em><em>the</em></em> web, and desktop is becoming the legacy one. There are now 4 billion active smartphones in the world, covering 70% of all potential users. What about desktops? They currently sit at 1.6 billion, and account for less and less of web usage every month.
-    </p>
+    <p>For over 13 years we've been treating the <em>mobile</em> web as an afterthought, like a mere exception to desktop. But it's time for this to change. The mobile web is now <em>the</em> web, and desktop is becoming the legacy one. There are now 4 billion active smartphones in the world, covering 70% of all potential users. What about desktops? They currently sit at 1.6 billion, and account for less and less of web usage every month.</p>
     <p>How well are we doing catering to mobile users? According to our research, even though 71% of sites make some kind of effort to adjust their site for mobile, they're falling well below the mark. Pages take forever to load and become unusable thanks to an abuse of JavaScript, text is often impossible to read, engaging with sites via clicking links or buttons is error-prone and infuriating, and tons of great technologies invented to mitigate these problems (Service Workers, autocomplete, zooming, new image formats, etc) are barely being used at all.</p>
     <p>The mobile web has now been around long enough for there to be an entire generation of kids where this is the only internet they've ever known. And what kind of experience are we giving them? We're essentially taking them back to the dial-up era. (Good thing I hear AOL still sells those CDs providing 1000 hours of free internet access!)</p>
     <figure id="mobile-web-fig-9">