From 248c985e3c2c3983426b67a397ff1e58672427c2 Mon Sep 17 00:00:00 2001
From: luxagraf <sng@luxagraf.net>
Date: Tue, 1 Dec 2015 10:43:26 -0500
Subject: initial commit

---
 .../2013-09-25_writing-in-the-open.txt             |  50 +++++
 .../2013-09-30_responsive-images-srcset.txt        | 181 +++++++++++++++
 ...8_easiest-way-get-started-designing-browser.txt | 116 ++++++++++
 ...2014-02-02_work-smarter-plain-text-workflow.txt | 250 +++++++++++++++++++++
 .../2014-02-12_what-is-responsive-web-design.txt   |  75 +++++++
 .../2014-02-19_complete-guide-picture-element.txt  | 235 +++++++++++++++++++
 ...0_live-editing-sass-firefox-vim-keybindings.txt | 118 ++++++++++
 ...to-build-responsive-websites-like-bruce-lee.txt |  54 +++++
 .../2014-03-12_zen-art-responsive-workflow.txt     |  86 +++++++
 ...better-link-underlines-css-background-image.txt |  58 +++++
 .../2014-03-20_look-responsive-design.txt          |  36 +++
 .../2014-03-26_shell-code-snippets-done-right.txt  |  48 ++++
 ...14-04-05_why-mobile-first-responsive-design.txt |  52 +++++
 .../2014-04-23_learn-web-development-today.txt     |  89 ++++++++
 .../2014-04-26_create-email-courses-mailchimp.txt  | 205 +++++++++++++++++
 ...ould-you-wrap-headers-images-and-text-links.txt |  39 ++++
 .../2014-10-03_using-picture-vs-img.txt            |  72 ++++++
 .../2014-10-10_lenovo-chromebook-review.txt        |  86 +++++++
 .../2014-10-28_google-progressive-enhancement.txt  |  31 +++
 .../2015-01-15_google-mobile-friendly-label.txt    |  34 +++
 src/old-no-longer-pub/2015-10-03_wordpress-1.txt   |  48 ++++
 21 files changed, 1963 insertions(+)
 create mode 100644 src/old-no-longer-pub/2013-09-25_writing-in-the-open.txt
 create mode 100644 src/old-no-longer-pub/2013-09-30_responsive-images-srcset.txt
 create mode 100644 src/old-no-longer-pub/2013-11-08_easiest-way-get-started-designing-browser.txt
 create mode 100644 src/old-no-longer-pub/2014-02-02_work-smarter-plain-text-workflow.txt
 create mode 100644 src/old-no-longer-pub/2014-02-12_what-is-responsive-web-design.txt
 create mode 100644 src/old-no-longer-pub/2014-02-19_complete-guide-picture-element.txt
 create mode 100644 src/old-no-longer-pub/2014-02-20_live-editing-sass-firefox-vim-keybindings.txt
 create mode 100644 src/old-no-longer-pub/2014-03-04_how-to-build-responsive-websites-like-bruce-lee.txt
 create mode 100644 src/old-no-longer-pub/2014-03-12_zen-art-responsive-workflow.txt
 create mode 100644 src/old-no-longer-pub/2014-03-19_better-link-underlines-css-background-image.txt
 create mode 100644 src/old-no-longer-pub/2014-03-20_look-responsive-design.txt
 create mode 100644 src/old-no-longer-pub/2014-03-26_shell-code-snippets-done-right.txt
 create mode 100644 src/old-no-longer-pub/2014-04-05_why-mobile-first-responsive-design.txt
 create mode 100644 src/old-no-longer-pub/2014-04-23_learn-web-development-today.txt
 create mode 100644 src/old-no-longer-pub/2014-04-26_create-email-courses-mailchimp.txt
 create mode 100644 src/old-no-longer-pub/2014-05-16_should-you-wrap-headers-images-and-text-links.txt
 create mode 100644 src/old-no-longer-pub/2014-10-03_using-picture-vs-img.txt
 create mode 100644 src/old-no-longer-pub/2014-10-10_lenovo-chromebook-review.txt
 create mode 100644 src/old-no-longer-pub/2014-10-28_google-progressive-enhancement.txt
 create mode 100644 src/old-no-longer-pub/2015-01-15_google-mobile-friendly-label.txt
 create mode 100644 src/old-no-longer-pub/2015-10-03_wordpress-1.txt

(limited to 'src/old-no-longer-pub')

diff --git a/src/old-no-longer-pub/2013-09-25_writing-in-the-open.txt b/src/old-no-longer-pub/2013-09-25_writing-in-the-open.txt
new file mode 100644
index 0000000..6a9e33f
--- /dev/null
+++ b/src/old-no-longer-pub/2013-09-25_writing-in-the-open.txt
@@ -0,0 +1,50 @@
+---
+title: Writing in the Open
+pub_date: 2013-09-25 14:14:55
+slug: /blog/2013/09/writing-in-the-open
+
+---
+
+Whew! Crazy weekend. I wasn't really prepared for how the web would react to learning that [Webmonkey is no more][9]. My inbox blew up. Clearly Webmonkey will be missed. Thanks to everyone who sent me their thoughts on Webmonkey shutting down and all the stories about learning HTML (DHTML natch), CSS or JavaScript from the site. Also, glad to hear that there are apparently so many Webmonkey beanies out there. Anyway, if I'm a little slow responding to you, I apologize, but rest assured I have read everyone's email and I will get back to you all in the next few days
+ 
+In the mean time, you should go read Brad Frost's recent post on [Designing in the Open][1]. 
+
+Frost and his wife, Melissa, are redesigning the Greater Pittsburgh Community Food Banks website and have decided to do everything in the open so the rest of us can see the process. There's a [very cool looking timeline][2] and a [post about their process so far][3]. In that post Melissa quotes a comment Josh Long wrote some time ago on Chris Coyier's [Working in Public][4] post (itself a good example) about why you would want to risk the potential embarrassment or ridicule or whatever else you're afraid of to work publicly:
+
+>   1. It makes you think clearly and directly.
+>   2. It forces you to know what the hell you're talking about.
+>   3. It shows people how much you put into your work.
+>   4. It's a great way to document your work.
+>   5. It's a great way to give back and teach others.
+
+To that I would add a couple more: it teaches you what you know (and don't), and it's fun, because really, if this isn't fun you shouldn't do it. 
+
+The main reason we don't show our processes more or work in public is fear. Fear that, as Melissa Frost says, you'll embarrass yourself or that you'll be seen as a fraud or <your fear here>. Fear is self-created though. Fear is _our_ reaction to an imaginary negative event _we've_ projected into the future. It's something that might happen, but hasn't. Fear can be helpful. For example, you're afraid you'll forget about an important meeting and that fear prompts you to write it down on your calendar. But more often than not fear is not helpful. More often than not fear - that imaginary projection into the future - ends up inhibiting us in the present. It stops you from sharing the stuff you've made for instance. I put off launching this site for months, at least partly out of fear. 
+
+So fuck fear. I don't have a cool looking timeline like the Frosts', nor do I have a super cool working new/old design split for this site like [Sparkbox's open redesign site][5]. But, in lieu of anything else, I do have a screenshot of my responsive web design book in progress: 
+
+![responsive web design in progress](/media/images/2013/rwdbook-inprogress.jpg)
+
+Does that count as working in the open? Probably not. But that's the best I can do at the moment. One of the early issues of McSweeneys had a line drawing of a bird with one wing, below it was the caption "trying, trying, trying". That's how I feel.
+
+If there's interest I could write more about what it's like to write a book (which I could title, how I tricked myself into writing 40,000 words in three weeks). At some point I'd like to take working in the open even further and put the "source" of the book in a public Git repository to make it easy for other people to fix typos, contribute resource links or, well - who knows what else people might end up doing? 
+
+I think that's probably the best reason to do anything "in the open" - it opens more doors for other people. Yeah some of them will be jerks and trolls. But in my experience most of them are not.
+
+And opening the door to others opens the door to serendipity. And serendipity often leads to magic.
+
+When you put things out in the world the world takes them, plays with them - sometimes nicely, sometimes not - and unexpected things start to happen. In my experience these things tend to be good. Random @replies morph into friends, ideas spark others' imaginations. I find there ends up being a lot of synchronicity - ideas colliding in interesting ways, what Robert Anton Wilson called "[Coincidance][8]". 
+
+I've never tried designing in the open, but I'd like to do more writing in the open. If you've got any good ideas on how to do that, please let me know.
+
+Okay, back to work.
+
+[1]: http://bradfrostweb.com/blog/post/designing-in-the-open/ (bradfrostweb.com, Designing in the Open)
+[2]: http://foodbank.bradfrostweb.com/
+[3]: http://melissafrostdesign.com/post/pittsburgh-food-bank-open-redesign/
+[4]: http://chriscoyier.net/2012/09/23/working-in-public/
+[5]: http://building.seesparkbox.com/
+[6]: https://longhandpixels.net/media/images/2013/xrwdbook-inprogress-sm.jpg.
+[7]: /media/images/2013/rwdbook-inprogress.jpg (view larger image of responsive design book in progress)
+[8]: http://www.amazon.com/Coincidance-Head-Robert-Anton-Wilson/dp/1561840041
+[9]: /blog/2013/09/whatever-happened-to-webmonkey
diff --git a/src/old-no-longer-pub/2013-09-30_responsive-images-srcset.txt b/src/old-no-longer-pub/2013-09-30_responsive-images-srcset.txt
new file mode 100644
index 0000000..3b3e02b
--- /dev/null
+++ b/src/old-no-longer-pub/2013-09-30_responsive-images-srcset.txt
@@ -0,0 +1,181 @@
+---
+title: Responsive Images & `srcset`
+pub_date: 2013-09-30 20:08:57
+slug: /blog/2013/09/responsive-images-srcset
+metadesc: A comprehensive overview of responsive images and the srcset attribute. Regularly updated to keep up with changing standards proposals.
+code: True
+tags: Responsive Images
+---
+
+[Note: This post is superseded by the fact that the picture element now exists. Picture supports srcset as well, so you can do everything I mention below, you just do it within `<picture>`. See my [complete guide to the picture element](https://longhandpixels.net/blog/2014/02/complete-guide-picture-element) for more details.]
+
+There are, in my experience, three pain points in any responsive design -- tabular data, advertising and images. The latter is the most interesting problem to me since it's not something you can design or engineer your way around. True, there are ways you can coerce today's browsers into doing roughly what you want -- serve large images to large screens and small ones to small screens -- but these are really hacks, sometimes very clever hacks, but still hacks. 
+
+Nathan Ford has put together a nice [Responsive Images Mega-List][1] in an attempt to catalog all the ways you can handle images in a responsive site today.
+
+That's a great list of resources for handling images today, but what I've been obsessing over lately is the future, when we won't need all these workarounds.
+
+Just like we hacked video into the web using Flash and eventually got the `<video>` tag, we're hacking responsive images into the web and eventually the web is going to give us a native solution. In fact, there's one just around the browser update bend. 
+
+## How `srcset` Simplifies Responsive Images
+
+The exciting thing is that there are not just one, but two responsive image solutions already in the works. The W3C is working on a couple of new tools aimed at making responsive images less complex. The first new feature that's likely to make it to a browser near you is the new `srcset` attribute for the `<img>` tag.
+
+[**Update 27 Feb 2014**: Chrome has [added support](http://blog.chromium.org/2014/02/chrome-34-responsive-images-and_9316.html) for `srcset`, which means it will land in Opera soon as well. The Chrome implementation mirrors what's described below for WebKit. At the same time the `srcset` attribute has been added to the proposed `<picture>` element which you can read about in my [Complete Guide to the <Picture> Element](https://longhandpixels.net/blog/2014/02/complete-guide-picture-element).]
+
+The proposed `srcset` attribute has a controversial history, which I wrote about [several][2] [times][3] on Webmonkey. I don't think any of that matters at this point though. It's true that `srcset` doesn't address everything about responsive images, but it looks to me like it covers the 80 percent use case and, more importantly, there is [already some browser support][4] (and more on the way). 
+
+Here's how `srcset` works:
+    
+~~~.language-markup
+<img alt="Image Desc"
+   src="image.jpg"
+   srcset="image-HD.jpg 2x, image-phone.jpg 320w, image-phone-HD.jpg 320w 2x">
+~~~
+
+As you can see, the `srcset` attribute takes a comma-separated list of values. Within each item in the list you have three variables. First there's the URL to the image, then there's a maximum viewport dimension (optional) and then an optional pixel density (for targeting higher resolution screens). So the `srcset` value `image-HD.jpg 2x` tells the browser, roughly, if you're on a display with high-res screen then grab this high-res image. Pretty simple. You can of course make it much more complex by adding several other images to the list, for example, to target various screen widths.
+
+There are two major drawbacks to `srcset`. First, **you can only specify screen width (or height) in pixels**. The reason has to with how browsers pre-fetch content, which happens long before there's enough info to calculate the value of a percentage or em width/height. See this [thread on the W3C mailing list][5] for details. The bottom line is, flexible units for `srcset` is a no-go.
+
+The other major drawback is that **you can only specify the equivalent of max-width** when defining the viewport dimensions. There is no min-width or orientation support like you'd use in CSS @media queries. That means you may not be able to line your `srcset` breakpoints up with your CSS breakpoints.
+
+There's some other stuff in the spec worth noting as well. For instance, "if the viewport dimensions or pixel density changes, the user agent can replace the image data with a new image on the fly." That means (I think) that, while there's no equivalent to CSS 3 @media's `orientation` query, you could get the same effect because the viewport dimensions change on rotation, triggering larger images to load (though to make that work you'd end up targeting specific device widths, which is not [future-friendly][6]). It's hard to imagine a scenario in which the pixel density would change, but hey, why not I guess?
+
+There is one very cool part of the spec though, it puts the ultimate decision about which images are served in the hands of the user. 
+
+No browser supports it, but the spec says that the higher res images specified in `srcset` are just candidates. Here's the [relevant bit][7]:
+
+> Optionally, return the URL of an entry in *candidates* chosen by the user agent, and that entry's associated pixel density, and then abort these steps. The user agent may apply any algorithm or heuristic in its selection of an entry for the purposes of this step.
+
+So in theory the browser gets the final say. This means the browser can check the available network and make a decision about whether or not to actually obey `srcset`. For instance it might reject the high-res images on 3G, but accept them over wifi. Even better, mobile browsers could add a user preference so users can say (as they can today with native apps), "I only want high-res images over wifi". Or all the time or whatever. The user is in control.
+
+I think that's probably the best way to handle what's possibly a user-developer conflict. For example, I want my images to look good on your retina iPad, but you might want to save your (possibly) expensive bandwidth for other things. I think the user should trump the developer in that scenario. With `srcset` the browser can give the user the power to make that decision.
+
+## Testing `srcset` Today
+
+This is all largely academic right now. Only one browser supports `srcset` and even that's just the nightly builds of Apple's WebKit.
+
+If you want to see it in action, go grab the [latest WebKit nightly][8]. Here's a live demo:
+
+<img src="/media/images/demos/srcsetdemo-fallback.jpg" srcset="/media/images/demos/srcsetdemo-2x.jpg 2x" alt="demo of srcset in action" width="660"/>
+This first test is for retina displays, which looks like this:
+
+~~~.language-markup
+<img alt="demo of srcset in action"
+  src="/media/images/demos/srcsetdemo-fallback.jpg" 
+  srcset="/media/images/demos/srcsetdemo-2x.jpg 2x"  />
+~~~
+
+<img src="/media/images/demos/srcsetdemo-fallback.jpg" srcset="/media/images/demos/srcsetdemo-widthquery.jpg 420w" alt="demo of srcset in action" />
+This test is for mobile screens with a maximum viewport of 420px, here&#8217;s the code:
+
+~~~.language-markup
+<img alt="demo of srcset in action" 
+    src="/media/images/demos/srcsetdemo-fallback.jpg" 
+    srcset="/media/images/demos/srcsetdemo-widthquery.jpg 420w" />
+~~~    
+
+<img src="/media/images/demos/srcsetdemo-fallback.jpg" srcset="/media/images/demos/srcsetdemo-mobile2x.jpg 420w x2" alt="demo of srcset in action" />
+The last test is for mobile high res screens and uses this code:
+
+~~~.language-markup
+<img alt="demo of srcset in action"
+    src="/media/images/demos/srcsetdemo-fallback.jpg" 
+    srcset="/media/images/demos/srcsetdemo-mobile2x.jpg 420w x2" />
+~~~   
+
+<img src="/media/images/demos/srcsetdemo-fallback.jpg" srcset="/media/images/demos/srcsetdemo-superwidequery.jpg 9000w" alt="demo of srcset in action" />
+This final test is designed to check WebKit's current implementation, which does not yet support specifying a width. It's the same query as above, but with a much wider max-width which should trigger it to load in desktop WebKit Nightly.
+
+~~~.language-markup
+<img alt="demo of srcset in action"
+    src="/media/images/demos/srcsetdemo-fallback.jpg" 
+    srcset="/media/images/demos/srcsetdemo-superwidequery.jpg 9000w"  />
+~~~
+    
+
+As of September 30, 2013, using the latest WebKit Nightly (v8536.30.1, 538+) only the first test works. WebKit only supports the pixel density queries, not the max viewport width query.
+
+## Which Web Browsers Support `srcset`?
+
+Eventually caniuse.org will probably [add][8] `srcset` (I think they require at least one shipping version of the feature before they'll track it), but for now I threw together a table for keeping track of which web browsers support `srcset`.
+
+Here's the list as of November 15, 2013:
+
+<div class="longtable">
+<table>
+<colgroup>
+<col style="text-align:left;"/>
+<col style="text-align:left;"/>
+</colgroup>
+
+<thead>
+<tr>
+	<th style="text-align:left;">Browser</th>
+	<th style="text-align:left;"><code>srcset</code> support</th>
+</tr>
+</thead>
+
+<tbody>
+<tr>
+	<td style="text-align:left;">WebKit Nightly</td>
+	<td class="yes" style="text-align:left;">yes</td>
+</tr>
+<tr>
+	<td style="text-align:left;">Safari 7</td>
+	<td class="no" style="text-align:left;">no</td>
+</tr>
+<tr>
+	<td style="text-align:left;">Firefox 30</td>
+	<td class="no" style="text-align:left;">no</td>
+</tr>
+<tr>
+	<td style="text-align:left;">Chrome 34+</td>
+	<td class="yes" style="text-align:left;">yes</td>
+</tr>
+<tr>
+	<td style="text-align:left;">Opera 16</td>
+	<td class="no" style="text-align:left;">no</td>
+</tr>
+<tr>
+	<td style="text-align:left;">IE 11</td>
+	<td class="no" style="text-align:left;">no</td>
+</tr>
+<tr>
+	<td style="text-align:left;">Mobile Safari 7</td>
+	<td class="no" style="text-align:left;">no</td>
+</tr>
+<tr>
+	<td style="text-align:left;">Opera Mini 7</td>
+	<td class="no" style="text-align:left;">no</td>
+</tr>
+<tr>
+	<td style="text-align:left;">Opera Mobile 14</td>
+	<td class="no" style="text-align:left;">no</td>
+</tr>
+<tr>
+	<td style="text-align:left;">Android Default 4.2</td>
+	<td class="no" style="text-align:left;">no</td>
+</tr>
+<tr>
+	<td style="text-align:left;">Chrome for Android</td>
+	<td class="no" style="text-align:left;">no</td>
+</tr>
+<tr>
+	<td style="text-align:left;">Firefox for Android</td>
+	<td class="no" style="text-align:left;">no </td>
+</tr>
+</tbody>
+</table>
+</div>
+
+Yes, it's a slightly ridiculous table, <strike>but with any luck Chrome will be joining the list of <code>srcset</code> supporters in the very near future</strike>. [**Update 2014-02-27**: Chrome 34 and higher [now support](http://blog.chromium.org/2014/02/chrome-34-responsive-images-and_9316.html) `srcset`, which also means Opera will soon as well]. My contacts at Mozilla tell me that Firefox is also working on support. So things are looking pretty good for the future. That doesn't help today though, so if you need something now, remember to check out Nathan Ford's [Responsive Images Mega-List][1] for a complete collection of responsive image solutions that work today.
+
+[1]: http://artequalswork.com/posts/responsive-images/ (Responsive Images Mega-List)
+[2]: http://www.webmonkey.com/2012/05/ready-or-not-adaptive-image-solution-is-now-part-of-html/ (Ready or Not, Adaptive-Image Solution Is Now Part of HTML)
+[3]: http://www.webmonkey.com/2012/05/browsers-at-odds-with-web-developers-over-adaptive-images/ (Browsers at Odds With Web Developers Over 'Adaptive Images')
+[4]: http://mobile.smashingmagazine.com/2013/08/21/webkit-implements-srcset-and-why-its-a-good-thing/
+[5]: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0310.html
+[6]: http://futurefriend.ly/
+[7]: http://www.w3.org/html/wg/drafts/srcset/w3c-srcset/#processing-the-image-candidates
+[8]: http://nightly.webkit.org/
diff --git a/src/old-no-longer-pub/2013-11-08_easiest-way-get-started-designing-browser.txt b/src/old-no-longer-pub/2013-11-08_easiest-way-get-started-designing-browser.txt
new file mode 100644
index 0000000..f6b4b30
--- /dev/null
+++ b/src/old-no-longer-pub/2013-11-08_easiest-way-get-started-designing-browser.txt
@@ -0,0 +1,116 @@
+---
+title: The Easiest Way to Get Started 'Designing in the Browser'
+pub_date: 2013-11-08 16:02:19
+slug: /blog/2013/11/easiest-way-get-started-designing-browser
+metadesc: Developing and designing directly in the browser has greatly simplify my workflow. Skipping intermediary tools like Photoshop means I'm able to accomplish more in less time, which in turn means I can say yes to more projects.
+tags: Responsive Web Design, Building Smarter Workflows
+code: True
+tutorial: True
+
+---
+
+*If you've ever struggled to "design in the web browser" this post is for you.*
+
+You've probably heard that phrase before, "designing in the browser", especially when it comes to building responsive websites. Some people even go so far as to say you shouldn't use Photoshop at all, but should build everything right in the browser. 
+
+I think you should choose whatever tool works the best for you, but since I switched to developing directly in the browser a few years ago I've been able to greatly simplify my workflow. Skipping intermediary tools like Photoshop means I'm able to accomplish more in less time, which in turn means I can say yes to more projects.
+
+Sounds awesome right? But where do you start?
+
+## How to Simplify "Designing in the Browser"
+
+Start with the content. Get your content from the client, make your sketches, your wireframes, whatever other preliminary things are already part of your workflow. Then, when that's done, instead of opening Photoshop, Illustrator or other layout apps, you convert that content to HTML and start structuring it to match your wireframes.
+
+But how? I start up a web browser (I use Firefox), point it to my local mockup files (just HTML files in my project folder) and start editing. That's it; that's my workflow: edit, refresh; edit, refresh. It's simple and it makes the feedback loop of design and development immediate and simple. 
+
+And to do that I didn't spend hours setting up some complex development environment, nor did I have to buy some expensive GUI server software package. In fact, I use just one line of code to pull this off.
+
+Here's how you can simplify your responsive design workflow, and start "designing in the browser" with what I call "the Python web server trick". I've been doing this for so long I often assume everyone knows about this, but I keep meeting people who don't. So... if you don't, here's a dead simple way to serve files locally with just one line of code.
+
+## The Best Web Server is the One That's Already Installed
+
+The key to designing in the browser is to have **a quick and easy way to serve up files locally**. You don't need anything fancy at this stage, just a basic web server.
+
+The easiest way I have found to set up this workflow is to use a very simple command line tool that creates a web server wherever I want it, whenever I want it.
+
+I know, I know, the command line is antiquated, mysterious and a bit frightening for many people. I know that because it was that way for me too. But I kept noticing how much faster I could do things compared to visual apps. And I found that every time I used the terminal, it got a little less intimidating. I learned how to do one little thing that sped up my overall workflow. Then I learned another. And another. Today I use the terminal more than any other application. You don't have to go that far, but don't let it intimidate you. Just take it slow. Start with one thing that simplifies your life, like this web server trick.
+
+If you've ever tried to set up a local development environment with Apache, PHP and the like you probably know what a headache that can be. Well, it turns out, if all you want is a simple web server, there's a much easier way. 
+
+Here's how to **turn any local folder on your Mac or Linux machine into a web server** (Windows users can do the very same thing, though first you'll need to install Python. Follow [these instructions](http://www.anthonydebarros.com/2011/10/15/setting-up-python-in-windows-7/) to get Python installed and then come back and follow along).
+
+Before we start our web server we need a folder to hold all our files. This folder will be the "root" of our web server. I divide my time between OS X and Linux, which both offer a "Sites" folder in your home folder. I use this folder to store all my projects. If you prefer to store things elsewhere just adjust all the path names in the code that follow. Open the `Sites` folder and create a new folder inside it named `myproject`. Then create a new file named `mydemo.html`. Open that file in your favorite editor and just type "Hello World".
+
+That gives us something to test with. The next step is to open up your terminal application. In OS X that means you head to the `Applications` folder, open the `Utilities` folder and then double-click the Terminal application (Windows users head to the Start Menu, click Run and then type `cmd`; if you're on Linux I'll assume you know how to open a terminal window). In the new Terminal window type/paste this line:
+
+~~~.language-bash
+cd ~/Sites/myproject
+~~~
+
+The command `cd` just means "change directory". So we've changed from our home user folder to the `myproject` directory. Okay, you're now inside the folder we created just a minute ago. Now type this line:
+
+~~~.language-bash
+python -m SimpleHTTPServer 8080
+~~~
+
+Now open your favorite web browser and head to the URL: `localhost:8080/`. You should now see a directory listing with a link to your `mydemo.html` file. Click that and you should see "Hello World". Go back to your text editor and change the `mydemo.html` file to read "Hello World, it's nice to meet you". Jump back to the browser and reload the page. You should now see the message "Hello World, it's nice to meet you"
+
+Congratulations! You created a web server. You now have a simple and fast way to serve up HTML files locally. You can edit, refresh and mock up live HTML files right in the browser.
+
+All we're doing here is taking advantage of the fact that the [Python programming language](http://www.python.org/) ships with a built-in web server. Since Python is built into OS X and Linux, it's always there, ready to serve up files (as noted above, if you're on Windows you'll need to install Python. I also suggest installing [Cygwin](http://cygwin.com/), it will make everything you do on the command line easier).
+
+## Improving the Script
+
+So we have a very basic way to serve files locally. There are various ways to make this more sophisticated, but this basic method will work when you're first getting started. 
+
+If you don't mind another quick trip to the Terminal you can even automate the process some more. To make it even simpler we can add an alias to what's known as a "profile", the configuration file that loads every time we start up a new terminal window. Most operating systems these days ship with the [Bash shell](http://en.wikipedia.org/wiki/Bash_%28Unix_shell%29). Assuming that's what you have (OS X uses Bash by default, as do most Linux distros), open a new terminal window and type this:
+
+~~~.language-bash
+nano ~/.bash_profile
+~~~
+
+Now paste this line into the window:
+
+~~~.language-bash
+alias serve='cd ~/Sites/myproject && python -m SimpleHTTPServer 8080'
+~~~
+
+Hit `control-x`, type a "y" and hit return to save the file. Now quit your terminal app and restart it.
+
+Now to turn on the server all we need to do is open a new terminal window and type "serve". Note that if your folder is in a different location, or if you move the folder you'll need to adjust your alias accordingly.
+
+If you've got a home network running and you'd like to be able to see your website on all your devices (handy for testing on phones, tablets and whatnot), you can alter this code slightly so other local devices can connect to your server. It's a little more complicated, but can still be a one-liner. 
+
+For example, if your machine's local network address is 192.168.1.5, you could run this command:
+
+~~~.language-bash
+python -c "import BaseHTTPServer as bhs, SimpleHTTPServer as shs; bhs.HTTPServer(('192.168.1.5', 8080), shs.SimpleHTTPRequestHandler).serve_forever()"
+~~~
+
+Now, instead of `localhost`, open the URL `192.168.1.5:8080` in your web browser and you'll see the same page, but now you can point your phone to that URL and it will load there as well. Ditto your tablet, Kindle and any other devices connected to your local network. 
+
+Obviously that's tough to remember so let's create an alias. To do that we'll just add another alias to the .bash_profile file we edited earlier. To open that up again just enter:
+
+~~~.language-bash
+nano ~/.bash_profile
+~~~
+
+Now paste this line into the window:
+
+~~~.language-bash
+alias serve_all="python -c 'import BaseHTTPServer as bhs, SimpleHTTPServer as shs; bhs.HTTPServer(('\''192.168.1.5'\'', 8080), shs.SimpleHTTPRequestHandler).serve_forever()'"
+~~~
+
+Now you can `cd` into any directory, type `serve_all` and run a web server that you can use to testing your sites on any device.
+
+That's all there is to it. A live web server whenever you want it, wherever you want it.
+
+That's how I "design in the browser". 
+
+The next step is to take that nice content the client gave us and put it into our mockup files so we have something more useful than "Hello World" in our web browser. I do this using plain text files, [Markdown](http://daringfireball.net/projects/markdown/) and [Pandoc](http://johnmacfarlane.net/pandoc/), which I cover in more detail in this follow-up post: [Work Smarter: The Plain Text Workflow](/blog/2014/02/work-smarter-plain-text-workflow). 
+
+I hope this simple Python server trick proves helpful, and, if you have any questions, drop them in the comments below.
+
+If you want to learn some more handy tips and tricks for improving your responsive design workflows check out my book, [Build a Better Web With Responsive Web Design](https://longhandpixels.net/books/responsive-web-design) and the accompanying videos.
+
+
diff --git a/src/old-no-longer-pub/2014-02-02_work-smarter-plain-text-workflow.txt b/src/old-no-longer-pub/2014-02-02_work-smarter-plain-text-workflow.txt
new file mode 100644
index 0000000..551f195
--- /dev/null
+++ b/src/old-no-longer-pub/2014-02-02_work-smarter-plain-text-workflow.txt
@@ -0,0 +1,250 @@
+---
+title: "Work Smarter: The Plain Text Workflow"
+pub_date: 2014-02-02 19:37:07
+slug: /blog/2014/02/work-smarter-plain-text-workflow
+metadesc: A guide to smarter responsive design workflows. If you're still designing websites in Photoshop you're doing too much work. 
+tags: Responsive Web Design, Building Smarter Workflows
+code: True
+tutorial: True
+---
+
+*If you've ever struggled building responsive websites, this post is for you. It's part of a series on responsive design and smarter workflows, all pulled from my book, [Responsive Web Design](https://longhandpixels.net/books/responsive-web-design). If you find this excerpt useful, and want even more ideas on how responsive design can help you create amazing websites, sign up for the newsletter below and you'll get a discount when the book is released.*
+
+[TOC]
+
+If your current workflow looks anything like mine used to, you probably start most of your design work in a graphics editor like Photoshop. There's nothing "wrong" with that per say, nor is Photoshop some tool for evil, but I'm here to tell you there is a better, more productive way to work.
+
+Here's the thing: if you're designing websites in Photoshop you're doing too much work. 
+
+If you're building responsive websites and you're not working directly with the code in a web browser you're wasting time and energy using the wrong tool for the job. There's nothing wrong with Photoshop, but it's not the best tool for developing responsive websites.
+
+Why?
+
+Photoshop has a fixed canvas size; the web has an infinitely flexible canvas. Responsive design means embracing that flexible canvas and you can't do that when you're working in a graphics editor.
+
+The web browser is the only tool I know of that offers the same fluid, flexible canvas of the web. **If you want to simplify and optimize your responsive workflow, the place to work is in the browser**. 
+
+Designing in the browser means working with the web rather than against it, and that's the first step toward a simpler, faster responsive design workflow.
+
+##Faster, Easier Web Development? Sign Me Up!
+
+For a long time I ignored the advice to design in the browser because often the people giving it stopped with the advice. Go design in the browser! It's awesome! And, unicorns! Whereas I would just sit there thinking, *Uuuuuuuh, okay, but what the heck does that mean? Design in the browser...? Grumble, well, I've got work to do and I know how to use Photoshop...*
+
+Designing directly in the web browser makes sense at a theoretical level, but what does it mean in practical terms? What does this workflow look like and where do you start?
+
+That's why I wrote this, to outline how I finally figured out I could save tremendous time and effort working directly in the browser rather than prototyping everything in Photoshop. I'm going to share my workflow in hopes it will prove useful to you. 
+
+Before we dive in, realize that this is just my workflow. It's not THE workflow by any means. Whether you're part of a small team, large team or working on your own, you have your idiosyncrasies and tics to consider. A good workflow will work with, not against you. I can't tell you how you should work. I can, however, tell you how I work and hopefully that will give you some ideas you can test in your own workflow. Take what you need, skip what you don't.
+
+In the [first part of this responsive design workflow series](https://longhandpixels.net/blog/2013/11/easiest-way-get-started-designing-browser) we looked at a super simple way to serve files on our local development machines. After all, you can't design in the browser if you don't have a server for your web browser to talk to. So I'll assume you've completed that tutorial (or have your own web server setup already). 
+
+## Everything Starts with the Content
+
+The first thing to do with any tough question is to break it down into smaller questions. So instead of asking what does designing in the browser look like, let's start with a more basic question: What do we need before we can display a webpage?
+
+The simple answer is: the content.
+
+Before we can do anything with HTML or CSS we need the contents of our site. Everything starts with content. No content, no HTML. No HTML, no CSS. 
+
+The foundation of any design has to be the content. I know what you're thinking; you're thinking I'll just grab some Lorem Ipsum. Or, if you prefer some snarky for your dev work, [Samuel L. Ipsum](http://slipsum.com). But that's not going to cut it. 
+
+Without the content we're designing in the dark. I can't remember where I first saw a graphic like this, but it's what turned the light bulb on for me.... Simply put, there's no point in designing a layout with this:
+
+[![two plain lorem ipsum paragraphs](https://longhandpixels.net/media/images/2014/contentfirst1.png)](https://longhandpixels.net/media/images/2014/contentfirst1.png "View Image 1")
+: The content you think you're going to get.
+
+When what you're actually need to display looks like this:
+
+[![structurally complex content with lists, paragraphs and blockquotes](https://longhandpixels.net/media/images/2014/contentfirst2.png)](https://longhandpixels.net/media/images/2014/contentfirst1.png "View Image 2")
+: The content you actually got.
+
+
+As Jeffery Zeldman [writes](http://www.zeldman.com/2008/05/06/content-precedes-design/), "design in the absence of content is not design, it's decoration." We're not decorating websites, we're designing them, which means we need actual content.
+
+In terms of workflow, this means you need to get the content as soon as you can. No content, no work to flow. It means that when you're meeting with clients you need to emphasize the importance of having the actual content, not placeholders, but actual content. Without the content you can't make the client's vision a reality. You need real content to build real websites.
+
+If you're doing a redesign of existing content, you're all set, just dump the site using a tool like [curl](http://curl.haxx.se) or wget[^1] and then do a content inventory -- list all the contents and make a special note of any patterns, repeated content and outlier content you find.  
+
+Once you have the content you can move on to sketching and wireframing -- figuring out the structure of the pages and overall site. I tend to do this stage mostly on paper because I find that to be the fastest way to get my ideas recorded, but I've seen other developers who use iPads with styluses, mind mapping tools, even one who used spreadsheets to create wireframes (yeah, he was a little strange). 
+
+Once I have a good idea of the hierarchy and structure of the content on the site, I immediately jump into the browser and start working with live HTML. At this point I'm just stacking text and creating structure, there's no CSS yet.
+
+There are two necessary components in this workflow: the web server and the files.
+
+##Tool #1: The Web Server
+
+For the full details on how you can start a web server in any folder on your computer, see the first part of this series. To quickly recap where we left off, recall that we set up our example project in `~/Sites/myproject/`. We then open up our terminal application and type:
+
+~~~language-bash
+cd ~/Sites/myproject/ && serve
+~~~
+
+Assuming you set up the aliases outlined in the first post, this will start up a server in the `myproject` folder. Now point your browser to [http://localhost/:8080](http://localhost/:8080) and you should see a directory listing of... nothing! That's okay, the important thing is that we've got a server up and running. 
+
+Now we're ready to turn our content into actual HTML files.
+
+##Tool #2: Plain Text
+
+Up until now I've been using a phrase I don't particularly like -- "the content". That makes it sound like it's just a pile of stuff. But it's not. It's words, phrases, sentences, pitches, headlines, sub headlines, outlines, lists, tables, buttons, forms, charts, illustrations, images, videos. "The content" is generic, the contents of the site you're building are not. This isn't just semantics, it's your first clue in how to get your workflow in line with the web itself.
+
+Notice two that almost everything in that list is either text, an image or a video. 
+
+At its core this is what the web is made of -- text and images. This is why starting your work in a graphics editor doesn't make sense. The web is mostly text. Even fancy landing pages and ultra-slick web apps are ultimately about serving up text and images in the some way.
+
+And within that core, for most sites, "the content" is text. So when we're designing in the browser we'll start where the web does, with text. Then we'll add structure to that text. Then we can actually **design** pages optimized to display that structured text rather than just decorating some filler and hoping for the best.
+
+### The Power of Markdown
+
+Starting with just the text makes it much easier to see the structure of your content and mark it up accordingly. 
+
+To my mind the best way to markup your documents at this stage is to use John Gruber's [Markdown](http://daringfireball.net/projects/markdown/). Markdown is a text-to-HTML conversion tool which allows you to markup text using an easy-to-read, easy-to-write format and then convert it to structurally valid HTML. While it won't allow you to markup every thing you might need in the end, it's perfect for generating quick prototypes like this. You can read through the [Markdown documentation over on Daring Fireball](http://daringfireball.net/projects/markdown/syntax).
+
+Best of all the syntax of Markdown is extremely simple, you can pick it up in an afternoon and reach the level of mastery we need in a day or two. 
+
+To markup our content we'd just dive into our plain text files and add a bit of structure. Let's say you had some text that looks like this:
+
+~~~{language-markup}
+Acme Widgets
+
+We're Awesome Widget Makers
+
+Crank your widgets faster with ACME Widgets
+
+Our Widgets are the best in the business. You can rely on ACME widgets day in and day out. The toughest, most dependable widgets out there.
+
+What can ACME Widgets do for you?
+
+We can help you build better subwidgets
+We can make you life widgetier
+We can solve all your widget headaches
+~~~
+
+Let's use Markdown to add some structure. The result might look something like this:
+
+~~~language-markup
+#We're Awesome Widget Makers
+
+##Crank your widgets faster with ACME Widgets
+
+Our Widgets are the best in the business. You can rely on ACME widgets day in and day out. The toughest, most dependable widgets out there.
+
+###What can ACME Widgets do for you?
+
+* We can help you build better subwidgets
+* We can make your life widgetier
+* We can solve all your widget headaches
+~~~
+
+You can refer to the [Markdown docs](http://daringfireball.net/projects/markdown/syntax) for more details on the syntax, but the main thing to know is that `#` will be converted to `<h1>`, `##` to `<h2>` and so on. The asterisks denote an unordered list. The sentences in the middle will automatically be wrapped in `<p>` tags. We've added structure to the text, but kept things readable. 
+
+Why bother? Why not go straight to HTML? Well, in this case the content is simple enough that sure, you might as well, but with much more complex, real-world content marking everything up in pure HTML is going to make it very difficult to read. Remember, this is the prototyping stage, things will be changing and you'll likely need to edit, rearrange and change your content many times. The more readable it is, the easier it is to make those structural changes.
+
+### Tools for Converting to Plain Text
+
+Unfortunately, it's rare that a client gives you plain text files. Most clients deliver content in MS Word files or PDFs or something even stranger. I had one client who sent over all their content as a series of PowerPoint presentations. 
+
+The good news is that almost any files can be reduced to plain text. Regardless of how the client delivers the content, I convert it to plain text. For Word files I just open and save as plain text. That won't preserve any formatting, but you can keep the original around just to make sure you get the hierarchy and structure right. 
+
+For PDFs I use a tool called [pdftotext](http://www.foolabs.com/xpdf/download.html). OS X users can grab a handy installer from [Carsten Blüm](http://www.bluem.net/en/mac/packages/). There are also numerous free online PDF-to-text converters, as well as OCR software available. If the client hands you content in PowerPoint slides you can open it in PowerPoint, save it as a Rich Text document and then open the Rich Text document in TextEdit or similar and save as plain text.
+
+The point is to get your content in plain text form. 
+
+### Pandoc for Fame and Fortune
+
+The next step is to convert our Markdown-formatted file into an HTML file we can view in the browser using the server we set up above. There's a nearly unlimited number of ways we can convert from Markdown to actual HTML, but my favorite is [Pandoc](http://johnmacfarlane.net/pandoc/).
+
+Installing Pandoc is simple, just head over to the [Pandoc download page](http://code.google.com/p/pandoc/downloads/list) and grab the installer for your platform (for OS X grab the .dmg file, for Windows grab the .msi). Then double click the installer and follow the directions. 
+
+Once you have Pandoc installed you just need to run it on your markdown files. To do that fire up a terminal application. On OS X that would be Applications >> Utilities >> Terminal. On Windows you'll need [Cygwin](http://x.cygwin.com).
+
+I know, the command line is antiquated, mysterious and a bit frightening for many people. 
+
+I know that because it was that way for me too. But I kept noticing how much faster I could do things compared to visual apps. And I found that every time I used the terminal, it got a little less intimidating. I learned how to do one little thing that sped up my overall workflow. Then I learned another. And another. Today I use the terminal more than any other application. You don't have to go that far, but don't let it intimidate you. Just take it slow. Start with one thing that simplifies your life, like [the web server trick](https://longhandpixels.net/blog/2013/11/easiest-way-get-started-designing-browser). 
+
+With that one already under your belt you're ready for Pandoc.
+
+Open your terminal and navigate to your project folder. To stick with the previous tutorial in this series we'll say our project files are in `~/Sites/myproject`:
+
+~~~{.language-bash}
+cd ~/Sites/myproject
+~~~
+
+Now that we're in the right directory we just need to invoke Pandoc:
+
+~~~{.language-bash}
+pandoc -s --smart -t html5 -o about.html about.txt
+~~~
+
+This line says, take the file `about.txt`, convert it from Markdown to HTML5 (that's the `-t html5` bit) and save the results in a new file named `about.html`. The `-s` flag at the beginning of the line tells Pandoc that we want this to be a standalone conversion, which means Pandoc will add `<html>`, `<head>`, `<body>` and a few other tags so that we have an actual valid HTML file rather than just a fragment of HTML. Pandoc even adds a link to the [HTML5shiv](https://code.google.com/p/html5shiv/) for IE. 
+
+The `--smart` flag turns on one little extra feature that converts straight quotes to actual or curly quotes. 
+
+Point your web browser to <http://localhost:8080/about.html> and you should see the results. View source and you'll notice that Pandoc has done a bunch of stuff:
+
+~~~language-markup
+<!DOCTYPE html>
+<html>
+<head>
+    <meta charset="utf-8">
+    <meta name="generator" content="pandoc">
+    <title></title>
+    <style type="text/css">code{white-space: pre;}</style>
+    <!--[if lt IE 9]>
+    <script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>
+    <![endif]-->
+</head>
+<body>
+    <h1 id="were-awesome-widget-makers">We're Awesome Widget Makers</h1>
+    <h2 id="crank-your-widgets-faster-with-acme-widgets">Crank your widgets faster with ACME Widgets</h2>
+    <p>Our Widgets are the best in the business. You can rely on ACME widgets day in and day out. The toughest, most dependable widgets out there.</p>
+    <h3 id="what-can-acme-widgets-do-for-you">What can ACME Widgets do for you?</h3>
+    <ul>
+        <li>We can help you build better subwidgets</li>
+        <li>We can make your life widgetier</li>
+        <li>We can solve all your widget headaches</li>
+    </ul>
+</body>
+</html>
+~~~
+Pandoc has converted all our Markdown formatting into actual HTML. Our hashes change to header tags and our list gets marked up as an unordered list. Don't worry too much about the IDs and all the header elements. That can be changed or deleted when you move to working with templates in an actual content management system. 
+
+As you can see we have a nicely structured HTML file which can serve as the basis of our templates or undergo further editing to add things like a site-wide navigation menu, header, logo and the like. 
+
+Hmm. Maybe that list at the end should be an ordered list (probably not, but for example's sake, go with me here). Well, that's easy to change. Just open up the `about.txt` files and change the markdown to look like this:
+
+~~~language-markup
+#We're Awesome Widget Makers
+
+##Crank your widgets faster with ACME Widgets
+
+Our Widgets are the best in the business. You can rely on ACME widgets day in and day out. The toughest, most dependable widgets out there.
+
+###What can ACME Widgets do for you?
+
+1. We can help you build better subwidgets
+2. We can make you life widgetier
+3. We can solve all your widget headaches
+~~~
+
+Run the same Pandoc command (**tip**: if you hit the up arrow in your terminal app it will bring up the last used command. Assuming you've done nothing else in the mean time, that will be the Pandoc command we ran before). 
+
+Refresh your browser and you should see that the list of things ACME widgets can do for you is now an ordered list. Hmm, maybe that header should be an H2? Maybe the client just called, they're sending over some updates for the page. None of that's a problem any more, you just update your text file, run Pandoc and see the results. Simple.
+
+## Further
+
+So far we've established a very basic, but fast workflow. We take our client provided content, convert it to text and with just two lines of code create HTML files and serve them locally for prototyping and structuring.
+
+All this does is give you quick and dirty HTML you can use for prototyping. Why is that useful?
+
+As Stephen Hay has [said repeatedly](http://www.the-haystack.com/) (and [written a book about](http://www.responsivedesignworkflow.com/), which you should read), starting with raw, unstyled HTML forces you to focus and prioritize. Hay suggests asking yourself, "what is the message that needs to be communicated if I was only able to provide them with unstyled HTML?" Start there, with the content -- the most important content -- and design everything around that.
+
+We've got that basic unstyled HTML. What if you want to get a little bit fancier with Pandoc? Well, you certainly can. I do. 
+
+In the next installment in this series we'll look at some advanced ways to use Pandoc including customizing the HTML template it uses, adding site-wide elements like navigation, headers and footers, as well as the part most designers all waiting for -- adding an actual stylesheet. 
+
+So stay tuned. In the mean time, you can head over the [Pandoc documentation](http://johnmacfarlane.net/pandoc/README.html) if you'd like to get a head start.
+
+[^1]: If you prefer a graphical download check out [Sitesucker](http://www.sitesucker.us/mac/mac.html) for OS X or [HTTrack](http://www.httrack.com) for Windows
+
+If you want to learn some more handy tips and tricks for improving your responsive design workflows, I'm writing a book to teach you exactly that (and a whole lot more). Sign up for the mailing list below to hear more about the book and get a discount when it's released.
+
diff --git a/src/old-no-longer-pub/2014-02-12_what-is-responsive-web-design.txt b/src/old-no-longer-pub/2014-02-12_what-is-responsive-web-design.txt
new file mode 100644
index 0000000..9d63bf5
--- /dev/null
+++ b/src/old-no-longer-pub/2014-02-12_what-is-responsive-web-design.txt
@@ -0,0 +1,75 @@
+---
+title: What is Responsive Web Design?
+pub_date: 2014-02-12 12:04:25
+slug: /blog/2014/02/what-is-responsive-web-design
+metadesc: A gentle introduction to responsive web design... hint, it's more than flexible sites with some media queries
+tags: Responsive Web Design
+
+---
+
+[*Note: This is an excerpt from my book, [Build a Better Web With Responsive Web Design](https://longhandpixels.net/books/responsive-web-design). This starts out pretty simple, but even if you're already familiar with the basic concept of responsive design you might learn a few new things. My definition of responsive web design is very braod, encompassing ideas like taking a mobile-first approach and using progressive enhancement to make sure you responsive web site works everywhere.*]
+
+The phrase responsive design was coined by Ethan Marcotte in 2009 in an *A List Apart* article, entitled, appropriately enough, *[Responsive Web Design](http://www.alistapart.com/articles/responsive-web-design/)*. At the most basic level Marcotte used the phrase to mean building websites that respond to users' needs.
+
+The specific case Marcotte wrote about was making websites flow into different layouts for a variety of screens, especially mobile. When Marcotte's article first appeared in 2009 the iPhone was just starting to be truly ubiquitous. Clients were asking for "iPhone websites". But it wasn't just the iPhone, the handheld device market was just about to explode. There was a fear that the web would devolve into a multitude of separate websites, each tailored to a specific device, which, as Marcotte and others recognized, would be insane.
+
+As Marcotte writes "can we really continue to commit to supporting each new user agent with its own bespoke experience? At some point, this starts to feel like a zero sum game. But how can we -- and our designs -- adapt?"
+
+The answer was two-fold. First there were some new tools available to help us out, namely the @media query in CSS 3. Then there was the second and more powerful part, which meant going back to the web's origins and rediscovering something many of us lost along the way -- the web is an inherently flexible medium.
+
+In practice responsive design means creating websites that look good no matter which screen they might be on. Building a responsive website means making sure that the site is easy to read and navigate with a minimum of resizing, scrolling or panning. Building a responsive website means building a site your users and customers will recognize and enjoy regardless of which device they might be using -- mobile phone, tablet, laptop, desktop or even the internet enabled toaster of the future.
+
+![Marcotte's original responsive demo site, shown here at roughly phone, tablet and desktop sizes](images/marcotte-demo.png)
+
+It sounds wonderful at first blush -- who doesn't want their website to look great and work well on any screen? Even those we don't know about yet? Stop and think about it for a bit though and suddenly responsive design starts to sound unfathomably complex. 
+
+How in the world do you make your site look good no matter where it's being served up -- phone, tablet, ebook reader, laptop, desktop and more?
+
+To complicate matters even those nice clean divisions -- mobile, tablet and desktop -- are fast disappearing. There are phones with tablet-like 7-inch HD screens, desktop-size monitors that run Android 4.0 and hybrid devices like Ubuntu's mobile OS which can dock to a monitor -- is that mobile? Is it a desktop? What if the answer to both questions is yes?
+
+Also consider that the "screens" of the future might not be screens at all. Google Glass is already in the wild and while it's still a "screen" of sorts, it's certainly different from what most of us are used to. Several years ago Microsoft showed off a prototype projection device dubbed the "OmniTouch" which essentially put the "screen" anywhere -- the desk in front of you, the wall during a presentation, your hand, anywhere. Other, somewhat more likely to actually make it to market "screens" include "smart" glass for windows, that can can pull all sort of tricks, including turning opaque to become a display. At the other end of the spectrum Sony is hard at work on displays that behave like and are no thicker than a single sheet of paper.
+
+![Google glasses. Say what you will, they're out there and they want to load your site. <small>Image credit: Giuseppe Costantino, [CC/Flickr](http://www.flickr.com/photos/69730904@N03/8813574238/).</small>](images/google-glass.png)
+
+Some of these ideas will become part of our reality, some will not. Other ideas we can't even imagine right now will also be created. 
+
+The "screen" of the future might be your sunglasses, your hand, the back of the seat in front of you on the bus or the window by your bed when you wake up in the morning. Which of these is mobile, which is a tablet and which is a desktop? To build a future-proof web we need to stop focusing so heavily on individual devices, yes, but why stop there? While we're at it we might as well get rid of the notion of device categories as well since the hardware has already started doing exactly that. In the end even thinking of "screens" will soon seem antiquated. For this reason most web standards rarely use the word "screen", opting instead to talk about "viewports". 
+
+Ultimately it makes no sense to frame our discussions by device type or even context. All of these devices, these screens, these viewports, these *things* are just portals into the world of the web. The more portals that can see into the web the more people you can bring into your world. 
+
+The future of the web is a chaos and confusion of portals. Building a tricked out site for each of them is an insane idea today and it will be even more insane two years, five years, twenty years from now.
+
+So what do we do? Well, we could wait and see. Keep building sites that target individual devices until we collapse under the weight of the work (or price ourselves out of anything clients would be willing to pay). Or we can take what developers like Brad Frost call a "future-friendly" approach. That is, we can do the best we can with the tools we have available today and make decisions on which tools to use based on which are the most likely to work in the future. 
+
+Let's step back in time for a minute to 2007 and consider the developer's dilemma when the iPhone first launched. You need to embed a movie in your page. The do-nothing approach would dictate you just embed a Flash player and call it a day. No Flash? Too bad. Apple will come around because, well, everyone has Flash. Except that we all know how that turned out.
+
+If instead we took a more future-friendly approach we might embed the movie using HTML5's video tag, while offering a Flash fallback for browsers that don't support modern web standards. This would have meant a bit more work at the time since there's a bit more code to write and we would have had to figure out exactly how to do it. 
+
+But the easier, "do-nothing" approach would have meant more work down the road when you had to convert your site to HTML5 video anyway since even Adobe has abandoned the idea of including Flash on mobile devices.
+
+What can we learn from this little example? Well, first and foremost we need to embrace solutions that work today. There's no point in designing *only* for the future. In this case going with only HTML5 video tags would probably have been a bad choice; in 2007 you still needed a Flash-based fallback. 
+
+We need to make our sites work well with the web as it is, but we should also keep an ear cocked toward the future and embrace those tools and design patterns that are most likely to work with the devices of the future as well. Brad Frost put it quite well when he said, "We don't know what will be under Christmas trees two years from now, but that's what we need to design for today."
+
+Right now that means using the responsive design tools and best practices that follow to build websites. 
+
+Let's start with the three basic tools of responsive design -- fluid layouts, media queries and flexible media. 
+
+*   *Fluid Layouts*: By defining our content grids in mathematical proportions rather than pixels our content will fit any screen. So instead of having a 750px main column and a 250px sidebar, the columns would be defined as 75% and 25% respectively.
+*    *Media Queries*: Media queries are a CSS feature that allow styles to be applied conditionally, based on criteria such as screen width and pixel density. With as little as 3 or 4 lines of code you can resize your entire website and re-flow content to fit different screen sizes.
+*    *Flexible Media*: Dimensions of images, video, and animations should be flexible and adapt to suit different screen sizes similar to how grids should be fluid.
+            
+To these three core principles of responsive design I am adding two more -- mobile-first design and progressive enhancement.
+
+*   *Mobile-first Design*: Start by making sure your site and its content work on the least capable devices your visitors are using. By all means build as fancy and JavaScripty of a site as you want; just do it on basic, solid foundations.
+*   *Progressive Enhancement*: Don't *stop* with that most basic version of your site; start there. Then layer in complexity and more advanced features for more capable devices, progressively enhancing it as the devices become more capable.
+
+That may sound like a lot of stuff to keep track of, but guess how many of the things in this list are actually new? 
+
+Just one, @media queries. Everything else is almost as old as the web. That means you don't really have to learn anything new, you just need to shift your approach in some subtle, but profound ways.
+
+Implementing responsive design is simple, but, as they say, the devil is in the details.
+
+That's where this book comes in. You bought this book, which means you're open to new ideas and new workflows. That's good because I'm going to challenge some long-held assumptions behind many of the sites you've probably built. I'm also going to tell you that, most likely, you've been doing it wrong, as they say. That's okay, I did it wrong for years too. Sure the sites we built worked, after all the biggest challenge we had was making things work in IE 6. And work they did, but we were still working from flawed premises and it's time to change that.
+
+It's time to step back from our toolkits and workflows and question everything because those fixed width sites designed for desktop screens don't work well on smartphones and probably don't work at all on feature phones. They probably won't look all that great in Google Glass or projected directly onto your retina either. As William Gibson said, the future is already here, it's just unevenly distributed. And that's what we need to develop, websites and web apps capable of handling the uneven distribution of the future.
diff --git a/src/old-no-longer-pub/2014-02-19_complete-guide-picture-element.txt b/src/old-no-longer-pub/2014-02-19_complete-guide-picture-element.txt
new file mode 100644
index 0000000..8f1c18b
--- /dev/null
+++ b/src/old-no-longer-pub/2014-02-19_complete-guide-picture-element.txt
@@ -0,0 +1,235 @@
+---
+title: A Complete Guide to the `<Picture>` Element
+pub_date: 2014-02-19 09:30:23
+slug: /blog/2014/02/complete-guide-picture-element
+tags: Responsive Images, Responsive Web Design
+metadesc: Everything you ever wanted to know about the proposed <picture> element. Just don't use it quite yet.
+code: True
+tutorial: True
+
+---
+
+*If you've ever struggled building responsive websites, this post is for you. It's part of a series on responsive design, in particular responsive images, pulled from my book, [Responsive Web Design](https://longhandpixels.net/books/responsive-web-design). If you find this excerpt useful, and want even more ideas on how responsive design can help you create amazing websites, pick up a copy today.*
+
+[**Last Update: 08/20/2014**]
+
+I also wrote up the back story of the `<picture>` element and all the hard work that made it possible for Ars Technica. If you want to know not just how to use it, but how a small group of people created it, be sure to <a href="http://arstechnica.com/information-technology/2014/09/how-a-new-html-element-will-make-the-web-faster/" rel="me">check that out</a> as well.
+
+[TOC]
+
+Most people who've never heard the phrase before think that "responsive design" refers to building websites that are, well, responsive. That is, fast pages that respond to user input with no lag or discernible load times.
+
+Of course that's not exactly what the phrase "responsive design" refers to in most web development contexts, but I think the web might be better off if it were. I don't think we need to throw out Ethan Marcotte's original definition of responsive design -- fluid grids, flexible images and @media queries -- but perhaps we could add another criteria to our definition: responsive websites should, above all else, be **really, really fast**.
+
+There are many, many ways to speed up websites, responsive or otherwise, but few things will lighten the load like reducing image size. If you've done nothing yet to optimize the front-end portion of your site, images are almost always the best place to start. Even without responsive images, I managed to shave several seconds off this site's load time using some very simple, basic optimizations.
+
+Nothing, however, is going to speed up mobile page load times like responsive images. And the good news is, thanks to a lot of hard work from some deditcated developers,  responsive images are here.
+
+## The `<picture>` Element
+
+Following the development of `<picture>` was a bit like listening to [Statler and Waldorf](https://en.wikipedia.org/wiki/Statler_and_Waldorf) in the [balcony of the Muppet's theatre](http://www.youtube.com/watch?v=NpYEJx7PkWE): "I love it!" "It's terrible!" "It's brilliant!" "It's okay" "It could be better" "It's awful!" "I love it!" And so on as developers and browser makers hashed out the details.
+
+In short, it was a soap opera. But in the end sanity prevailed and it got done. We have a draft specification for a new HTML element -- `<picture>`.
+
+As of right now `<picture>` is available in the dev channel of Chrome and in Firefox 34+. In both cases you'll need to enable it. In Firefox, head to `about:config` and search for "dom.image.picture.enabled". In Chrome you'll need to go to [chrome://flags/#enable-experimental-web-platform-features](chrome://flags/#enable-experimental-web-platform-features), enable that feature and restart.
+
+By the end of the year `<picture>` support should be on by default in the stable versions of both Chrome and Firefox. More importantly for those of us taking a mobile-first approach to development, `<picture.` support will be available in the mobile versions as well.
+
+What about other browsers? Opera is based on Blink and will support `<picture>` (hopefully) when Chrome does. Apple's Safari supports the `srcset` portion of `picture`, which we'll discuss in a minute. WebKit, which powers Safari, will soon have support for the rest of picture, but Apple won't likely ship it in Safari until the next major update. According to Microsoft's new [Status.Modern.IE](http://status.modern.ie/pictureelement) site, `<picture>` support is "under consideration" for a future release. 
+
+Fortunately for us, browsers that don't understand `<picture>` have a fallback -- the good old `<img>` element.
+
+That means there's nothing to stop you from using `<picture>` right now. If you need a solution that works everywhere right now, there's PictureFill, a JavaScript based polyfill, but it requires JavaScript, which may not be right for every solution. On the plus side, PictureFill only kicks in when the browser doesn't have native support. Personally, I'm going ahead with straight `picture` for most clients. 
+
+## Digging Into Picture
+
+The `<picture>` element looks a bit like the HTML5 `<audio>` and `<video>` tags. The actual `<picture>` tag acts as a container element for `<source>` elements which then points to the actual images you want to load. 
+
+The big difference is that `<picture>` doesn't actually load your image. For that you need an `<img>` tag. So the browser evaluates all the various attributes you've specified in your `<picture>` block, picks the best image and then loads the image into the `<img>` inside your `<picture>` tag. 
+
+In other words, `<picture>` doesn't actually display your image, it just tells the browser which image to display. Think of it as a way to filter possibilities for the `img` tag inside it.
+
+To help the browser pick the best image you have three major components to work with, all attributes of `<source>` elements within the `<picture>` tag, except for `srcset`, which can be an attribute of image as well.
+
+The three attributes are: 
+
+* `srcset`: Yes, the same `srcset` that was [originally proposed for the `<img>` tag](https://longhandpixels.net/blog/2013/09/responsive-images-srcset). The `srcset` attribute gives the browser a list of possible images, along with some (optional) "hints" about the screen resolution and screen size that correspond with each image source.
+
+* `media`: The `media` attribute is where you would put your `@media` query information. When the `@media` attribute evaluates to true, the browser then moves to the associated `srcset`.
+
+* `sizes`: The `sizes` attribute allows you to specify a set of intrinsic sizes for the images described in the srcset attribute. This one is a little tricky at first, but basically it allows you to tell the browser how much of the viewport should be taken up by the image. This will become clearer in the example below.
+{^ .list--indented }
+
+To get a better understanding of how each attribute works, let's dive into some code.
+
+## Using the `<picture>` Element for High Resolution Images
+
+Let's start with the first use case in the [responsive images use case list](http://usecases.responsiveimages.org): "[resolution-based selection](http://usecases.responsiveimages.org/#resolution-based-selection)". Essentially we want to serve high-resolution images to high-res devices while allowing low-res devices to avoid the bandwidth penalty of overly-large files.
+
+Here's how you would use `<picture>` to give Hi-DPI screens high-res images and regular screens regular images. 
+
+Let's say we're trying to build a more responsive version of my [Responsive Web Design book page](/books/responsive-web-design). Let's say we have two book cover images -- `cover1x.jpg`, which is a normal resolution image, and `cover2x.jpg` which is the same image, but at a much higher resolution. 
+
+Let's go ahead and make things [future-friendly](http://futurefriendlyweb.com) by adding a third image, `cover4x.jpg`, to handle those 4K+ monitors that are just a few years away from being on every desktop. So with three images at three resolutions our `<picture>` code would look like this:
+
+~~~{.language-markup}
+<picture>
+    <source srcset="cover1x.jpg 1x, cover2x.jpg 2x, cover4x.jpg 4x">
+    <img src="cover1x.jpg" alt="Responsive Web Design cover">
+</picture>
+~~~
+
+Here we have a simple `<picture>` tag with one `<source>` tag and an `<img>` tag which doubles as a fall back for older browsers. Within the `<source>` tag we've used the `srcset` attribute to say to the browser (or "user-agent" in spec-speak) if the screen pixel density is 1x then load `cover1x.jpg`; if the screen density is 2x then load the higher-resolution `cover2x.jpg`. Finally, if the screen density is 4x, grab `cover4x.jpg`. 
+
+What happens if the resolution is somewhere in between these values? Well, you could add in other resolutions (e.g. 1.3x, 1.6x and so on) and URLs if you want to be explicit. Remember though that which image to choose is entirely up to the browser. The `srcset` values we've given are described in the spec as "hints". It may be that, despite having a high-res screen, the user has explicitly instructed the browser (through a preference setting) not to download large images over 3G. 
+
+Screen resolution is after all just one factor in deciding on the appropriate image to download. As developers we don't (and never will) have all the information that the browser does, which is why the final decision lies with the browser. As I've said before, this is a good thing; this is exactly the way it should be.
+
+Here's the our resolution-based query in action. Provided you're got a high-res display and are running a browser with `<picture>` support this should display the high-res image:
+
+<picture>
+    <source srcset="/media/images/demos/srcsetdemo-2x.jpg 2x" />
+    <img src="/media/images/demos/srcsetdemo-fallback.jpg" alt="demo of srcset in action" />
+</picture>
+
+That's how you would handle the simple resolution-based selection scenario. Before we move on though, let's look at another value you can add to `srcset` declarations: width. 
+
+Consider this scenario: we have roughly the same situation, we'll limit it to two images this time, one high-res, one not. But we don't know how wide the image is going to be on the user's screen. Say our normal-res image is 640px wide. On a high-res screen that happens to be only 320 effective pixels wide, a 640px image would actually qualify as a high-res image. The situation is slightly more nuanced than a simple 1x vs 2x screen. To always send the larger image to 2x screens might still waste bandwidth because we're not accounting for the size of the screen/image.
+
+Here's how you can handle this scenario with `<picture>`. Let's stick with the same assumptions in the last scenario, but let's be a little more specific this time, `cover1x.jpg` is 640px wide and `cover2x.jpg` is 1280px wide. Here's what the code would look like:
+
+~~~{.language-markup}
+<picture>
+    <source sizes="100%" srcset="cover1x.jpg 640w, cover2x.jpg 1280w">
+    <img src="cover1x.jpg" alt="Responsive Web Design cover">
+</picture>
+~~~
+
+Now our `srcset` values are based on width and the browser gets to select the best image based on another `<source>` attribute,  `sizes`. In this case we've told the browser that final image selected will be as wide as the entire viewport. Later we'll see how you can use this with other values.
+
+The final result will be as wide as the viewport, so if the user is on a device that is effectively 320px wide, but at 2x density the browser would, barring other conflicting info like user settings, pick `cover1.jpg`. If the user's viewport happened to be 640px wide, but the density was only 1x, `cover1.jpg` would again be used. On the other hand if the viewport happened to be 640px wide, but the density was 2x, `cover2.jpg` would be used.
+
+## Different Image Sizes Based on Viewport Width
+
+When you think of responsive images, this is probably the use case you think of -- serving smaller images to smaller screens, larger ones to larger screens. Later we'll see how you can combine this with the pixel density stuff above for even more control.
+
+First, here's how `<picture>` can be used to serve up different images based on viewport width. 
+
+For the following examples, let's say we have three images, `small.jpg`, `medium.jpg` and `large.jpg` and we want to serve them to the corresponding viewport sizes. Let's make one more assumption: that we're taking a mobile-first approach and our fallback will also be the smallest image.
+
+Here's what that code would look like:
+
+~~~{.language-markup}
+<picture>
+    <source media="(min-width: 45em)" srcset="large.jpg">
+    <source media="(min-width: 18em)" srcset="medium.jpg">
+    <img src="small.jpg" alt="Robert Anton Wilson laughing">
+</picture>
+~~~
+
+This time we've used the `media` attribute to write a couple queries that work just like CSS `@media` queries. Our mobile-first approach here means any viewport larger than 45em gets `large.jpg`, any viewport between 18em and 45em gets `medium.jpg` and anything smaller than 18em gets our `small.jpg`. 
+
+Notice that here our smaller image is in the `<img>` tag, not a `<source>` tag. While we could add a third `<source>` tag with a srcset pointing to `small.jpg`, there's no need to do that since, as I mentioned earlier, `<picture>` and `<source>` are not the tags that actually load images. The `<picture>` element must contain an `<img>` element for the browser to actually display your image. Browsers that understand `<picture>` will first parse through all your rules, pick an image and then swap that image into the `src` attribute on the `<img>` tag.
+
+In this example not only is the `<img>` tag a fallback for older browsers, its `src` value also becomes the image used by `<picture>` savvy browsers if neither media query evaluates to true.
+
+Here's the above example in action (wrapped in a figure tag)
+
+<figure>
+<picture>
+    <source media="(min-width: 45em)" srcset="/media/images/2014/wilson-large.jpg">
+    <source media="(min-width: 28em)" srcset="/media/images/2014/wilson-medium.jpg">
+    <img src="/media/images/2014/wilson-small.jpg" alt="Robert Anton Wilson laughing">
+</picture>
+<figcaption>Robert Anton Wilson. Image from Wikicommons</figcaption>
+</figure>
+
+## Different Image Size and Resolution Based on Viewport Width
+
+Now let's combine both of the previous examples and use `<picture>` to serve up different size and resolution images based on viewport width and device pixel density. To do that we'll need six images -- `small.jpg`, `small-hd.jpg`, `medium.jpg`, `medium-hd.jpg`, `.large.jpg` and `large-hd.jpg` (side note: in the future you'll want a CMS that's good at generating tons of image options from the one you actually upload. Otherwise, plan on going insane while resizing images in Photoshop).
+
+Okay, let's put all those images into a `<picture>` tag:
+
+~~~{.language-markup}
+<picture>
+    <source media="(min-width: 45em)" srcset="large.jpg, large-hd.jpg 2x">
+    <source media="(min-width: 18em)" srcset="medium.jpg, medium-hd.jpg 2x">
+    <source srcset="small.jpg, small-hd.jpg 2x">
+    <img src="small.jpg" alt="Robert Anton Wilson laughing" >
+</picture>
+~~~
+
+This looks just like the previous example except that now our `scrset` includes a second image and the 2x value to indicate that our `-hd.jpg` images are for high resolution screens. 
+
+Also note that this time we did use a third `<source>` tag since small screen devices may still be high resolution. That is, while we don't need a media attribute, we do want to check the resolution, which requires a third `<source>` tag.
+
+## Solving the Art Direction Conundrum
+
+Here's a common responsive design problem: You have an image that, at full size on large screens, easily conveys its information. However, when that image is scaled down to fit on a small screen it becomes difficult to understand the image. For example consider an image of the president shaking hands with Robert Anton Wilson. At full size the image might show both men and some background, but when shrunk down you would barely be able to make out that it's two men shaking hands, let alone have any clue who the men might be. 
+
+In situations like this it makes sense to crop the image rather than just scaling it down. In the example above that might mean cropping the image to be just the President and Robert Anton Wilson's heads. You no longer know they're shaking hands, but most of the time it's more important to know who they are than what they're doing.
+
+Frankly, handling this scenario is really more a problem for your CMS than the `<picture>` element. But assuming you have a way to generate the cropped image (or images if you're doing both normal and high-res) then the code would look something like this:
+
+~~~{.language-markup}
+<picture>
+    <source media="(min-width: 45em)" srcset="original.jpg, original-hd.jpg 2x">
+    <source media="(min-width: 18em)" srcset="cropped-medium.jpg, cropped-medium-hd.jpg 2x">
+    <source srcset="cropped-small.jpg, cropped-small-hd.jpg 2x">
+    <img src="cropped-small.jpg" alt="The President shaking hands with Robert Anton Wilson" >
+</picture>
+~~~
+
+Here we're assuming there are two crops that make sense for the viewports they're targeting. In this case that means a crop that fits viewports between 18em and 45em and another (presumably tighter) crop for smaller screens. We're also assuming we have both regular and high-resolution versions of the image.
+
+See what I mean about having a CMS that makes it really easy to generate a ton of different images from a single source? Having to do something like this by hand would suck for even the smallest of blogs.
+
+There are other possible scenarios that fit the art direction problem, for example, providing a black and white version of a color pie chart for monochrome screens.
+
+## Handling More Complex Scenarios
+
+So far we've looked at pretty easy-to-grok scenarios using `<picture>`, but the new element addresses some more complex situations as well. For example, we might have a responsive layout where images morph depending on viewport width (and thus there may not always be a one-to-one correlation between viewport width and image size). 
+
+The `<picture>` element can handle this scenario as well, but this where the syntax starts to get, well, things can get complicated (as things tend to do when you want them to be very flexible).
+
+Imagine you have a storefront with three breakpoints, one for phone-ish devices, another for tablet-ish and a desktop layout. You build the site using a mobile-first approach, so you start with a single-column layout with images that span the full width of the viewport. At the first breakpoint the images switch to a two-column layout and may be a bit smaller than the full-width, single-column images just before the breakpoint (even though the viewport is larger now). Finally, on the larger layout the images move to a three-column grid and start off at the same size as the two-column layout but then scale up to be as large or larger than the images in the single-column layout.
+
+[![Illustration of scenario where image size does not necessary correspond to viewport](https://longhandpixels.net/media/images/2014/picture_element_illustration.png)](https://longhandpixels.net/media/images/2014/picture_element_illustration.png "View Image 1")
+: The very common image grid scenario. In this example we're using a single column (100% width) on small screens, two columns (50% width) on medium screens and three columns (rough 33%, but with some additional padding) on large screens.
+
+So what do we do with this scenario? Again, the first thing you'll need is a CMS that generates, let's say six, images to fit this scenario. Assuming the images are in place, the code is actually not that bad, albeit a little verbose. Here's some example code pulled directly from the responsive images spec:
+
+~~~{.language-markup}
+<picture>
+<source sizes="(max-width: 30em) 100%, (max-width: 50em) 50%, calc(33% - 100px)"
+        srcset="pic100.jpg 100w, pic200.jpg 200w, pic400.jpg 400w,
+                pic800.jpg 800w, pic1600.jpg 1600w, pic3200.jpg 3200w">
+<img src="pic400.jpg" alt="Robert Anton Wilson laughing">
+</picture>
+~~~
+
+Believe it or not, this is actually the terse way to write this out. You *could* write this out as six different `<source>` elements each with the entire `srcset` above, though I have no idea why you would want to do that.
+
+Let's step through the code line by line. The first thing we do is set up a series of breakpoints along with the size of the image relative to the viewport width at each of those breakpoints. So `(max-width: 30em) 100%` covers our smaller screen where the layout is single column and the image is full width. Then `(max-width: 50em) 50%` covers our medium layout which happens between 30em and 50em, where images are now 50% the width of the viewport.
+
+For the last argument in `sizes` things are a little trickier. There's no max-width, this just applies to everything over 50em. The single argument uses `calc()` to say images are 1/3 the viewport width, but there's 100px of padding as well. You may have heard that you should avoid using `calc()` in CSS since it tends to slow things down. Is the same thing true here? I actually don't know; if you do, chime in in the comments. 
+
+Once we have the image-to-viewport ratio setup for each of our layout possibilities, then we use `srcset` to point the browser to our six image sizes, adding a width specification to help the browser pick the best one. In the end the browser will pick the optimal image based on the current image-to-viewport ratio, current viewport size and current viewport density. 
+
+Complicated though this may be, it's actually pretty awesome. You've got the ability to serve the right image to the right screen based on the actual size the image will be on the screen. That's far more effective and powerful than just saying send a small image to a small screen and a big on to a big screen.
+
+## Further Reading
+
+Picture is awesome, but sprawling in scope. It's probably the single most potentially confusing element in HTML, but fortunately the basic uses cases are simple.
+
+Still, it never hurts to have more info. With that in mind here's a list of tutorials and write ups that you should check out as well.
+
+* [Native Responsive Images](https://dev.opera.com/articles/native-responsive-images/) -- Yoav Weiss writing for the Opera Dev center on how to use the `<picture>` element. Weiss wrote the code for Blink/WebKit's `<picture>` support; very few people understand `<picture>` as well as he does.
+
+* [The official Responsive Images Community Group website](http://responsiveimages.org/) Lots of good stuff here, including some [demos](http://responsiveimages.org/demos/).
+
+* [Responsive Images Use Cases](http://usecases.responsiveimages.org/) -- This covers the use cases and rational behind the `<picture>` element.
+
+* [The picture Element](http://www.w3.org/html/wg/drafts/html/master/embedded-content.html#the-picture-element) -- the HTML spec document. 
+{^ .list--indented }
+
diff --git a/src/old-no-longer-pub/2014-02-20_live-editing-sass-firefox-vim-keybindings.txt b/src/old-no-longer-pub/2014-02-20_live-editing-sass-firefox-vim-keybindings.txt
new file mode 100644
index 0000000..a133705
--- /dev/null
+++ b/src/old-no-longer-pub/2014-02-20_live-editing-sass-firefox-vim-keybindings.txt
@@ -0,0 +1,118 @@
+---
+title: Live Editing Sass in Firefox with Vim Keybindings
+pub_date: 2014-02-20 10:08:45
+slug: /blog/2014/02/live-editing-sass-firefox-vim-keybindings
+tags: Building Smarter Workflows
+metadesc: The Firefox developer tools now support live editing Sass files right in the browser and Vim keyboard shortcuts
+code: True
+tutorial: True
+
+---
+
+[TOC]
+
+The Firefox developer tools now support [live editing Sass files right in the browser](https://hacks.mozilla.org/2014/02/live-editing-sass-and-less-in-the-firefox-developer-tools/).
+
+This is, like a lot of what Mozilla has been doing lately, a case of Firefox playing catch-up with the competition -- Chrome has had similar features for quite some time. 
+
+On the other hand, Firefox is ahead of Chrome in another area: [Vim and Emacs keybindings](https://developer.mozilla.org/en-US/docs/Tools/Using_the_Source_Editor#Alternative_key_mappings) (which I believe is because the editor in Firefox is based on [CodeMirror](http://codemirror.net/)).
+
+If that means nothing to you then stick with Chrome. If, however, you're loath to abandon the power of Vim or Emacs for editing files in the browser, this means you can have the best of both worlds -- live editing Sass files in the browser *and* Vim or Emacs keybindings.
+
+Because live editing [Sass files](http://sass-lang.com/) in the browser with Vim keybindings? That's some awesome sauce right there.
+
+If you prefer, here's a screencast walking you through the process. Other wise, read on.
+
+<div class="embed-container-960">
+<div class='embed-container'>
+    <iframe src='https://player.vimeo.com/video/87289985' frameborder='0' webkitAllowFullScreen mozallowfullscreen allowFullScreen></iframe>
+</div>
+</div>
+
+## Set Up Sass Editing in Firefox.
+
+The Mozilla Hacks blog posted a [quick overview](https://hacks.mozilla.org/2014/02/live-editing-sass-and-less-in-the-firefox-developer-tools/) on how to set things up, but it assumes you've already got Sass set up to compile sourcemaps. In case you don't, here's some more complete instructions on how to set up Sass and Firefox[^1].
+
+### Firefox
+
+First off you need a pre-release version of Firefox. Both the Sass sourcemaps support and the Vim/Emacs keybindings are available starting with Firefox 29. I use the [Nightly channel](http://nightly.mozilla.org/) (currently Firefox 30a1), but the [Aurora channel](http://www.mozilla.org/en-US/firefox/aurora/) (currently Firefox 29a2) will work as well. 
+
+### Sass and Compass
+
+The next step is to set up Sass such that it will output a sourcemap file in addition to your CSS.
+
+What in the world is a sourcemap? Simply put, sourcemaps are a way to map compiled code back to its pre-compiled source. The reason any of this is possible at all is because Sass recently added support for CSS sourcemaps. That means that when it turns your Sass code into CSS, Sass also outputs a map of what it did. Firefox can then look at the map and connect the rendered CSS back to your source Sass. The sourcemap support is brand new and currently only found in the pre-release versions of Sass.
+
+I happen to like the Sass offshoot [Compass](http://compass-style.org/) better than vanilla Sass as Compass provides some very handy extras like CSS 3 prefixing tools. As with Sass, only the pre-release versions of Compass support sourcemaps (and even those are [not quite there](https://github.com/chriseppstein/compass/issues/1108)). 
+
+Fortunately we can get the pre-release versions of both Sass and Compass with a single command. 
+
+~~~.language-bash
+$ sudo gem install compass --pre
+~~~
+
+This command tells the Ruby gem system that we want the pre-release version of Compass (that's what the --pre flag is for). In the process we'll also get the latest version of Sass that works with Compass. 
+
+You're probably used to starting Compass with something like `compass watch`. Eventually you'll be able to do that, but for now the only way I've been able to get Sass, Compass and sourcemaps working together is by invoking `sass` directly like so:
+
+~~~.language-bash
+`sass --compass --poll --sourcemap --watch sass/screen.scss:screen.css`
+~~~
+
+To break that down:
+
+1. `sass --compass` -- this bit starts Sass and includes Compass so that we have access to all our extras.
+2. `--poll` -- this gets around a super annoying permissions error. This shouldn't be necessary, but currently it gets around a bug. Alternately you can start `sass` with `sudo`.
+3. `--watch` -- watch tells sass to watch for changes rather than just compiling once.
+4. `--sourcemap sass/screen.scss:screen.css` -- This is the important part. We tell Sass that we want to use sourcemaps and then we create a mapping. In this case I've told Sass to make a map explaining how the file screen.scss inside the `sass` folder turns into the `screen.css` output file. This is what Firefox will use to map CSS rules to Sass rules.
+
+Sass is now running, watching our files for changes. Now we just need a local server of some kind. I typically use my [my python server trick](https://longhandpixels.net/blog/2013/11/easiest-way-get-started-designing-browser) for quick prototyping, but anything will work -- local Apache, Nginx, Django development server, whatever development server RoR offers -- anything will work.
+
+### Putting it All Together
+
+Now let's go back to Firefox and let it know about our sourcemap. 
+
+Here's where things are significantly different than Chrome. I'm not sure which is "better" but if you're used to the Chrome approach, the Firefox approach may seem strange. 
+
+![Right click in the CSS field to show original source](https://longhandpixels.net/media/images/2014/show_original_sources.jpg){: class="img-right"}First load your localhost url. Now open the developer tools and inspect some element you want to change. Now all you need to do is right click in the CSS section of the Inspector tab and choose "Show original sources". Now click the little link next to the style rules and Firefox will open your Sass file in the Style editor.
+
+Now just hit save, either the link next to the file list or hit CMD-S (CTRL-S). The first time you save a file you have to tell Firefox where the file is on your disk -- navigate to the folder with your Sass files and hit save, overwriting the original. You'll need to do this once for each Sass partial that you have, which is annoying if you've got a lot. I happen to prefer the Chrome method, which maps the local folder to a local URL. It's a bit more work to set up, but you only have to do it once.
+
+Either way though that's it, you're done. Edit Sass live in the browser, see your changes update almost instantly with no refresh.
+
+Here's what it looks like:
+
+[![Animated gif showing live Sass editing in Firefox](https://longhandpixels.net/media/images/2014/smaller-ff-tools.gif)](https://longhandpixels.net/media/images/2014/smaller-ff-tools.gif "View Image 1")
+: Just right click to change the view from compiled CSS to SCSS. Pretty Cool. Note that I've already saved the file once so Firefox knows where it is.
+
+
+## Vim or Emacs Keybindings
+
+I know, I know you were only in it for the keybindings, how the heck do you get those?
+
+Pretty simple. Open `about:config` and search for `devtools.editor.keymap`. Right click the "value" field and enter either "vim" or "emacs". I had to restart Firefox for the changes to take effect.
+
+Now you have a way to edit Sass right in the browser and still get the benefit of all the keyboard shortcuts you've commited to muscle memory over the years.
+
+There's one annoying bug (at least I think it's a bug) for Vim users, `:w` (the Vim save command) does not work like CMD-S (CTRL-S); it will always open the file save dialog box rather than just writing to disk. It's annoying, but I haven't found a workaround yet.
+
+## Shortcomings Compared to Chrome
+
+While Firefox's combo of live editing Sass and Vim keybindings is awesome, there a couple things that I think could be improved.
+
+In Chrome if you CMD-click (or CTRL-click) on an individual CSS rule in the styles tab Chrome jumps you to the relevant file and moves your cursor right to that rule. It even highlights the line in yellow for a second or two so you know where the cursor is in the file. It's very slick and very useful. CMD-click a rule in Firefox and nothing special will happen. Bummer. 
+
+The other thing that's troubling me with Firefox is the need to "Save As" the first time you edit a Sass file. It feels janky to me and frankly it's a pain when your project has dozens and dozens of Sass partials. I much prefer Chrome's (admittedly perhaps more confusing at first) approach of associating a folder with a URL.
+
+Still, the Vim keybindings makes me more productive than I can be in Chrome without them so I'm back to Firefox.
+
+## Further Reading
+
+* Mozilla Hack Blog: [Live Editing Sass and Less in the Firefox Developer Tools](https://hacks.mozilla.org/2014/02/live-editing-sass-and-less-in-the-firefox-developer-tools/)
+* Tutsplus: [Developing With Sass and Chrome DevTools](http://code.tutsplus.com/tutorials/developing-with-sass-and-chrome-devtools--net-32805)
+* Ben Frain: [Faster Sass debugging and style iteration with source maps, Chrome Web Developer Tools and Grunt](http://benfrain.com/add-sass-compass-debug-info-for-chrome-web-developer-tools/)
+* Google Developer Docs: [Working with CSS Preprocessors](https://developers.google.com/chrome-developer-tools/docs/css-preprocessors)
+* HTML5Rocks: [Sass/CSS Source Map debugging](http://www.html5rocks.com/en/tutorials/developertools/revolutions2013/#toc-key-performance)
+{^ .list--indented }
+
+[^1]: At least here's how you make it happen for Sass; I know nothing about Less, much less Less with Grunt. If you prefer Less, head over to the [Mozilla Hack blog post](https://hacks.mozilla.org/2014/02/live-editing-sass-and-less-in-the-firefox-developer-tools/) and check out their instructions.
diff --git a/src/old-no-longer-pub/2014-03-04_how-to-build-responsive-websites-like-bruce-lee.txt b/src/old-no-longer-pub/2014-03-04_how-to-build-responsive-websites-like-bruce-lee.txt
new file mode 100644
index 0000000..c6e9036
--- /dev/null
+++ b/src/old-no-longer-pub/2014-03-04_how-to-build-responsive-websites-like-bruce-lee.txt
@@ -0,0 +1,54 @@
+---
+title: Why Responsive Design, or How to Build Websites Like Bruce Lee
+pub_date: 2014-03-04 12:04:25
+slug: /blog/2014/03/how-to-build-responsive-websites-like-bruce-lee
+metadesc: Embracing the fluid nature of responsive web design means you can start building websites like Bruce Lee. 
+tags: Responsive Web Design
+
+---
+
+[*Note: This is an excerpt from my book, [Build a Better Web With Responsive Web Design](https://longhandpixels.net/books/responsive-web-design). If you like what you read here, pick up a copy of the book and be sure to sign up for the newsletter over there in the sidebar.*]
+
+Spend enough time emersed in the world of web development and you may notice that the phrase ***responsive web design*** has taken on an almost religious status. 
+
+I grew believing that you should question everything, especially your unchallenged premises. So, why is responsive design a good idea? 
+
+There are many reasons, but to me the most compelling is also the simplest -- the web already is responsive.
+
+Every time you build a website that is not fluid by nature, with content that flows gracefully onto any screen, you are fighting the essential nature of the web. That fighting is going to make your life as a developer more difficult, as anyone who's ever tried to achieve pixel-perfect precision across browsers can attest.
+
+The web is naturally fluid. To show you what I mean, let's play with an example page.
+
+Head to the `sample_files` folder that came with this book and open up the folder `responsive basics`. Now open the file basic.html in your favorite web browser. Pretty boring right? Just some black text on a white background. The text isn't even centered or constrained at all, just long lines stretching across the screen. But let's play with this most basic of web pages for a minute. Grab the right edge of your browser window and resize it, making it narrower. What happens? The text re-wraps and re-flows to fit the new window size. 
+
+Hmm, so the page responded to our input (resizing the screen). That's responsive design in a nutshell. And yes, the web is responsive right out of the box. Now no one but web developers ever drags their window around to watch how designs reflow, so don't get hung up on that. The point isn't that text re-flows as you drag, but that the text can flow onto any screen.
+
+If you've ever built a fixed-width website (960px wide by chance?) you've broken one of the web's greatest features -- it's naturally fluid. Web browsers have always enabled nearly everything now labeled "responsive design" right out of the box, including  the most fundamental element you're looking at here -- fluid layouts. 
+
+Okay, sweet, done.
+
+Well, there is a little more to it, but this really is the core and I find it helpful to frame the question "why responsive design?" this way because it gets to the basic truth of the web -- everything is flexible, everything is fluid. When we embrace the web's inherent fluidity we're actually freeing ourselves from our own constraints. I find that a very liberating feeling, one that has implications well beyond just the web. 
+
+Kung Fu legend Bruce Lee's teacher once said to him. "Preserve yourself by following the natural bends of things and don't interfere." Lee meditated on this idea and eventually came up with his now famous quote that he must have "a mind like water".
+
+>"Don't get set into one form, adapt it and build your own, and let it grow, be like water. Empty your mind, be formless, shapeless -- like water. Now you put water in a cup, it becomes the cup; You put water into a bottle it becomes the bottle; You put it in a teapot it becomes the teapot." -- Bruce Lee
+
+Lee's metaphor works for nearly anything, but it's especially apt for anyone building responsive websites. It perfectly captures what we're striving for -- content and design that flow like water from one screen to the next -- as well as the approach we need to take -- keeping an open mind, letting go of our preconceptions and learning to embrace the flow of the web.
+
+If all that sounds a little hokey to you, consider another thought, equally rooted in Asian philosophy, but a little more concrete, John Allsopp's *[A Dao of Web Design](http://alistapart.com/article/dao)*. 
+
+Allsopp's famous article is perhaps the best thing ever written about web development. What's perhaps most astounding about *A Dao of Web Design* is that it was written not last year, not even right after the iPhone was released and changed the mobile device landscape forever, but way back in 2000 when the web development community was still trying to sort out how to separate form and function with cascading stylesheets.
+
+Before iPads, before Google Glasses, before there even was a mobile web, Allsopp hit the nail on the head: "It is the nature of the web to be flexible, and it should be our role as designers and developers to embrace this flexibility, and produce pages which, by being flexible, are accessible to all."
+
+I highly recommend you read [the entire article](http://alistapart.com/article/dao). Go ahead, I'll wait. 
+
+Sure, some of Allsopp's examples are a bit outdated, like his argument against the font tag. No developer worth their salt would even think to use a font tag these days. In fact, that's one of the upsides of the web today -- much of Allsopp's advice in the article has since become part of most web developer's best practices, part of the standard web developer toolkit. For example, avoiding HTML for presentation and using relative font sizing (percentages or ems) to ensure pages scale properly. 
+
+But sadly most of us did not heed Allsopp's bigger-picture advice to embrace the inherently flexible nature of the web. Here's Allsopp's original suggestion for working with the flexibility of the web rather than fighting it:
+
+>Make pages which are accessible, regardless of the browser, platform or screen that your reader chooses or must use to access your pages. This means pages which are legible regardless of screen resolution or size, or number of colors (and remember too that pages may be printed, or read aloud by reading software, or read using braille browsers). This means pages which adapt to the needs of a reader, whose eyesight is less than perfect, and who wishes to read pages with a very large font size.
+
+Unfortunately Allsopp's advice was largely ignored, even by some of the best known developers on the web. Regrettably, we at Webmonkey did not start embracing responsive development best practices until the second round of interest, when, like everyone else, the iPhone and other mobile devices forced us to rethink our designs.
+
+That's okay though, it's never too late to embrace something new. 
diff --git a/src/old-no-longer-pub/2014-03-12_zen-art-responsive-workflow.txt b/src/old-no-longer-pub/2014-03-12_zen-art-responsive-workflow.txt
new file mode 100644
index 0000000..f9e023f
--- /dev/null
+++ b/src/old-no-longer-pub/2014-03-12_zen-art-responsive-workflow.txt
@@ -0,0 +1,86 @@
+---
+title: Zen and the Art of the Responsive Web Design Workflow
+pub_date: 2014-03-12 10:08:57
+slug: /blog/2014/03/zen-art-responsive-design-workflow
+metadesc: Embracing the fluid nature of responsive web design means you can start building websites like Bruce Lee. 
+tags: Responsive Web Design
+tutorials: True
+
+---
+
+[*Note: This is an excerpt from my book, [Build a Better Web With Responsive Web Design](https://longhandpixels.net/books/responsive-web-design). If you like what you read here, pick up a copy of the book and be sure to sign up for the newsletter over there in the sidebar.*]
+
+[TOC]
+
+If your current workflow is anything like mine and that of other designers I have worked with, it probably goes something like this: wireframe content -> sketch designs -> convert those to Photoshop comps -> pass to client for approval -> convert to HTML/CSS/JavaScript. I've left out a few steps, but the basic idea is pretty simple: Photoshop is the first place you go after you have the skeleton of the design on paper.
+
+Perhaps not coincidentally that's almost exactly the workflow (albeit a greatly simplified version) of Wired magazine's print edition. It's the workflow that web designers inherited from print and one that's still taught in all but the most forward thinking web design programs. It's taught because for a long time it worked. Sure people might resize their browser or text, but for the most part you could mock up something in Photoshop and reliably convert it to HTML and CSS  with maybe a bit of JavaScript thrown in.
+
+To embrace a responsive approach and stick with the this workflow means you're going to have a very hard time not just thinking responsively but mocking things up. How will you know where your breakpoints need to be without putting your designs in a live browser and resizing them? Once you have those breakpoints you're going to have to back the Photoshop and create what, 4 mockups? 6? 10? That's a lot of extra work.
+
+[![Illustration of scenario where image size does not necessary correspond to viewport](/media/images/2014/workflows-the-hard-way.jpg)](/media/images/2014/workflows-the-hard-way.jpg "View Image 1")
+: Mockups the hard way. Why create tons of different size and state mockups in Photoshop when you can actually build it, live, fully-functional in the browser?
+
+Just as we've shrugged off so much of the print design legacy in other ways -- flexible canvases, fluid designs and flowing text -- it's time to shrug off the print design workflow. It's time to put down the Photoshop, step away from the pixels and rethink our approach from the ground up.
+
+That doesn't mean we shouldn't learn from print. A lot of web developers talk about starting from the content and working your way out, which is exactly what print designers do as well. The content should always be the starting point, but the way we think about the content and the way we figure out how it will behave and appear to the user needs to change.
+
+## Working with the Responsive Flow
+
+Quite frankly coming up with a responsive workflow that really works is going to take some experimentation on your part. Whether you're part of a small team, large team or working on your own, you have your idiosyncrasies and tics to consider. A good workflow will work with, not against your unique style.
+
+While you should embrace your idiosyncrasies and tics, there are some general guidelines that have emerged from those of us who have worked on responsive sites big and small. I'm going to offer some methods and tools in the hope that they prove beneficial to you and your team.
+
+The biggest change I suggest making when -- or even before -- you attempt your first responsive design project is to get your designers and developers working together. Too often developers are brought in much later in the process, after the design work is already done. That might work when your designs have only one, set in stone width, but for responsive design you'll likely benefit from bringing in developers right at the outset. 
+
+When your design and development teams work together you can start to get the kind of feedback loop you need for effective responsive workflows. Collaboration means there's immediate feedback for both teams. Developers can point out scenarios where designs fail and designers can go back and handle those. You decrease the likelihood of anything falling through the cracks. For example, what happens when the user denies access to geo-location data? What happens when the JavaScript fails and the ads don't load? What happens when the third-party fonts fail? 
+
+Developers tend to be better at imagining all the ways in which a design can fail. Let them in early so they can better inform the process. They can point out problems early, before they require a massive effort to solve.
+
+The other side of the coin comes later, when you're building out the actual site. Keep designers involved and they can help sort out unforeseen problems. Developers might not know the why behind a decision, but if your designers are working alongside them they can help guide the development process by offering insight into decisions and helping to ensure the original, client-approved vision is maintained.
+
+This sort of workflow necessarily requires good communication skills, but more than anything it requires rethinking your approach. Gone are the days when designers handed their work to developers and moved on. Gone too are the days when developers could just sit back and wait for finalized mockups to convert to HTML and CSS. If such days ever existed at all, they are certainly behind us now. 
+
+If your design and development teams aren't working together, get them working together post haste. 
+
+What does this look like on a practical level?
+
+Well, as I've written elsewhere, [start with content](https://longhandpixels.net/blog/2014/02/work-smarter-plain-text-workflow#everything-starts-with-the-content) when you can. 
+
+Once you have the content you can move on to sketching and wireframing -- figuring out the structure of the page and overall site. I tend to do this stage mostly on paper because if find it the fastest way to get my ideas recorded, but I've seen other developers who use iPads with styluses, mind mapping tools, even one who used spreadsheets to create wireframes (yeah, he was a little strange). 
+
+If you haven't before embrace what designer Jason Santa Maria once termed the "[gray box method](http://v3.jasonsantamaria.com/archive/2004/05/24/grey_box_method.php)". That is, wireframe the basic elements of your site as a series of gray boxes you can then shuffle and rearrange as you figure out which bits of content need to go where on various layouts and screen sizes. You can even take this literally, cutting our gray shapes and taping them to something like a white board in various configurations. The point of using gray is to stop, in Santa Maria's words, "worrying about color and imagery choices and allow myself to focus on the site’s structure and hierarchy." This is particularly helpful in responsive design because it forces you to consider from the outset how you'll need to reshuffle content as the screen size changes.
+
+Along with wireframes, I sketch user flows and step by step scenarios based on how the client imagines their visitors interacting with the site. This helps with design obviously, but it also helps tremendously when you get to the testing stage by providing an ideal against which to measure how visitors *actually* interact with the site. The gap between those two things becomes the basis of the next iteration. 
+
+## Designing in the Browser
+
+Once I have a good idea of how I want to arrange the content on the page I immediately jump into the browser and start working with live HTML. At this point I'm just stacking text and creating structure, there's no CSS yet.
+
+How I work in the browser is probably the most idiosyncratic part of my workflow. I've written a bit before about how I work with [plain text files and Pandoc to generate live HTML mockups](https://longhandpixels.net/blog/2014/02/work-smarter-plain-text-workflow#tool-2-plain-text). I then serve those mockups with a simple webserver, which I think is the [easiest way to get started "designing in the browser"](https://longhandpixels.net/blog/2013/11/easiest-way-get-started-designing-browser). From there I start editing and refining my mockups directly in the browser, using tools like the Chrome or [Firefox Developer Tools](https://longhandpixels.net/blog/2014/02/live-editing-sass-firefox-vim-keybindings).
+
+It's worth pointing out that this process of sketching, wireframing, outlining user flows and building mockups in the browser is not all that different from what I've always done, responsive or otherwise, but there is one major difference -- responsive design requires a more circular flow. 
+
+In other words this is not a straight linear progression from sketch to wireframe live demo. It's more like a series of loops, something like: look at the content, sketch out basic ideas, create a wireframe, consider user flows, go back to content, rearrange slightly, tweak wireframe, create mockups, revisit user flows, re-tweak wireframe and so on.
+
+## Rinse and Repeat
+
+Once I've got a basic live site served up from a local folder, with at least one version of all the different pages the site is likely to have, the next step is to start doing all the things that make up building a responsive site. For me that means starting with my small screen layout,  which is also typically the least capable device I'm supporting, and then working my way up the line. I create a basic mobile layout and then start stretching it until it looks like crap. I mark that as a breakpoint and head back to my text editor to start a new media query. Then I rinse and repeat with all the various pages until everything has been handled.
+
+This will be ported over to template files at some point. This mockup process is still very loose and experimental and I shift back and forth between text editor and Firefox/Chrome, experimenting to see what makes the most sense. 
+
+This essentially begins the looping workflow I talked about above -- iterating through various pages, encountering issues and solving them, whether that's something I do myself or something slightly more structured when I'm working with a team.
+
+One of the advantages of this workflow is the fact that you can take a live mockup to the client. In my experience this is usually incredibly helpful. It allows the client to interact with a mockup and see where the problems are before the site is in a more finalized form. 
+
+
+## Conclusion and Further Reading.
+
+As I wrote at the start of this piece, there is no one size fits all responsive design workflow. That said I think it is helpful to distill the basics down to these three general principles:
+
+* Start with content (when possible)
+* Work with code directly as much as possible -- test everything in the browser.
+* Iterate. 
+{^ .list--indented }
+
+If you'd like more details on how I do all that and the tools I use be sure to look at my previous post on my [plain-text based workflow](). You might also want to pick up a copy of my book which has over 100 pages and dozens of videos devoted to various tools and [responsive design workflows](https://longhandpixels.net/books/responsive-web-design).
diff --git a/src/old-no-longer-pub/2014-03-19_better-link-underlines-css-background-image.txt b/src/old-no-longer-pub/2014-03-19_better-link-underlines-css-background-image.txt
new file mode 100644
index 0000000..85a929c
--- /dev/null
+++ b/src/old-no-longer-pub/2014-03-19_better-link-underlines-css-background-image.txt
@@ -0,0 +1,58 @@
+---
+title: Better Link Underlines with CSS `background-image`
+pub_date: 2014-03-19 12:04:25
+slug: /blog/2014/03/better-link-underlines-css-background-image
+tags: CSS Tips & Tricks
+metadesc: Using CSS background-image to get (nearly) perfect link underlines.
+code: True
+tutorial: True
+
+---
+
+Medium's Marcin Wichary posted a fascinating look at his [quest](https://medium.com/p/7c03a9274f9) to create better looking link underlines on the site. It's a great read if you're at all obsessive about typography on the web.
+
+>How hard could it be to draw a horizontal line on a screen? ... This is a story on how a quick evening project to fix the appearance of underlined Medium links turned into a month-long endeavour.
+
+I highly suggest having a look at [Wichary's post](https://medium.com/p/7c03a9274f9), but Medium doesn't seem big on tutorials -- Wichary never actually posts the code he's using to achieve the underlines.
+
+I was curious, because Google may be abandoning link underlines, but I still like them, especially when the links are in bodies of text. I was also curious because this site has the same problem Medium's old link styles had in Chrome: ugly, thick underlines. The version of Chrome in the Canary channel fixes this, but the current shipping version still looks bad:
+
+[![Ugly link underlines in Chrome](https://longhandpixels.net/media/images/2014/chrome-underlines-bad.png)](https://longhandpixels.net/media/images/2014/chrome-underlines-bad.png "View Image 1")
+: Link underlines in Chrome 33 and below
+
+Canary channel:
+
+[![better link underlines in Chrome](https://longhandpixels.net/media/images/2014/chrome-underlines-better.png)](https://longhandpixels.net/media/images/2014/chrome-underlines-better.png "View Image 2")
+: Link underlines in Chrome 35+
+
+Still, I was curious what Wichary has come up with so I opened the dev tools, poked around a bit and found that these are the key styles:
+
+~~~.language-css
+a {
+    text-decoration: none;
+    background-image: linear-gradient(to bottom, white 75%, #333332 75%);
+    background-size: 2px 2px;
+    background-position: 0px 24px;
+    background-repeat: repeat-x;
+}
+~~~
+
+You'll need to adjust the colors to fit with your site's color scheme and bear in mind that the background size and position may need to be adjusted based on your font size and line-height.
+
+I happen to like the underline slightly heavier than what Medium is using so after playing with this technique a bit, here's what I'm planning to roll out here at some point:
+
+~~~.language-css
+    background-image: linear-gradient(to bottom, white 50%, #DE4D00 75%);
+    background-size: 2px 2px;
+    background-position: 0 20px;
+    background-repeat: repeat-x;
+~~~
+
+Here's what it looks like:
+
+[![Fancy link underlines using background-image](https://longhandpixels.net/media/images/2014/fancy-underlines.png)](https://longhandpixels.net/media/images/2014/fancy-underlines.png "View Image 3")
+: Link underlines using `background-image`
+
+So far as I can tell there are no accessibility or other downsides to this technique, but if you know better let me know in the comments. It degrades pretty well too since you can just use a good old `text-decoration: underline;` for older browsers.
+
+Now if only the Medium developers would give the site's URLs this level of attention.
diff --git a/src/old-no-longer-pub/2014-03-20_look-responsive-design.txt b/src/old-no-longer-pub/2014-03-20_look-responsive-design.txt
new file mode 100644
index 0000000..b4553af
--- /dev/null
+++ b/src/old-no-longer-pub/2014-03-20_look-responsive-design.txt
@@ -0,0 +1,36 @@
+---
+title: The Look of Responsive Design 
+pub_date: 2014-03-20 12:04:25
+slug: /blog/2014/03/look-responsive-design
+metadesc: Does responsive design have a 'look'?
+tags: Responsive Web Design
+---
+
+Mark Boulton posted something to Twitter yesterday that I think deserves more attention than it has seen thus far. Boulton [writes](https://twitter.com/markboulton/status/445943150247702528): 
+
+>"I wonder if #RWD looks the way it does because so many projects aren't being run by designers, but by front-end dev teams."
+
+I suppose you could take that as a dig against front end developers, but I don't think it was meant that way and that, to me anyway, is not the interesting part of the question. 
+
+I'm also not interested in defending responsive design. If you don't want/like/care about responsive design that's fine. Carry on. 
+
+What I've been thinking about since I read Boulton's thought is not the roles of designers and developers in responsive projects[^1]. What got me thinking is this notion that "responsive web design looks the way it does". 
+
+The reason I've been thinking about it is because when I first saw this in my Twitter feed I had a kind of gut reaction -- *yeah, I know what he means there, responsive web design does look a certain way*. But the more I've thought about this, the less I agree with myself and my initial gut reaction. 
+
+I'm actually pretty sure I have no idea what responsive design looks like. 
+
+What I'm really hoping is that Boulton will blog about what he meant because he's a talented designer and I am not, so it's very possible I'm missing the obvious. 
+
+Tim Kadlec offers some reasons [Why RWD Looks Like RWD](http://timkadlec.com/2014/03/why-rwd-looks-like-rwd/), and goes a little further, writing "to be fair, a pretty large number of responsive sites do tend to share similar aesthetics."
+
+I agree with him, but I don't know that responsive web design has anything to do with it. I think that a pretty large number of WordPress site's [look like WordPress sites](http://ma.tt/2014/01/techmeme-100/). I think you could back up out of categories entirely and simply say "a large number of *websites* share similar aesthetics".
+
+Sure, the popularity of responsive design coincides with some other design trends: blocky, very consciously grid-oriented layouts, Pinterest-inspired layouts, Medium-popularized big image layouts and so on. And at the same time libraries like Bootstrap and its ilk have homogenized design details to some degree[^2]. Then there's the ubiquitous "hamburger" menu and other shared mobile design patterns, but most of those patterns are purloined from mobile applications rather than something responsive web designers came up with.
+
+There's also the fact that newsy websites (Boston Globe, BBC, The Guardian, et al) have been some of the earliest and most prominent adopters of responsive design. They all have similar visual designs, but I think that's owing more to the similarity in [the structure of news content](http://www.markboulton.co.uk/journal/structure-first-content-always) than responsive web design.
+
+Responsive design imposes new constraints that are hard to solve. And whenever there's new territory, early maps all tend to borrow from each other and end up looking similar. When someone solves a problem -- for example, pull to refresh -- dozens of others rush to adopt the same solutions, which leads to common design patterns, but there's nothing about that that's unique to responsive design.
+
+[^1]: I suspect that was more the point and it's probably a better topic, but it's not the one that got me thinking.
+[^2]: Which is not to say that's a bad thing. It is just a thing.
diff --git a/src/old-no-longer-pub/2014-03-26_shell-code-snippets-done-right.txt b/src/old-no-longer-pub/2014-03-26_shell-code-snippets-done-right.txt
new file mode 100644
index 0000000..038b841
--- /dev/null
+++ b/src/old-no-longer-pub/2014-03-26_shell-code-snippets-done-right.txt
@@ -0,0 +1,48 @@
+---
+title: Shell Code Snippets Done Right
+pub_date: 2014-03-26 12:04:25
+slug: /blog/2014/03/shell-code-snippets-done-right
+metadesc: A better way to post shell code samples on your site.
+tags: CSS Tips & Tricks
+code: True
+tutorial: True
+
+---
+
+If you post tutorials online, particularly anything involving shell code, you've inevitably run into the problem where people copy and paste the code and end up including the `$` prompt by mistake.
+
+The code won't work when you do that so your tutorial becomes less helpful. Sometimes people will post a comment wondering what happened, but they're just as likely to decide you don't know what you're talking about and move on.
+
+Even users that know not to copy the `$` have to be careful how when they select your code to avoid accidentally copying it.
+
+You could leave out the `$` to avoid this, but then it can be hard to tell what's a wrapped line versus what's two separate lines of code.
+
+Turn out there's a better way -- you can display the prompt and make sure no one ever selects it thanks to the CSS pseudo class `:before`.
+
+I found [this screenshot][1][^1] in an open tab this morning and thought I'd share what a subtle, but helpful stroke of genius Github has created here:
+
+[![Screenshot of Github source code showing how to use `:before` to add a prompt before shell code][2]](https://longhandpixels.net/media/images/2014/github-prompt-before.jpg "View Image 1")
+: Github's ingenius use of `:before` to display a prompt before shell code snippets
+
+Github is using a pseudo class to prepend command line code with the `$` prompt. It's a great attention to detail -- you get the prompt, but because it's a pseudo element it can't be copied when users copy and paste the code. In most browsers it can't even be selected, which means you don't have to worry when you're highlighting code to copy it.
+
+This site currently uses [Prismjs][3] for code highlighting so Github's exact syntax won't work here, but here's a snippet of CSS to make this work with Prismjs:
+
+~~~.language-css
+code.language-bash:before {
+    content: "$ ";
+}
+~~~
+
+The markdown processor I use adds `language-bash` to both the `pre` and `code` tags, which is why I've used the more specific `code` selector. 
+
+And there you go, a better way to display snippets of shell code on your site.
+
+The main downside I can see is that if/when I roll this out I have to go back and delete all the `$` in my posts. 
+
+[^1]: I have no idea where I found this or how it came to open in my browser. Probably Twitter, but I've been unable to track down who did it since Twitter's search features suck. If you know, post a comment.
+
+
+[1]: http://cl.ly/Ub7p
+[2]: https://longhandpixels.net/media/images/2014/github-prompt-before.jpg
+[3]: http://prismjs.com/
diff --git a/src/old-no-longer-pub/2014-04-05_why-mobile-first-responsive-design.txt b/src/old-no-longer-pub/2014-04-05_why-mobile-first-responsive-design.txt
new file mode 100644
index 0000000..4728863
--- /dev/null
+++ b/src/old-no-longer-pub/2014-04-05_why-mobile-first-responsive-design.txt
@@ -0,0 +1,52 @@
+---
+title: Why Mobile-First is the Right Way to Build Responsive Websites
+pub_date: 2014-04-05 12:04:25
+slug: /blog/2014/04/why-mobile-first-responsive-design
+metadesc: Why taking a mobile-first approach is the best way to build responsive website.
+tags: Responsive Web Design
+
+---
+[*Note: This is an excerpt from my book, [Build a Better Web With Responsive Web Design](https://longhandpixels.net/books/responsive-web-design). If you like what you read here, pick up a copy of the book and be sure to sign up for the newsletter over there in the sidebar.*]
+
+The goal of responsive web design is to create websites that look great and function well on any device that accesses them. 
+
+Assuming you're already familiar with the flexible foundations of fluid layouts and typography along with @media queries you're ready to dive into the world of responsive web design. 
+
+In fact, you're probably itching to dive in and start writing @media queries for tablet-size devices and others for mobile devices to trick out your current fixed-width sites in shiny new responsive duds.
+
+That approach works. You can approach responsive design as something you tack on to a desktop site. That is, you can build out your designs for larger screens and then use media queries to make sure things look good on tablets, phones and all the other myriad devices out there. Indeed, this is often the only practical approach to take when you're adding on to an existing design with clients who have a tight budget or timeline and don't want a completely redesigned website. 
+
+In other words, there's nothing wrong with building a desktop site and then adding some @media queries to handle other screens. In fact I guarantee that, no matter how much you want to embrace the approach I'm about to outline there will be cases where it just isn't an option.
+
+That said, there is, to my mind, a far better place to start your responsive designs -- with the least capable device. 
+
+Developer Luke Wroblewski, who, among other things, was the Chief Design Architect at Yahoo, has helped popularize what he calls a "mobile-first" approach to design. In fact he's written a book on the subject entitled, appropriately, *[Mobile First](http://www.abookapart.com/products/mobile-first "buy Mobile First")*. I'm going to briefly discuss why I think what Wroblewski calls mobile first is the best approach for responsive design. For a deeper look at why a mobile first approach makes the most sense be sure to pick up a copy of Wroblewski's *Mobile First*.
+
+Why does Wroblewski think you should start designing for mobile devices first? Here's what he [writes on his blog](http://www.lukew.com/ff/entry.asp?1333 "Luke Wroblewski on why mobile-first is the right approach" ):
+
+>We start with the value of our service and our content. The constraints in mobile devices force us to focus on what really matters so we only include and emphasize the most valuable parts of our offering first and foremost. 
+
+In other words the constraints of mobile devices -- often, though not always, limited bandwidth, small screens, touch interfaces, etc -- help you focus on what's really important in your designs. That means cutting the cruft and getting the content your users are after front and center. For example, it might force you to consider, given the limited screen sizes of mobile devices -- often less than 480px in height -- whether that 100px tall logo is really worth the screen real estate it requires. Ditto menus, sharing buttons and all the other cruft that can accumulate around the actual content users want. Some of that "cruft" might be important, some might not. The point is that starting with mobile devices helps to create constraints, which in turn creates focus.
+
+While I like Wroblewski's mobile-first approach, I have a slightly different way of looking at it. As I already mentioned, I like to think not just mobile-first, but *least capable device first*^[1].
+
+Clearly I'm no good at coining a phrase, but I prefer to think of it this way because most of the constraints of mobile devices will be gone in the next few years -- networks are getting faster, so are mobile processors. However, while the phones of tomorrow may be as powerful as the laptops of today, there will be an entirely new class of devices we haven't even thought of yet connecting to the web that will have constraints. In other words, don't get hung up on the "mobile" part of mobile-first, think ***least capable device first***.
+
+Naturally, *least capable* is very open-ended. Does that mean you have to make sure your site renders in Lynx running on a BBC Micro? No, it just means starting with the basics and layering on complexity rather than starting with the complex desktop layout and trying to strip it back. 
+
+In fact the first step is determining the least capable device you want to support. Sometimes that might be a feature phone browser that doesn't understand @media queries. Other clients might not care about reaching that market and just want something that works well on the mobile devices most popular in the U.S and Europe.
+
+Whatever the case, first determine where you're going to start. Once you have that least capable device to target you can start building.
+
+So what are the practical components of a least capable device mindset? What does this mean for our actual code?
+
+It means we start by building a site that works on these least capable devices. No media queries, no fancy JavaScript. Just a basic site optimized for the least capable device you're targeting. 
+
+Start simple. Build your site so it looks good without many bells or whistles. This has two advantages, the first is practical, it supports older phones and mobile web browsers that don't understand @media queries (as noted earlier it might even mean obscurities like Lynx works as well). The second advantage to the approach is that it forces you to focus on what's important from the get-go.
+
+Then, once you have a baseline experience you can add the bells and whistles. 
+
+You wouldn't start building a massive skyscraper without first laying a strong foundation. That's precisely what this bare-bones experience provides, a strong foundation to support all the rest of your progressively more complex enhancements.
+
+
+[^1]: I'm pretty sure Wroblewski also means least capable device when he says mobile first, I just like to be explicit about it.
diff --git a/src/old-no-longer-pub/2014-04-23_learn-web-development-today.txt b/src/old-no-longer-pub/2014-04-23_learn-web-development-today.txt
new file mode 100644
index 0000000..47144c4
--- /dev/null
+++ b/src/old-no-longer-pub/2014-04-23_learn-web-development-today.txt
@@ -0,0 +1,89 @@
+---
+title: How to Learn Web Development Today
+pub_date: 2014-04-13 12:04:25
+slug: /blog/2014/04/learn-web-development-today
+metadesc: How to learn web development on the modern web or why you don't need webmonkey, A List Apart, Smashing Magazine or anyone else.
+
+---
+
+I launched my book today. If you're interested in learning how to build fast, user-friendly, mobile-first, progressively-enhanced responsive websites grab a copy of the awkwardly titled, ***[Build a Better Web with Responsive Web Design](https://longhandpixels.net/books/responsive-web-design?utm_source=lhp&utm_medium=blog&utm_campaign=lhp)***. There's a free 60 page excerpt you can download to try it out before you buy.
+
+It's been a long, and lately very hectic, road from [running Webmonkey](https://longhandpixels.net/blog/2013/09/whatever-happened-to-webmonkey) to self-publishing, but along the way I got an idea stuck in my head and it won't go away: we need to embrace the post-Webmonkey world. 
+
+To put it another way, we need to embrace the post-megasite web. Webmonkey happens to be the megasite that I identify with, but there are others as well.
+
+I've been thinking about this in part because I've been embracing a post-megasite world on a personal level and also because several dozen people have emailed me over the past year to ask, "now that Webmonkey is gone, what publications should I follow to keep up with web development?"
+
+Most of these people will mention A List Apart, Smashing Magazine, <strike>.Net</strike>, maybe one or two more megasites and then want to know what else is out there that they don't know about yet.
+
+These are all great publications, but they're all, like Webmonkey, a dying breed. .Net already died in fact. There's just not much money in selling ads alongside daily web development news and web-savvy audiences like yourself tend to have ad blockers installed, which means even less money for these sites than say, CNN.
+
+## What to Do Instead
+
+Learning how to build websites and finding answers to your questions has become a very distributed thing in last ten years. While there are still some Webmonkey-esque things around, none of them can possibly keep track of everything. There's simply too much stuff happening too fast for any centralized resource to keep track of. Except for maybe CSS Tricks, which seems to show up in the results for pretty much every web development question I've ever had. Not sure when Chris Coyier sleeps.
+
+For the most part though web development has long since moved past the top-down, hierarchical knowledge structures that tend to define new endeavors, when only a few people know how to do something, to a distributed model where there are so many blog posts, so many answers on Stack Overflow, so many helpful tip and tricks around the web that there is no single resource capable of tracking them all. Except Google.
+
+This has some tremendous advantages over the world in which Webmonkey was born. 
+
+First, it makes our knowledge more distributed, which means its more resilient. Fewer silos means less risk of catastrophic loss of knowledge. Even the loss of major things like Mark Pilgrim's wonderful HTML5 book can be recovered and distributed around so it won't disappear again.
+
+This sort of resilience is good, but the far better part of the more distributed knowledge base is that there are so many more people to learn from. So many people facing the same situations you are and solving the same problems you have means more solutions to be found. This has a two-fold effect. First, it makes your life easier because it's easier to find answers to your questions. Second, it frees up your time to contribute back different, possibly novel solutions to the problems you can't easily answer with a bit of web searching.
+
+So my response to people asking that question "now that Webmonkey is gone, what publications should I follow to keep up with web development?" has two parts. 
+
+## Write What You Know
+
+First, and most importantly, start keeping a public journal of your work. I don't mean a portfolio, I mean a record of the problems you encounter and ways you solve them. Seriously, go right now and download and install WordPress or setup GitHub Pages or something. You're a web developer. If you don't know how to do that yet, you need to do learn how to do it now. 
+
+Now you have a website. When you get stumped by some problem start by searching to see what other people have done to solve it. Then write up the problem and post a link to the solution you find. Your future self will thank you for this; I will thank you for this. 
+
+Not only will you have a reference point should the same question come up again, you're more likely to remember your solution because you wrote it down. 
+
+You'll also be helping the rest of us since the more links that point to good solutions the more those solutions rise to the top of search engines. Everyone wins and you have something to refer back to in six months when you encounter the same problem again and can't remember what you did. 
+
+For example, I don't particularly want to remember how to setup Nginx on Debian. I want to know how to do it, but I don't really want to waste actual memory on it. There are too many far more interesting things to keep track of. So, when I did sit down and figure out how to do it, I wrote a post called [Install Nginx on Debian/Ubuntu](https://longhandpixels.net/blog/2014/02/install-nginx-debian-ubuntu). Now whenever I need to know how to install Nginx I just refer to that.
+
+## Find People Smarter Than You
+
+My other suggestion to people looking for a Webmonkey replacement is to embrace Noam Chomsky's notion of a star system, AKA the blogroll. Remember the blogroll? That thing where people used to list the people the admired, followed, learned from? Bring that back. List the people you learn from, the people you admire, the people that are smarter than you. As they say, if you're the smartest person in the room, you're in the wrong room.  
+
+I'll get you started, here's a list of people that are way smarter than me. Follow these people on Twitter, subscribe to their RSS feeds, watch what they're doing and don't be afraid to ask them for advice. Most of them won't bite. The worst thing that will happen is they'll ignore you, which is not the end of the world.
+
+* [@anna_debenham](https://twitter.com/anna_debenham)
+* [@yoavweiss](https://twitter.com/yoavweiss)
+* [@jenville](https://twitter.com/jenville)
+* [@wilto](https://twitter.com/wilto)
+* [@MattWilcox](https://twitter.com/MattWilcox)
+* [@aworkinglibrary](https://twitter.com/aworkinglibrary)
+* [@igrigorik](https://twitter.com/igrigorik)
+* [@JennLukas](https://twitter.com/JennLukas)
+* [@karenmcgrane](https://twitter.com/karenmcgrane)
+* [@paul_irish](https://twitter.com/paul_irish)
+* [@meyerweb](https://twitter.com/meyerweb)
+* [@mollydotcom](https://twitter.com/mollydotcom)
+* [@lukew](https://twitter.com/lukew)
+* [@susanjrobertson](https://twitter.com/susanjrobertson)
+* [@adactio](https://twitter.com/adactio)
+* [@Souders](https://twitter.com/Souders)
+* [@lyzadanger](https://twitter.com/lyzadanger)
+* [@beep](https://twitter.com/beep)
+* [@tkadlec](https://twitter.com/tkadlec)
+* [@brucel](https://twitter.com/brucel)
+* [@johnallsopp](https://twitter.com/johnallsopp)
+* [@scottjehl](https://twitter.com/scottjehl)
+* [@jensimmons](https://twitter.com/jensimmons)
+* [@sara_ann_marie](https://twitter.com/sara_ann_marie)
+* [@samanthatoy](https://twitter.com/samanthatoy)
+* [@swissmiss](https://twitter.com/swissmiss)
+* [@LeaVerou](https://twitter.com/LeaVerou)
+* [@stubbornella](https://twitter.com/stubbornella)
+* [@brad_frost](https://twitter.com/brad_frost)
+* [@chriscoyier](https://twitter.com/chriscoyier)
+* [@RWD](https://twitter.com/RWD)
+
+For simplicity's sake these are all twitter links, but have a look at the bio section in each of those links, most of them have blogs you can add to your feed reader as well. 
+
+This list is far from complete, there are thousands and thousands of people I have not listed here, but hopefully this will get you started. Then look and see who these people are following and keep expanding your network.
+
+Okay, now go build something you love. And don't forget to tell us how you did it.
diff --git a/src/old-no-longer-pub/2014-04-26_create-email-courses-mailchimp.txt b/src/old-no-longer-pub/2014-04-26_create-email-courses-mailchimp.txt
new file mode 100644
index 0000000..7beeb91
--- /dev/null
+++ b/src/old-no-longer-pub/2014-04-26_create-email-courses-mailchimp.txt
@@ -0,0 +1,205 @@
+---
+title: Create Email Courses With MailChimp
+pub_date: 2014-04-25 12:04:25
+slug: /blog/2014/04/create-email-courses-mailchimp
+metadesc: How to set up email courses or drip campaigns using MailChimp
+tutorial: True
+
+---
+
+I like to teach people how to do things, whether that's a simple tutorial on this site or a [big ol' book](https://longhandpixels.net/books/responsive-web-design). Lately I've been playing with the idea of a "course" delivered via email. 
+
+I use MailChimp for my mailing lists and it turns out you can also use MailChimp to provide a timed series of tutorials as well, a bit like an email-based course. Basically I wanted a way to take sequential and otherwise related tutorials from this site and package them up in something that can be delivered via email.
+
+While MailChimp can do this, it's not really the primary use case and it was not immediately obvious to me how to do it. MailChimp has great documentation, but it doesn't really cover this use case in detail. The MailChimp admin interface also appears to have changed a lot in the last couple years so many of tutorials out there on the web are no longer completely accurate when it comes to menu locations and such. 
+
+This is how I ended up accomplishing what I wanted to do.
+
+Everything that follows assumes you've used MailChimp before to at least send a newsletter. You'll also need to have a paid account because we're going to create a series of autoresponders, which (at the time of writing) are only available as part of paid accounts.
+
+Before we dive in, here's how I want this to work: When a person signs up for the longhandpixels newsletter there will be a checkbox that says "Yes, I'd also like to receive a free 7-day course on responsive web design" or similar. When someone checks that box I want to 1) add them to the main mailing list and 2) start a series of emails that get delivered once a day for the next seven days. If they don't check that box then they should just be signed up for the main mailing list.
+
+Note that you can do this in some sleazy ways that amount to tricking people into getting a bunch of marketing spam they don't want. Please don't do that. Life is short, don't waste people's time. It will just make people hate you and whatever you're offering. But if you have content people actually want, I think this is a great way to get it to them.
+
+## Create the Form
+
+The first step is to create a sign up form with a custom field that offers the option to also get the email course. To do that click the lists menu item to the left of the page in the MailChimp admin. 
+
+Select the mailing list you want subscribers to end up on (or create a new list). That will take you to the list page where, along the top you'll see a series of tabs, click on "Signup forms". You should see three options, General forms, Embedded forms and Form integrations. Select the middle option, Embedded forms. 
+
+![The link to the form builder](https://longhandpixels.net/media/images/2014/mailchimp-form-builder-link.png){: class="img-right"} You should now be on the form customization page. Here you can build your form however you'd like, the thing we need to do is add an extra field so our potential subscribers can take the 7-day course. To do that we'll use MailChimp's form builder, which you can get to via the link under the Form options menu. 
+
+Now we need to add a new field, so double-click the Check Boxes option on the right, which will add a new checkbox field to your form. You can change the field label to something that makes sense. I ended up not displaying this in the actual form, but it's how this segment of subscribers will be identified in the next step so put something in there that makes sense. I chose "rwd_course". 
+
+You can then set the text in the options box to whatever you'd like. I use "Yes, I'd also like to receive a free 7-day course on responsive web design".
+
+[![MailChimp form builder](https://longhandpixels.net/media/images/2014/mailchimp-form-builder.png)](https://longhandpixels.net/media/images/2014/mailchimp-form-builder.png "View Image 2")
+: Adding a checkbox using MailChimp's form builder
+
+Alright, now go back to the initial form page and grab the embed code. This is curiously difficult to do. I may be missing something, but the only way I know of to get out of the form builder is to click Signup forms again and then once again select the middle option, Embedded forms. From here you can grab the embed code and customize it to your liking. You can see the example at the bottom of this page to see what mine looks like.
+
+## Set up the Email Course
+
+Now we have a way for people to join our mailing list and let us know they want the course. The next step is to set up the actual course.
+
+To do that we'll need to create a series of autoresponders. Click the autoresponders link on the left side of the page and then click the Create Autoresponder button at the top of the page.
+
+This will take you to the first step in the autoresponder setup process, which is essentially exactly the same as setting up your regular mailings, it just has a few extra options that allow you to control when it is sent out.
+
+The first step is to select whichever list you're using. Then we want to narrow the list by selecting the "Send to a new segment" option. Click the drop-down menu and look under Merge fields for the checkbox option we created earlier. Select "rwd_course" (or whatever you named it), "one of" and the only option available.
+
+[![Setting up the list segment in MailChimp](https://longhandpixels.net/media/images/2014/mailchimp-segment-options.png)](https://longhandpixels.net/media/images/2014/mailchimp-segment-options.png "View Image 3")
+: Setting up the list segment in MailChimp
+
+Hit the Next button and you'll see the screen that set what event will trigger the autoresponder and when the mail will be sent. The event we want to start things off with is "subscription to the list". Typically I send a welcome email to everyone who subscribes so I consider this to be first lesson in the course and thus send it one day from when someone signs up. You could, however, use this first autoresponder to send a kind of "thanks for signing up for the course, the first lesson will be here tomorrow" sort of thing, in which case I would set it to send "within the hour" after sign up (which is the shortest time MailChimp offers for autoresponders).
+
+Other options here include the ability to limit which days of the week the mail is sent, for example perhaps not sending your course on weekends. To be honest I haven't touched this yet, but it might be worth tweaking delivery days down the road, based on your response rates.
+
+The next screens are the same as setting up any other campaign in MailChimp, allowing you to customize the mail subject, email, name and other variables. There's plenty of [good documentation](http://kb.mailchimp.com/article/how-do-i-create-a-new-campaign/) on this stuff so I won't repeat it here. See the [MailChimp knowledge base](http://kb.mailchimp.com/home) if you're completely new to MailChimp.
+
+The only thing I'll mention here is that I use a very specific campaign naming structure so I can see the order of emails sent at a glance. Since this will be the first lesson I would name it "RWD Course - Lesson 01". Without the sequential naming scheme it's impossible to look at a list of your autoresponders and know which one is which lesson.
+
+From here you just add your first lesson, pick a nice theme and start up the autoresponder. 
+
+So you have the form set up, and anyone who signs up will get lesson one delivered to their inbox a day later. 
+
+Now you just need to rinse and repeat. Like I said, this is a little outside the typical MailChimp use case so unfortunately there's no simpler way to do it. Luckily you can save a bit of time if you go back to the Autoresponders list page (by clicking the autoresponer link in the left-hand menu) and click on the Edit drop down button where you'll see an option to "Replicate". 
+
+This will essentially clone your autoresponder, keeping everything the same so all you have to change is the subject line, the autoresponder name (now "RWD Course - Lesson 02" or similar) and the actual content. Don't forget to force the plain text content to update as well since it won't, for some reason, always auto-update when you change the HTML content.
+
+Then replicate again. And again. And so on. You can start to see why Nathan Berry is doing well with [ConvertKit](http://convertkit.com/) (which greatly streamlines this process). I don't mind the extra steps, and I like to keep everything in one place so I'm sticking with MailChimp even if my attempts to create email courses are a little outside the usual use case.
+
+Be sure to let me know if you have any questions and if you'd like to see my responsive design course in action, here's the signup form:
+
+<div class="form--wrapper">
+<style>
+.input--button, .package--button {
+  display: block;
+  background-color: #d05c1c;
+  background-image: -moz-linear-gradient(bottom, #d05c1c, #e26f30);
+  background-image: -webkit-linear-gradient(bottom, #d05c1c, #e26f30);
+  background-image: linear-gradient(to top bottom, #d05c1c, #e26f30);
+  -ms-filter: "progid:DXImageTransform.Microsoft.gradient (GradientType=0, startColorstr=#d05c1c, endColorstr=#e26f30)";
+  padding: 15px 25px;
+  color: #fff !important;
+  margin-bottom: 10px;
+  font-weight: normal;
+  border: 1px solid #c14b0b;
+  border-radius: 5px;
+  text-decoration: none;
+  box-shadow: 0px 0px 3px rgba(0, 0, 0, 0.19), 0px 1px 0px rgba(255, 255, 255, 0.34) inset, 0px 0px 10px rgba(0, 0, 0, 0.05) inset; }
+.form--wrapper {
+  padding: 2em 0; }
+
+.form--wrapper form {
+  margin: 0 auto;
+  max-width: 18.75em;
+font-family: "HelveticaNeue-Light", "Helvetica Neue Light", "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;
+  clear: both; }
+  @media (min-width: 32em) {
+    .form--wrapper form {
+      float: right;
+      clear: none;
+      max-width: 15em; } }
+  @media (min-width: 47em) {
+    .form--wrapper form {
+      max-width: 23.75em; } }
+
+.form--fieldgroup {
+  margin-bottom: 1em; }
+
+label {
+  display: block;
+  font-size: 12px;
+  font-size: 0.75rem;
+  font-weight: 600; }
+
+.label--inline {
+  display: inline-block;
+  margin-left: 8px;
+  max-width: 21.875em; }
+
+.input--check {
+  float: left;
+  margin: 0; }
+
+.input--textfield {
+  width: 15.3125em; }
+  @media (min-width: 32em) {
+    .input--textfield {
+      max-width: 13.125em; } }
+  @media (min-width: 47em) {
+    .input--textfield {
+      max-width: 17.1875em; } }
+
+.input--button {
+  max-width: 250px; }
+  @media (min-width: 32em) {
+    .input--button {
+      max-width: 15em; } }
+  @media (min-width: 47em) {
+    .input--button {
+      max-width: 250px; } }
+
+.input--button__sample {
+  max-width: 280px; }
+
+.form--small {
+  font-size: 90%; }
+
+.img-open-book {
+  margin: 0 auto 2em;
+  display: block; }
+  @media (min-width: 32em) {
+    .img-open-book {
+      float: left;
+      width: 48%;
+      margin-right: 1em; } }
+.form--wrapper:before,
+.form--wrapper:after {
+  content:"";
+  display:table;
+}
+.form--wrapper:after {
+  clear:both;
+}
+.form--wrapper {
+  zoom:1; /* For IE 6/7 (trigger hasLayout) */
+}
+.form--small {
+font-size: 73% !important;}
+</style>
+<img alt="Build A Better Web With Responsive Design by Scott Gilbertson" src="https://longhandpixels.net/books/media/sample-chapter-image.png" class="img-open-book">
+ <!-- Begin MailChimp Signup Form -->
+<form action="https://longhandpixels.us7.list-manage.com/subscribe/post?u=f56776029b67b1c8c712eee00&amp;id=040927f84d" method="post" id="mc-embedded-subscribe-form" name="mc-embedded-subscribe-form" class="validate" target="_blank" novalidate="">
+
+<div class="form--fieldgroup">
+<label for="mce-FNAME">First Name </label> <input type="text" value="" name="FNAME" class="input--textfield" placeholder="Jane Doe" id="mce-FNAME" style="background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAABHklEQVQ4EaVTO26DQBD1ohQWaS2lg9JybZ+AK7hNwx2oIoVf4UPQ0Lj1FdKktevIpel8AKNUkDcWMxpgSaIEaTVv3sx7uztiTdu2s/98DywOw3Dued4Who/M2aIx5lZV1aEsy0+qiwHELyi+Ytl0PQ69SxAxkWIA4RMRTdNsKE59juMcuZd6xIAFeZ6fGCdJ8kY4y7KAuTRNGd7jyEBXsdOPE3a0QGPsniOnnYMO67LgSQN9T41F2QGrQRRFCwyzoIF2qyBuKKbcOgPXdVeY9rMWgNsjf9ccYesJhk3f5dYT1HX9gR0LLQR30TnjkUEcx2uIuS4RnI+aj6sJR0AM8AaumPaM/rRehyWhXqbFAA9kh3/8/NvHxAYGAsZ/il8IalkCLBfNVAAAAABJRU5ErkJggg==); background-attachment: scroll; background-position: 100% 50%; background-repeat: no-repeat no-repeat;">
+</div>
+<div class="form--fieldgroup">
+<label for="mce-EMAIL">Email Address</label> <input type="email" autocapitalize="off" autocorrect="off" value="" placeholder="jane@doe.com" name="EMAIL" class="input--textfield" id="mce-EMAIL">
+</div>
+<div class="form--fieldgroup">
+<label for="mce-group[5529]-5529-0" class="label--inline">Yes, I’d also like to receive a free 7-day course on responsive web design.</label><input type="checkbox" value="1" name="group[5529][1]" id="mce-group[5529]-5529-0" class="input--check" checked="">
+</div>
+<div style="position: absolute; left: -5000px;">
+<input type="text" name="b_f56776029b67b1c8c712eee00_040927f84d" value="">
+</div>
+<input type="submit" value="Send Me the Sample Chapter" name="subscribe" id="mc-embedded-subscribe" class="input--button input--button__sample">
+<p class="form--small">
+<small>We won’t send you spam. Unsubscribe at any time.</small>
+</p>
+</form>
+</div>
+
+And seriously, don't create spammy drip campaigns no one wants to read.
+
+##Further Reading
+
+* [MailChimp.com - Getting Started Autoresponders: An Experiment in Empowerment](http://blog.mailchimp.com/getting-started-autoresponders-an-experiment-in-empowerment/)
+* [MailChimp.com - Advanced customization of MailChimp's signup forms](http://kb.mailchimp.com/article/advanced-customization-of-mailchimps-sign-up-forms)
+* [MailChimp.com - Drip Email Campaigns – Setting Expectations](https://blog.mailchimp.com/drip-email-campaigns-setting-expectations/)
+* [Smashing Magazine - How To Create A Self-Paced Email Course](http://www.smashingmagazine.com/2014/02/10/how-to-create-a-self-paced-email-course/)
+* [ryandoom.com - Setting up a drip email campaign with MailChimp](http://www.ryandoom.com/Blog/tabid/91/ID/26/Setting-up-a-drip-email-campaign-with-MailChimp.aspx)
+{^ .list--indented }
+
diff --git a/src/old-no-longer-pub/2014-05-16_should-you-wrap-headers-images-and-text-links.txt b/src/old-no-longer-pub/2014-05-16_should-you-wrap-headers-images-and-text-links.txt
new file mode 100644
index 0000000..853275f
--- /dev/null
+++ b/src/old-no-longer-pub/2014-05-16_should-you-wrap-headers-images-and-text-links.txt
@@ -0,0 +1,39 @@
+---
+title: Should You Wrap Headers, Images and Text Together in Links?
+pub_date: 2014-05-16 12:04:25
+slug: /blog/2014/05/should-you-wrap-headers-images-and-text-links
+metadesc: What happens when you wrap large amounts of text and images in link tags?
+code: True
+
+---
+
+Question marks in headlines are a pet peeve of mine because the answer is [almost always](https://twitter.com/YourTitleSucks), "no". In this case though, I'm genuinely not sure. 
+
+[Update 2014-07-16: I lean toward no for situations with a large amount of text since it makes selecting that text really hard on mobile devices]
+
+Matt Wilcox asked an interesting [question on Twitter](https://twitter.com/MattWilcox/status/467251442307567616) today:
+
+> A11y question: we now often wrap headers and paras and images all in one `<a/>`... Makes sense, but how does that impact screen reader users?
+
+And [the follow up](https://twitter.com/MattWilcox/status/467251958387331072):
+
+> This is a good way to avoid having to link an image, header, and ‘read more’ with three identical URLs, but how are wrapped links read out?
+
+Just in case you didn't know, HTML5 allows you to put just about anything inside an `<a>`, which means you can do things like this:
+
+~~~language-markup
+<a href="#">
+    <article>
+        <h1>My Article Title</h1>
+        <img src="" alt="some related image" />
+        <time datetime="2014-05-15T19:43:23">05/15/14</time>
+        <p>Paragraph text. Couple be multiple 'grafs, could be dozens. Could be just about anything really.</p>
+    </article> 
+</a>
+~~~
+
+This eliminates the need have three separate links around the title, image and perhaps a "read more" link.
+
+But as Wilcox points out, there might be unanticipated consequences that make this not such a good idea in terms of accessibility, and even usability (not sure there's a real distinction there). For example, any text becomes <strike>impossible</strike> very difficult to select, which makes me hesitate to use this technique in this particular case. There may be cases where that isn't a major problem.
+
+I threw together a [test page](https://longhandpixels.net/demos/large-text-a11y/) that I can run through [ChromeVox](http://www.chromevox.com/) and OS X's VoiceOver (the two screen readers I have access to) and see what happens. But I don't use a screen reader on a regular basis so it's hard to know what works and what doesn't, other than obviously very annoying stuff. If you use a screen reader or have a means to test this scenario on other screen readers, I'd love to hear from you.
diff --git a/src/old-no-longer-pub/2014-10-03_using-picture-vs-img.txt b/src/old-no-longer-pub/2014-10-03_using-picture-vs-img.txt
new file mode 100644
index 0000000..3c2d39c
--- /dev/null
+++ b/src/old-no-longer-pub/2014-10-03_using-picture-vs-img.txt
@@ -0,0 +1,72 @@
+---
+title: "`<picture>` Is Not the Element You're Looking For"
+pub_date: 2014-09-30 09:30:23
+slug: /blog/2014/09/picture-not-the-element-youre-looking-for
+tags: Responsive Images, Responsive Web Design
+metadesc: Most of the time the <picture> element is not what you want, just use img. Your users will thank you.
+code: True
+tutorial: True
+
+---
+
+The `<picture>` element will be supported in Chromium/Chrome/Opera stable in a few weeks. Later this year it will be part of Firefox. Some of it is already available in Safari and Mobile Safari. It's also top of IE12's to-do list. 
+
+The bottom line is that you can start using `<picture>`. You can polyfill it with [Picturefill][1] if you want, but since `<picture>` degrades reasonably gracefully I haven't even been doing that. I've been using `<picture>`.
+
+Except that, as Jason Grigsby recently pointed out, you probably [don't need `<picture>`][2]. 
+
+See, two of the most useful attributes for the `<picture>` element also work on the good old `<img>` element. Those two attributes are `srcset` and `sizes`.
+
+In other words, this markup (from, [A Complete Guide to the `<picture>` Element][3])...
+
+~~~{.language-markup}
+<picture>
+    <source media="(min-width: 48em)" srcset="pic-large1x.jpg 800w, pic-large2x.jpg 800w 2x">
+    <source media="(min-width: 37.25em)" srcset="pic-med1x.jpg 400w, pic-med2x.jpg 400w 2x">
+    <source srcset="pic1x.jpg 200w, pic2x.jpg 200w 2x">
+    <img src="pic1x.jpg" alt="Responsive Web Design cover">
+</picture>
+~~~
+
+...will do nearly the same things as this markup that doesn't use `<picture>`:
+
+~~~{.language-markup}
+<img sizes="(min-width: 48em) 100vw,
+			(min-width: 37.25em) 50vw,
+			calc(33vw - 100px)"
+	srcset="pic-large1x.jpg 800w,
+			pic-large2x.jpg 800w 2x,
+			pic-med1x.jpg 400w,
+			pic-med2x.jpg 400w 2x,
+			pic2x.jpg 200w 2x,
+			pic1x.jpg 200w"
+    src="pic1x.jpg" alt="Responsive Web Design cover">
+~~~
+
+The main difference between these two lies in the browser algorithm that ends up picking which image to display.
+
+In the first case, using the `<source>` tag means the browser **MUST** use the first source that has a rule that matches. That's [part of the `<picture>` specification][4].
+
+In the second bit of code, using the `sizes` and `srcset` attribute on the `<img>` tag, means the browser gets to decide which image it thinks is best. **When you use `<img>` the browser can pick the picture as it sees fit**. Avoiding the `<source>` tag allows the browser to pick the image via its own algorithms. 
+
+That means the browser can respect the wishes of your visitor, for example, not downloading a high resolution image over 3G networks. It also allows the browser to be smarter, for example, downloading the lowest resolution image until the person zooms in, at which point the browser might grab a higher resolution image.
+
+Generally speaking, the only time you need to use `<picture>` is when you're handling [the "art direction" use case][5], which, according to `<picture>` guru Yoav Weiss is [currently around 25 percent of the time][6]. 
+
+The rest of the time, the majority of the time, stick with `<img>`, your users will thank you.
+
+## Further Reading
+
+* [Don't use `<picture>` (most of the time)](http://blog.cloudfour.com/dont-use-picture-most-of-the-time/)
+* [A Complete Guide to the `<Picture>` Element](https://longhandpixels.net/blog/2014/02/complete-guide-picture-element)
+* [Native Responsive Images](https://dev.opera.com/articles/native-responsive-images/)
+* [Srcset and sizes](http://ericportis.com/posts/2014/srcset-sizes/)
+{^ .list--indented }
+
+
+[1]: http://scottjehl.github.io/picturefill/
+[2]: http://blog.cloudfour.com/dont-use-picture-most-of-the-time/
+[3]: https://longhandpixels.net/blog/2014/02/complete-guide-picture-element)
+[4]: https://html.spec.whatwg.org/multipage/embedded-content.html#select-an-image-source
+[5]: http://usecases.responsiveimages.org/#h3_art-direction
+[6]: http://blog.yoav.ws/2013/05/How-Big-Is-Art-Direction
diff --git a/src/old-no-longer-pub/2014-10-10_lenovo-chromebook-review.txt b/src/old-no-longer-pub/2014-10-10_lenovo-chromebook-review.txt
new file mode 100644
index 0000000..e4b6bca
--- /dev/null
+++ b/src/old-no-longer-pub/2014-10-10_lenovo-chromebook-review.txt
@@ -0,0 +1,86 @@
+---
+title: "Review: The Lenovo n20p Chromebook"
+pub_date: 2014-10-10 09:30:23
+slug: /blog/2014/10/lenovo-n20p-chromebook-review
+metadesc: A follow up to my Wired review, aimed at those curious about running Linux on Chromebooks
+
+---
+
+I've been testing some Chromebooks for Wired. My first review is the [Lenovo n20p][1].
+
+Here's the part I can't fit into the allotted 750 words: I'm not at all interested in these devices when they're running Chrome OS[^1]. 
+
+I'm interested in Chromebooks because they're cheap and they're hackable. I'm interested in them because for $200-$300 you can get what amounts to an underpowered ultrabook. My ideal laptop is cheap, light, and long lasting. Chromebooks deliver on all three counts, which means I can take the $800-$1000 I would have spent on an actual ultrabook and put it to better use in the world.
+
+Chrome OS, however, is not for me. I need a terminal. I want to run shell scripts and apps like Vim, Mutt, Python, Pandoc, etc. I also want a RAW image editor. And I want to use the browser of my choice. 
+
+In other words, I want Linux on my Chromebook, otherwise all bets are off, which is why I'm putting up this little addendum to my Wired review -- for anyone else who's curious to hear what Linux is like on a $200 laptop. 
+
+Spoiler alert: It's surprisingly awesome, though you need to make sure you get the right hardware for what you want to do.
+
+## The Lenovo n20p
+
+I hope it's clear from the Wired review that I do not recommend you buy the Lenovo n20p unless you really, really want the touchscreen features. Otherwise the screen is a deal breaker. It's also overpriced relative to other Chromebooks and short on RAM.
+
+Let me reiterate that first point here: the screen is awful. Completely, utterly awful. Sure it's a touch screen, which is good, because it's not much of visual screen. There are far better screens on Chromebooks that retail for $100 less. I'm typing this right now in Vim, using the [Solarized][2] dark] color scheme and I can barely see the words on the screen. It's that bad. 
+
+Still, this is the first Chromebook I've had to experiment with so I installed and have been using Debian GNU/Linux on it. I opted for the Xfce desktop since it's somewhat lighter than GNOME[^2].
+
+Debian runs really well on this machine when booted through the [Crouton project][3]. Crouton is not secure and I don't recommend actually using it full time, but it's not bad for testing. The better option would be to dual boot through the [SeaBIOS firmware][4] (or ditch Chrome OS entirely) but I'm not sure SeaBIOS is included with this hardware. I'm sending this device back to Lenovo; I don't want to brick a loaner machine installing alternate firmware. 
+
+## The Strange Story of Performance
+
+In the Wired review I mentioned that with Chrome OS I got about 6 hours of battery life doing normal stuff -- browsing the web, streaming audio and video, writing and so on. With Xfce on top of Debian on the same machine I get 8 sometimes 9 hours. I have no explanation for this other than perhaps Linux has better power management...? If that's true, Chrome OS is really lagging here because Linux has pretty shitty power management in my experience. Whatever the case Xfce routinely outdid Chrome OS in battery life.
+
+But wait, it gets weirder. In the Wired review I mentioned that the Lenovo bogs down considerably when you open more than 10 or so tabs (sad for 2GB of RAM, but that's just how it is). For example, open a few YouTube videos, Google Docs, a web-based email app and few dozen more and scrolling starts to stutter and switching tabs is noticeably sluggish. Do the very same thing in Chromium running on Debian and you get nothing of the sort.
+
+I have no explanation for this either, especially because Crouton means Chrome OS is still running alongside Debian. While performance should be on par, exceeding Chrome OS is difficult to explain. But hey, good news for those who want to run Linux on a Chromebook. 
+
+So, what's it like to try something moderately taxing, in my case, editing RAW images in Darktable? And can you record a decent screencast? How about editing video? The answers are, it's not that bad, yes and yes but it will take longer. Which is to say that I found the Lenovo to be plenty snappy considering it's only 2GB of RAM and a Celeron processor.
+
+I did not load my entire photo library (remember there's only a 16GB SSD), but I did throw about 5 GB of photos in it and Darktable wasn't much slower than on my MacBook Pro, which has 16GB of RAM. Browsing through large folders of images sometimes caused jumpy scrolling and thumbnails took longer to generate and come into view, but it was not nearly as horrible as I expected. In fact it was totally usable, other than the screen.
+
+I didn't really understand how bad the screen sucks on the n20p until I tried to edit a photo. It was a washed out joke. Whole tonal ranges that Darktable was offering to adjust simply didn't show up in the image on the screen. 
+
+I record a lot of screencasts and edit video a fair bit. I tested both on the Lenovo and am happy to report that it's possible, though exporting your edited HD video of any length will be something you're better off starting shortly before you head to bed. Which is to say it works fine, it just takes longer.
+
+## Hardware Problems 
+
+Overall I was quite happy with the n20p's hardware, save the screen. The keyboard is one the best I've used on a small device. There is a proprietary power jack, which is annoying if you want to have two -- there's no borrowing a compatible cable from another device.
+
+Another potential annoyance for Linux users is that the SD card doesn't sit flush, which means you can't leave it in and use it as a second drive. Regrettably this seems to be the overall trend in current laptop design, so not like Lenovo are the only ones doing this, but it still sucks. 
+
+I made a half-hearted attempt to crack open the case and see what the RAM/SSD upgrade potential is, but the case did not open easily and since I have to get it back to Lenovo in one piece I didn't push it. Also, the screen. Deal breaker.
+
+## Software Problems
+
+I couldn't get Xmodmap to remap the search key (what would be the caps lock key on most laptops) to control. I have no doubt it can be done, but my first attempt did not work and I didn't feel like spending the time to debug it. I doubt this is a hardware problem though since others have managed to get it working on Chromebooks, just a warning that your current .Xmodmap file might not work on a Chromebook.
+
+I also encountered some problems getting unicode characters to display properly. I've never had this problem with Xfce before but I doubt it was hardware related. I also somehow ended up with the xfce4-mixer needing to run as root to work, which can be fixed by uninstalling and reinstalling.
+
+Most of these things can probably be attributed to my own ignorance than anything directly related to the Chromebook/Linux experience.
+
+## Conclusion
+
+Don't buy the Lenovo n20p as a hackable Linux Chromebook.
+
+That said, Linux on a Chromebook is awesome. Or at least it has the potential to be. 
+
+I want this to be my only computer. For that I want an HD IPS screen. There are a couple Chromebooks on the market now with better screens, which is encouraging. I'd also want a Chromebook with an upgradable SSD (like the Acer 720 line). 
+
+In an ideal world there would be a way to upgrade to 8GB of RAM, but it seems that soldered RAM is becoming more common. On the plus side, I now know I can get by with 4GB and this revolutionary new technology called patience. I'd also love to see an SD card slot that accommodates the entire card so it can act as a second drive, but this seems to be the thing least likely to actually happen.
+
+Currently all these things exist, but not in a single machine. Like I said in the Wired article, at this point the best Chromebook is an impossible Frankenbook. That means there has to be some compromise or some patience. I'm opting for the latter. I'd be willing to bet though that when CES rolls around next year there will be some very tempting Chromebooks available.
+
+I'll follow this up with more thoughts when the next review is up on Wired (which will likely be the 13in NVIDIA Tegra-based Acer).
+
+
+[^1]: I don't believe the deal Google offers -- all your data in exchange for free, useful services -- is a good exchange. They get more than I do out of that. But I am privileged to know how to host things myself and I can afford to pay for services like Fastmail. Most people, unfortunately, are not as privileged, something I try to be mindful of when suggesting whether or not you should use a particular technology.
+
+[^2]: Something like Openbox or Xmonad would be even lighter, but requires a bit more work to install through Crouton. I went with the lightest of the easy-to-install options available in Crouton.
+
+
+[1]: http://www.wired.com/2014/10/lenovo-n20p-chromebook/
+[2]: http://ethanschoonover.com/solarized
+[3]: https://github.com/dnschneid/crouton/
+[4]: http://www.coreboot.org/SeaBIOS
diff --git a/src/old-no-longer-pub/2014-10-28_google-progressive-enhancement.txt b/src/old-no-longer-pub/2014-10-28_google-progressive-enhancement.txt
new file mode 100644
index 0000000..8008e41
--- /dev/null
+++ b/src/old-no-longer-pub/2014-10-28_google-progressive-enhancement.txt
@@ -0,0 +1,31 @@
+---
+title: Google Recommends Progressive Enhancement
+pub_date: 2014-10-28 09:30:23
+slug: /blog/2014/10/google-progressive-enhancement
+metadesc: Google has updated its webmaster tools guidelines to suggest developers use progressive enhancement.
+
+---
+
+Just in case you don't subscribe to the [Longhandpixels newsletter][1] (for shame, sign up in the footer :-)), Google recently [updated its Webmaster Guidelines][2] to suggest that developers use progressive enhancement. 
+
+Here's the quote:
+
+>Just like modern browsers, our rendering engine might not support all of the technologies a page uses. Make sure your web design adheres to the principles of progressive enhancement as this helps our systems (and a wider range of browsers) see usable content and basic functionality when certain web design features are not yet supported.
+
+As a fan of progressive enhancement ever since the term first appeared on Webmonkey eons ago, I would like to say thank you to Google. Thank you for throwing your weight behind progressive enhancement.
+
+I consider progressive enhancement the cornerstone on which all web design builds (literally and figuratively), but I also know from painful experience that not every developer agrees. I also know nothing shuts up a web developer faster than saying, *well, Google says...*
+
+What makes Google's announcement even more interesting is that it comes in the middle of a post that's actually telling developers that Google spiders will now render CSS and JavaScript. Even as Google's spiders get smarter and better at rendering pages the company still thinks progressive enhancement is important. 
+
+If you're scratching your head wondering what progressive enhancement is, well, you can go read Steve Champeon’s [original Webmonkey article][3] for some background and then check out Aaron Gustafson's [ALA article from 2008][4]. 
+
+If you're interested in how progressive enhancement works in conjunction with responsive design, pick up a copy of my book, <cite>[Build a Better Web with Responsive Design][5]</cite>. I published an excerpt that covers some aspects of progressive enhancement, responsive design and [Why mobile-first is the right way to build responsive websites][6], if you'd like to get a feel for what I'm talking about.
+
+
+[1]: https://longhandpixels.net/newsletter/
+[2]: http://googlewebmastercentral.blogspot.com/2014/10/updating-our-technical-webmaster.html
+[3]: http://hesketh.com/publications/progressive_enhancement_and_the_future_of_web_design.html
+[4]: http://alistapart.com/article/understandingprogressiveenhancement
+[5]: https://longhandpixels.net/books/responsive-web-design
+[6]: https://longhandpixels.net/blog/2014/04/why-mobile-first-responsive-design
diff --git a/src/old-no-longer-pub/2015-01-15_google-mobile-friendly-label.txt b/src/old-no-longer-pub/2015-01-15_google-mobile-friendly-label.txt
new file mode 100644
index 0000000..58aa108
--- /dev/null
+++ b/src/old-no-longer-pub/2015-01-15_google-mobile-friendly-label.txt
@@ -0,0 +1,34 @@
+---
+title: Google Calls Out 'Mobile-Friendly' Sites
+pub_date: 2015-01-15 09:30:23
+slug: /blog/2015/01/google-mobile-friendly-label
+metadesc: Google is now labeling mobile-friendly sites in search results and mobile-unfriendliness may soon hurt your search engine rankings
+
+---
+
+Google has started adding a "mobile-friendly" label next to search results on mobile devices. 
+
+<img src="/media/images/2015/google-mobile-friendly.png" alt="Google's new mobile friendly label">
+
+As a user I love this [^1], and I'll be honest, I'd be pretty unlikely to click through to a site that doesn't get this label -- what's the point? Even if the site is the sole source of whatever I want there's a good chance I won't be able to view it on my phone.
+
+As a web developer I want to make sure my sites get that little "mobile-friendly" label. Here's Google's criteria for what makes a website "mobile-friendly":
+
+>* Avoids software that is not common on mobile devices, like Flash
+>* Uses text that is readable without zooming
+>* Sizes content to the screen so users don't have to scroll horizontally or zoom
+>* Places links far enough apart so that the correct one can be easily tapped
+
+The first is hopefully obvious at this point. The third item is just basic responsive design 101. The others though are things that don't get nearly enough attention in responsive web design. Text big enough to read and links you can tap *should* be key elements of any good responsive design, but sadly, at least in my mobile browsing experience, they aren't.
+
+I'm happy to see Google start to label sites that fail on these counts and I hope it motivates developers to start taking the smaller, but still very important aspects of responsive design -- like typography and white space -- more seriously. 
+
+I'm also happy that the mobile-friendliness of a site may become a factor in how it ranks in search results. According [the Google Webmaster Blog](http://googlewebmastercentral.blogspot.com/2014/11/helping-users-find-mobile-friendly-pages.html), Google sees the "mobile-friendly" labels as "a first step in helping mobile users to have a better mobile web experience. ***We are also experimenting with using the mobile-friendly criteria as a ranking signal***. (emphasis mine).
+
+<img src="/media/images/2015/google-mobile-friendly-lhp.jpg" alt="Longhandpixels gets the mobile friendly label">
+
+There's a [test page](https://www.google.com/webmasters/tools/mobile-friendly/) where you can see how your sites do. This one gets the mobile-friendly label, natch.
+
+<div class="callout"><h3>Need help getting to "mobile-friendly"?</h3> <img src="/media/rwd-cover.png" alt="book cover" />The book <a href="https://longhandpixels.net/books/responsive-web-design">Build a Better Web with Responsive Web Design</a> is the fastest way to get from here to responsive. You'll learn the best ways to scale fonts with screen size and make sure your tap targets are big enough for comfortable browsing. Read the book, follow the suggestions and your site will be "mobile-friendly".</div>
+
+[^1]: I really wish DuckDuckGo would do this as well since I use it quite a bit more than Google these days.
diff --git a/src/old-no-longer-pub/2015-10-03_wordpress-1.txt b/src/old-no-longer-pub/2015-10-03_wordpress-1.txt
new file mode 100644
index 0000000..846f751
--- /dev/null
+++ b/src/old-no-longer-pub/2015-10-03_wordpress-1.txt
@@ -0,0 +1,48 @@
+WordPress is pretty universally reviled among programmers. It's more or less the Walmart of code. A lot of the core code is very poorly written and in a language no one likes. That's never bothered me. What I don't like is that it encourages mixing presentation code and logic. It also encourages terrible behavior by users[^1] and is at least partly responsible for how damn slow the web has become[^2].
+
+WordPress is also often the best choice for clients. 
+
+Why is something so awful often the best choice? Because clients have budgets and paying me to set up and lightly customize WordPress is dramatically cheaper than paying me to write you something totally custom (and really awesome) using Django or Rails. Budgets are part of reality and with WordPress -- in spite of all that's wrong with it -- the client's money goes further[^3].
+
+WordPress is also fantastically good at some things. The admin is generally very usable and thoughtfully created; the comment system is hands down the best of the web and it has helped millions, possibly billions of people get their ideas on the web. 
+
+That does not, however, explain why *I* was able to get past my dislike of WordPress. My dislike of WordPress centers around the way it mixes logic -- PHP code in this case -- and presentation (HTML). It's a terrible way to work and terrible thing to try to maintain. 
+
+I want all my code in one file, all my HTML in another. The code file uses logic to get the information needed and put it in variables. It then passes those variables to the HTML which displays them and all is well. That's how pretty much every thing designed for the web since about 1999 has worked. Except for WordPress.
+
+I've built dozens of WordPress sites over the years and for most of that time I've hated every minute of it, which, trust me, is no way to make a living. 
+
+All that changed about 4 months ago when I discovered [Timber](https://github.com/jarednova/timber). Timber is a plugin that lets you develop WordPress themes using object-oriented code and the [Twig template engine](http://twig.sensiolabs.org/).
+
+Timber takes all that is bad about WordPress's coding style and enables the kind of clean, sane separation of code web developers are used to. It makes WordPress behave a bit more like Rails or Django.
+
+More importantly, it lets me build WordPress sites without hating every minute of it. I actually like building WordPress sites using Timber. It's not as much fun as using Django, but it's close enough that I ported this site over to WordPress (from a custom Python-based static publishing system).
+
+A couple things to note if this sounds good to you. First, yes, Timber is a WordPress plugin. No, from my testing, it won't slow your site down. But yes, it does introduce a dependency on which all your code will hang. Porting from Timber to non-Timber will be non-trivial. Make sure you're okay with that before you dive in. 
+
+To give you some sense of what it's like to work with Twig, here's what your template code looks like:
+
+~~~.language-markup
+{% extends "base.twig" %}
+{% block content %}
+<article class="h-entry">
+<h1 class="p-name">{{post.title}}</h1>
+<img src="{{post.thumbnail.src}}" alt="image alt text" />
+<div class="body">
+    {{post.content}}
+</div>
+{% endblock %}
+~~~
+
+Yes, that looks a lot like Django template code. The Twig templating system is based on Django's (so is nearly every other templating project I've come across lately. Django is  not perfect, but its template system is clearly pretty close).
+
+You still create .php files with Timber, they're just all logic. You instantiate Timber objects and then query for whatever posts/pages/custom post type data you want. Then you pass that on to the template file. Again, that will probably sound familiar to most non-WordPress developers.
+
+Who cares? Well, if you hate WordPress because of the way it forces you to mix logic and presentation code then Timber might make your life a bit brighter. If you're perfectly happy with WordPress as is, then why the hell are you still reading this?
+
+
+[^1]: For a long time the WordPress Codex actually said that your wp-content folder was "intended by Developers to be completely writable by all (owner/user, group, and public)." Yup, seriously. It's since been changed, so congrats to the WordPress team on cracking open [Internet Security for Dummies](http://www.amazon.com/Norton-Internet-Security-Dummies-Computers/dp/0764575775), but here's the [Internet Archive page](https://web.archive.org/web/20110325073349/http://codex.wordpress.org/Hardening_WordPress) of that advice in case you don't believe me.
+
+[^2]: WordPress supposedly powers about a 1/3 of the web so that alone makes it responsible. But search the web for almost any problem with WordPress and the first bit of advice you'll get is "just install ______ plugin". That's great on one hand, because you don't need to know any code, but because of how WordPress bootstraps plugins it also tends to slow sites to a crawl (and load dozens of external scripts in many cases).
+
+[^3]: WordPress is also more widely used and therefore there are more people capable of maintaining it. That means clients have a more future-proof solution than a customized system written in Python or Ruby.
-- 
cgit v1.2.3-70-g09d2