Close out final 2020 Fonts Chapter TODOs

src/content/en/2020/fonts.md

@@ -20,7 +20,6 @@ featured_stat_2: 10.3%
 featured_stat_label_2: Usage of <code>font-display</code> swap
 featured_stat_3: 11.0%
 featured_stat_label_3: Usage of Variable Fonts on mobile sites
-unedited: true
 ---
 ## Introduction
 
@@ -64,9 +63,7 @@ The country that uses the most font bytes is South Korea, which is not all that
   )
 }}
 
-There's a great thread on [web font usage by country](https://discuss.httparchive.org/t/how-does-web-font-usage-vary-by-country/1649) on the HTTP Archive discussion forum.
-
-{# TODO (authors) - this sentence is a bit hanging our there. What's great about this thread compared to what we are covering here? Is it that you're wanting to credit that thread as the basis for the queries used by this chapter (if so say so), or you believe they have more insights than you have here (again in which case say so, but reading through the thread doesn't seem that much more, and even if there was could it not be summarised more here?), or is it you're wanting to direct people to there for further discussions? #}
+There's an interesting thread on [web font usage by country](https://discuss.httparchive.org/t/how-does-web-font-usage-vary-by-country/1649) on the HTTP Archive discussion forum that certainly influenced the queries used by this chapter. Given the large number of typefaces produced for Asian languages, it's likely usage will rise in that region as technology for serving those fonts more efficiently becomes available.
 
 ### Serving with a service
 
@@ -105,16 +102,12 @@ It was interesting to note the differences in speed for sites using the various
   )
 }}
 
-When viewing commercial services such as Adobe (`use.typekit.net`) or Monotype (`fast.fonts.com`) it is interesting to note that on desktop they tend to be as fast or slightly faster than Google Fonts, but are noticeably slower on mobile. Conventional wisdom has generally held that the tracking scripts used by those services substantially slow them down, but that is apparently less an issue today than it has been in years past.
-
-{# TODO authors - Do we want to add a note to say that we are measuring site performance and not necessarily font hoster performance? It could be that Adobe sites are all just pooor on mobile and it's nothing to do with their hosting platform #}
+When viewing commercial services such as Adobe (`use.typekit.net`) or Monotype (`fast.fonts.com`) it is interesting to note that on desktop they tend to be as fast or slightly faster than Google Fonts, but are noticeably slower on mobile. Conventional wisdom has generally held that the tracking scripts used by those services substantially slow them down, but that is apparently less an issue today than it has been in years past. While it's true that we are measuring site performance and not necessarily font hoster performance, those tracking scripts impact font loading on the client so it seems relevant to include these observations.
 
 #### Self-hosting isn't always better
 
 Self-hosting fonts on the same domain as the website can be faster, as [we discovered for this very website](https://www.tunetheweb.com/blog/should-you-self-host-google-fonts/), however this is not always the case as the data shows.
 
-{# TODO Authors - Suggested different wording here, and moved `local` down to below. Let me knwo your thoughts. Particularly as I inserted a reference to my own site here which is a bit presumptious of me :-) but it is about the Web Almanac so think it fits. #}
-
 {{ figure_markup(
   image="fonts-web-hosting-performance-desktop.png",
   caption="Web font hosting performance, desktop.",
@@ -135,9 +128,7 @@ Self-hosting fonts on the same domain as the website can be faster, as [we disco
   )
 }}
 
-It wouldn't be sound to infer causality between hosting strategy from the above data, as there are other variables that may confound the relationship. But, putting that aside, we find that adding the self-hosting fonts doesn't always lead to better performance. Hosted font solutions often perform a number of optimizations that may not always be replicated when self-hosting.
-
-{# TODO Authors - Review above alterations #}
+It wouldn't be sound to infer causality between hosting strategy from the above data, as there are other variables that may confound the relationship. But, putting that aside, we find that adding the self-hosting fonts doesn't always lead to better performance. Hosted font solutions often perform a number of optimizations (like subsetting, removing OpenType features, and ensuring the smallest possible font format) that may not always be replicated when self-hosting.
 
 #### Local isn't always better
 
@@ -329,9 +320,11 @@ Lots more information about color fonts, including examples, are available at [c
 
 Variable fonts are certainly one of the biggest stories this year. They're seen in 10.54% of desktop pages, and 11.00% of mobile. That's up from an average of 1.8% last year, a huge growth factor. It is not hard to see why their popularity is increasing – they offer more design flexibility, and also potentially smaller binary font sizes, especially if multiple styles of the same font are used on the same page.
 
-{# That's huge usage! Any ideas what's driven it? It would appear no variable font has any where near that usage so how come total usage is so high? Has any particular service or platform turned this on by default? #}
+Likely the greatest driver of this increase is due to Google Fonts now serving a number of their more popular offerings as variable fonts when there are enough weights in use on a page and the browser supports them. The ability to 'swap in' variable fonts where a performance gain can be achieved without altering any of the CSS in use or any intervention required of the web author is a remarkable testament to the viability of the technology.
+
+The simplest description of the variable font format is a single font file that acts as many: rather than individual font files for every weight and width or even italics, they can all be contained in a single, highly efficient file. That resulting file can render the font at a given combination of axis values via CSS (or other applications that support them). There are a number of standardized, or 'registered', axes plus the ability for font designers to define their own axes and expose them to the user.
 
-{# TODO - authors Should we add a paragraph or bullet list explaing the common font axis and what they mean before launching into their usage? What is difference between wght and wdth? And between slnt and ital? Web Almanac readers may come here from pother chapters and not be familiar with these terms. Plus I am a little familair and don't know these answers! #}
+Weight (`wght`) corresponds to the traditional notion of regular or bold or light; width (`wdth`) maps to styles like condensed or extended; slant (`slnt`) refers to an oblique angle of the font; italic (`ital`) usually slants the font and replaces certain glyphs with alternate styles; and optical size (`opsz`) refers to something relatively new to the web, but is actually a revival of a technique common in metal type creation going back hundreds of years. Historically, optical sizing refers to the practice of reducing stroke contrast (thick and thin lines) and open up letter spacing when a font is made at a physically smaller size in order to increase legibility, and conversely to increase that contrast and tighten spacing when a font is displayed at much larger sizes. Enabling this in digital type can allow a single font to look and behave substantially differently when used at very small or large sizes. You can learn more about them and see lots of examples at [variablefonts.io](https://variablefonts.io).
 
 {{ figure_markup(
   image="fonts-font-variation-settings-usage.png",