Merge branch 'master' of https://github.com/mmistakes/made-mistakes-j…

…ekyll

src/_data/comments/short-guide/comment-1477264530494.yml

@@ -0,0 +1,6 @@
+message: "Hi Michael,\r\nI just discovered your lessons as I am just getting into iPad art and I think they are really awesome! I apologize if I am being redundant about anything, but exactly which iPad are you using for this? I have an iPad Air 1 and am having trouble finding others who use this iPad and know which styli work with it. I understand apple changed the technology in the air 2, which is why I am often confused whether a stylus will work properly with my iPad. Would you recommend the Pencil to use with Paper, or the Pogo Connect, specifically on the iPad Air 1?  I've been reading great things on both styli but am unsure if it is for Air 1 or 2.\r\nThank you for taking the time to read my unnecessarily wrong message, and I look forward to hearing back! \r\nKeep up the great work!"
+name: Cari
+email: ab9e4031ce22d7ca7c977cb12c6f1a4c
+url: ''
+hidden: ''
+date: '2016-10-23T23:15:29.851Z'

src/_data/comments/short-guide/comment-1477270163289.yml

@@ -0,0 +1,6 @@
+message: "@Cari - I have an iPad Air 2 and you can read up on my [stylus recommendations here](https://mademistakes.com/faqs/stylus-recommendations/). Pencil has good [compatibility with older devices](https://support.fiftythree.com/hc/en-us/articles/201712591-Using-Pencil#ipad-compatibility) and does work with the original Air.\r\n\r\nI had the original Pogo Connect and used that with an iPad 3rd gen. I know when the original Air came out it had all kinds of issues with it and pretty sure didn't work since Apple changed the screen tech. There's a Pogo Connect 2 now that works with the Air 2, but no idea if it works with the original Air. Probably best to check the manufacturer's site."
+name: Michael Rose
+email: 1ce71bc10b86565464b612093d89707e
+url: 'https://mademistakes.com'
+hidden: ''
+date: '2016-10-24T00:49:22.600Z'

src/_posts/til/2016-10-21-using-ssi.md → src/_drafts/using-ssi.md

@@ -1,8 +1,11 @@
 ---
 title: "Using SSI to Detect Cookies"
+layout: page
+category: til
 excerpt:
 image: 
-  teaser:
+  path: /assets/images/using-ssi.jpg
+  teaser: /assets/images/using-ssi-teaser.jpg
 tags: [web development, Jekyll]
 ---
 
@@ -19,19 +22,19 @@ Analyzed with [Google's PageSpeed Insights](https://developers.google.com/speed/
   <figcaption>{{ pagespeed_caption | markdownify | remove: "<p>" | remove: "</p>" }}</figcaption>
 </figure>
 
-This process wasn't ideal for a variety of reasons:
+This workflow wasn't ideal for a variety of reasons:
 
 1. Manual process.
 2. Need to maintain separate "critical" stylesheets for inlining.
 3. Included a bunch of declarations that aren't critical to rendering "above the fold" content ---  causing some file size bloat.
 
-So with the help of [**Critical**](https://github.com/addyosmani/critical) and friends I attempted to automated the process in the next release of the site. Getting it working within the constraints of a Jekyll site with thousands of posts wasn't easy, but I got close with these [Gulp tasks](https://github.com/mmistakes/made-mistakes-jekyll/tree/master/gulp/tasks). A tale for another day unfortunately...
+So with the help of [**Critical**](https://github.com/addyosmani/critical) (and friends) I attempted to automated the process. Getting it working within the constraints of a Jekyll site with thousands of posts wasn't easy, but I got close with [a set of Gulp tasks](https://github.com/mmistakes/made-mistakes-jekyll/tree/master/gulp/tasks). A tale for another day unfortunately...
 
 Sorry a little off topic there, back to SSI directives.
 
-To speed things up for repeat visitors, loading a cached version of the CSS instead of waiting for **loadCSS** to do its thing is preferred. Using Filament Group's aptly named [**Enhance.js**](https://github.com/filamentgroup/enhance) project as a boilerplate, I learned that this can be achieved with a cookie and SSI directives.
+I learned that to speed up things for repeat visitors, loading a cached version of the CSS instead of waiting for **loadCSS** to do its thing was preferred. By using Filament Group's aptly named [**Enhance.js**](https://github.com/filamentgroup/enhance) project as a boilerplate, this could be achieved by dropping a cookie and using SSI directives.
 
-Structuring our HTML a little something like this:
+Structuring our HTML looks a little like like this:
 
 ```html
 <!--#if expr="$HTTP_COOKIE=/fullcss\=true/" -->
@@ -48,10 +51,10 @@ The `#if` and `#else` conditionals are SSI directives used by Apache to do some
 
 *[SSI]: Server Side Includes
 
-For first time visitors without this cookie:
+For first time visitors:
 
 1. Critical CSS inlined within the `<style>` element will load almost instantly.
-2. **loadCSS** script will asynchronously the remaining page CSS as not to block rendering.
+2. **loadCSS** script will asynchronously load the remaining page CSS as not to block rendering.
 3. A cookie will be set to trigger the loading of cached CSS on future page loads.
 
 After setting all this up and testing my pages against [**WebPagetest**](https://www.webpagetest.org/), [**PageSpeed Insights**](https://developers.google.com/speed/pagespeed/insights/), and [**GTmetrix**](https://gtmetrix.com/) I saw an obvious drop in scrores :confused:. Apparently the SSI directives weren't working as intended, causing `style.css` to render block each page load. Hmmmm...