Fix a bunch of typos

Author: csswizardry

_posts/2017-01-25-moving-css-wizardry-onto-https-and-http-2.md

@@ -38,7 +38,7 @@ prerequisite for a number of other technologies, and having a secure
 site—regardless of its content—is never a bad thing. More on the first bit in a
 moment, but for now I want to talk a little about security.
 
-I imagine that although most users won’t have much of a understanding as to the
+I imagine that although most users won’t have much of an understanding as to the
 technical implications behind a secure or a not-secure site (I’m hesitant to use
 the word _insecure_), they are becoming aware that there is such thing as
 security. With Google’s intent to [mark certain websites as
@@ -59,12 +59,12 @@ HTTP/1.1 protocol that we’ve been using for almost two decades. It brings many
 benefits to both developers and users, but many of its best features are centred
 around performance:
 
-* Compressed headers: HTTP/1.1 sends its headers uncompressed, which creates a
-  surprising amount of overhead. HTTP/2 reduces that by compressing the response
-  headers as well as the response body.
-* Multiplexing: get around head of line blocking and lack of parallelisation by
-  sending multiple assets asynchronously over the same TCP connection.
-* Server push: allows developers to send late requested assets preemptively.
+* **Compressed headers**: HTTP/1.1 sends its headers uncompressed, which creates
+  a surprising amount of overhead. HTTP/2 reduces that by compressing the
+  response headers as well as the response body.
+* **Multiplexing:** get around head of line blocking and lack of parallelisation
+  by sending multiple assets asynchronously over the same TCP connection.
+* **Server push**: allows developers to send late requested assets preemptively.
 
 A lot of HTTP/2’s additions will moot the domain sharding, concatenating, and
 inlining strategies we came up with as hacks, and will instead allow us to
@@ -75,18 +75,18 @@ performance boost right out of the box.
 Further, HTTP/2 is required in order for certain other technologies to be
 utilised:
 
-* Brotli, an improved compression algorithm from Google, needs to run over
+* **Brotli**, an improved compression algorithm from Google, needs to run over
   HTTP/2 because of third parties (ISPs, proxies, etc.) infamously trying to
-  recompress already compressed transfer. By preventing them getting at at all,
-  it means that they can’t try running gzip over a new, unknknow content
-  encoding (e.g. Brotli).
-* Service Worker absolutely needs to run over HTTP/2, because it’s basically a
-  man in the middle. We’re building a proxy that sits in between our users and
+  recompress already compressed transfer. By preventing them getting at it in
+  the first place, it means that they can’t try running gzip over a new, unknown
+  content encoding (e.g. Brotli).
+* **Service Worker** absolutely needs to run over HTTP/2, because it’s basically
+  a man in the middle. We’re building a proxy that sits in between our users and
   our servers, so the need for security there should be pretty clear.
 
 Currently I’m not making that much use of anything HTTP/2 offers me other than
 multiplexing and header compression (because I didn’t even have to lift a
-finger) for those. My site is already pretty slim, and I’m serving so few assets
+finger for those). My site is already pretty slim, and I’m serving so few assets
 that one could almost argue over-engineering, but one really great example of
 where I will benefit from HTTP/2 multiplexing is this [relatively large list of
 images on the homepage](/#section:clients).
@@ -95,7 +95,7 @@ images on the homepage](/#section:clients).
 
 Support for HTTP/2 is [pretty good](http://caniuse.com/#feat=http2), and always
 improving. Servers capable of serving over HTTP/2 will also still deliver to
-HTTP/1.1 clients, so nothing will break.
+HTTP/1.x clients, so nothing will break.
 
 However, it might not be time for your company to switch over too.
 Unfortunately, HTTP/2 best practices become bad practices in HTTP/1.1, and