6 ms·

Show HN: CSS Quality Guide

49 points by bevacqua 11y ago

handonam 11y ago
Why not look at BEM? https://en.bem.info/ https://en.bem.info/ http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/ http://csswizardry.com/2013/01/mindbemding-getting-your-head... Harry Roberts really simplifies the idea of it.
matthewbauer 11y ago
Most style guides say to use namespaces for everything. I've never used them. What do I have to be worried about?
- mikewhy 11y ago
  If you have say a post entry: .post { border: 1px solid #000; } .post .title { font-weight: bold; } And you want to put it into a sidebar .sidebar { background-color: #ccc; } .sidebar .title { text-decoration: underline; } That post's title is now going to be underlined. That's one of the reasons for namespacing. If the classes were `.post--title` and `.sidebar--title`, this would be avoided
  - austinlyons 11y ago
    Wouldn't you just instead write the CSS as follows? .sidebar.title { text-decoration: underline; }
    - talmand 11y ago
      That likely wouldn't have the intended effect as I find it doubtful that the element with the sidebar class would also be the title.
    - lstamour 11y ago
      Well, you could also write .sidebar > .title to be more specific than simply all .title elements in .sidebar, but the point is to not tie your CSS quite so closely to the HTML hierarchy I suppose.
  - talmand 11y ago
    I had an explanation as to why your CSS was wrong but then I realized an HTML example is needed. I'm assuming you mean something like this: <section class='content'> <div class='post'> <h1 class='title'></h1> </div> </section> <section class='sidebar'> <div class='post'> <h1 class='title'></h1> </div> </section> If so, what you say would indeed happen. Also, I've never thought of .post--title as a form of namespacing. I always understood it to be more like .post .title, as in nesting with SCSS or Less. Not saying you're wrong, just never thought of it that way.
  - armandososa 11y ago
    I've found that these cases are non-issues when you use something like BEM. The downside is that the HTML then becomes horrible to look at: <div class='sidebar'> <div class='sidebar__post'> <h2 class='sidebar__post__title'> Please kill me </h2> </div> </div> So… you have to chose between unmaintainable CSS or weird HTML. I think that, in the end, something like this is the only sane outcome: https://medium.com/seek-ui-engineering/the-end-of-global-css-90d2a4a06284 https://medium.com/seek-ui-engineering/the-end-of-global-css...
    - mikewhy 11y ago
      I probably wouldn't go so far as to use `sidebar__post__title `, just `sidebar--title` and `post--title`. That way if you want to style a post title in the sidebar, it's clearly `.sidebar .post--title` using something like BEM solves a lot of problems. Silly collisions and searchability are my big takeaways.
  - jt2190 11y ago
    If not underlining post titles is so important, than the CSS rule should make that explicit: .post .title { font-weight: bold; text-decoration: none; } Leaving text-decoration out of the rule is basically saying: "I defer to my ancestor rules for advice on styling this, and I accept their decision."
    - mikewhy 11y ago
      It's not just that the post titles shouldn't be underlined, it's that one elements style should not creep into another elements style by accident
      - marcosdumay 11y ago
        Well, the "all descendants" selector is explicitly intended to do that. It's a bit too far to call it "by accident". There's rarely a real use for the ".sidebar .title" construction.
        talmand 11y ago
        Rarely? I would think the vast majority of websites would have a version of that in place in several ways.
- lstamour 11y ago
  If you use SCSS and group your CSS by, e.g. a class in the body tag and additional nesting for components, or if your component-specific styles are loaded only when necessary (e.g. HTTP/2) then not much. The purpose of these techniques, or of prefixing your class names, is to avoid naming collisions. E.g. is your list supposed to have bullets? If you just say ul { list-style: none; } you've effectively said all lists shouldn't. But you might later say the opposite and not notice until your stylesheets are all compiled together and it's a race to see which one wins on every page. Or the other example posted (above, since this comment was downvoted for unknown reasons) where you move HTML around and your stylesheets aren't in sync. Of course, prefixing isn't for everyone -- e.g. https://github.com/twbs/bootstrap/issues/1235 https://github.com/twbs/bootstrap/issues/1235 -- some argue you should know all the styles on your page and how they interact, even if using a "CSS framework" and so naming collisions is just one of the things you'll have to worry about -- if you namespace, what's to prevent a naming collision even with your namespaces? :) This is also where it might be useful to point to https://speakerdeck.com/vjeux/react-css-in-js https://speakerdeck.com/vjeux/react-css-in-js
udfalkso 11y ago
Great guide. I'd suggesting adding a bit more about the "why?" if the goal is compliance. In some cases, there are performance benefits to the stated approach (like not deeply nesting classes or avoiding tag based selectors) but some readers may not be aware of this and may assume that it's entirely a style based preference which is easier to ignore due to personal preference.
jjar 11y ago
Ignore ID's? What? The point of an ID is it is a selector used to identify only one element on a page - A header or a footer for example. You can't replace that semantic meaning with classes, if you're only going to be using the style once on a page then change it to an ID. Example: <div class="header inset aboutUs"> or <div id="header" class="inset aboutUs"> The difference is the second option shows at first glance what the element is supposed to be representing to someone reading your code.
- cng2 11y ago
  When managing css in large projects, specificity is your worst enemy. ID are not styled, if there are any. If your worried about being semantic for the header and footer, use the html5 header and footer tags.
  - BinaryIdiot 11y ago
    > When managing css in large projects, specificity is your worst enemy I couldn't disagree more. The more specific you are the less side affects you'll encounter in the rest of your project. When a project gets incredibly large if your styles are NOT specific you're going to run into a lot of unintended consequences. This doesn't mean I encourage using IDs all over the place; they should only be used when there can be a single version of that element on the page. But being specific also means using the cascade (e.g. html > body > div.mydiv versus just .mydiv).
    - tomjakubowski 11y ago
      > I couldn't disagree more. The more specific you are the less side affects you'll encounter in the rest of your project. When a project gets incredibly large if your styles are NOT specific you're going to run into a lot of unintended consequences. You can handle 99% of use cases for specificity just nesting classes. Using IDs to settle specificity is the same as bringing an ICBM to a Nerf gun fight. When I was doing front-end development, I spent more time fighting back against overly specific CSS, thanks to IDs (and fellow developers who just sprinkled `important!` on everything until it worked), than struggling because I couldn't get specific enough without IDs.
octocoupler 11y ago
What is so bad about frameworks? Isn't a simple framework with good standard classes a good thing?
- ricklancee 11y ago
  The author probaly never worked with a deadline before, where there is no time to build everything custom.
scotchio 11y ago
"Frameworks and Vendor Styles: Stay away from frameworks" I disagree - frameworks are awesome. I guess it's all contingent to the project you're working on though. For small projects, it speeds things up and stops you from reinventing the CSS wheel. With large projects, even if you don't use a framework, you [should] end up making one with a style guide (eg: http://walmartlabs.github.io/web-style-guide/ http://walmartlabs.github.io/web-style-guide/). Either way, to completely rule them out is not the best advice IMHO. Other than that, pretty great post/share.
pierotofy 11y ago
Lots of guidelines, many without an obvious reason.
armandososa 11y ago
I disagree on what this says about frameworks. I think frameworks are great. They are specially great when you come to really understand one and how it works and how it can be customised. The major problems I've seen with frameworks is that people just use the default look or try to add customisations on top of the default CSS, overriding styles. I mean, that is just setting yourself up for a world of pain. But most CSS frameworks are really, really flexible in the build stage. You can tweak a few variables that can dramatically alter the appearance of a stylesheet and give you an awesome base to build on. Pretty much for free. If you do all the CSS from scratch you're anyway going to write at the least a reset, some base typographic styles, responsive stuff, and some kind of grid system. Why not use something that is widely used, peer-reviewed, and very customisable?
- donjh 11y ago
  Do you have a particular framework you'd recommend?
  - bwy 11y ago
    It must really depend on what you're looking for/doing. My favorite is http://getskeleton.com/ http://getskeleton.com/. I'm a noob, but I like that I can understand and completely customize the 400 lines of code (https://github.com/dhg/Skeleton/blob/master/css/skeleton.css https://github.com/dhg/Skeleton/blob/master/css/skeleton.css) easily.
  - armandososa 11y ago
    I, personally, like foundation. Mostly because it's more barebones than Bootstrap, it's fairly easy to customise and it uses SCSS which I like better than Less. On the other hand, it sometimes feels like its development has stalled, while Bootstrap future looks bright https://twitter.com/mdo/status/591364406816079873?lang=en https://twitter.com/mdo/status/591364406816079873?lang=en
- pookieinc 11y ago
  Just to build on top of this, and syntax-aside, what about using frameworks like SMACSS, BEM, OOCSS, etc for organizational purposes? I've been hearing a lot about these especially lately and about their greatness for scalability and maintainability once implemented and relied on.
joshribakoff 11y ago
I like how he explains separating layout from presentation. When writing the layout code, keep in mind how its coupled to the HTML. This link mentions how "layout" like z-index is coupled to the structure of HTML, because nesting elements creates new stacking contexts (Z-index is hierarchical - an element's z-index only controls it's depth within the current context, not the overall document). http://philipwalton.com/articles/what-no-one-told-you-about-z-index/ http://philipwalton.com/articles/what-no-one-told-you-about-... This one advises using "js" prefixed classes for JS, so the JS is only coupled to the HTML & not the CSS: http://philipwalton.com/articles/decoupling-html-css-and-javascript/ http://philipwalton.com/articles/decoupling-html-css-and-jav...
piker 11y ago
This was very helpful. One thought on your "Mobile first" media queries segment. While absolutely correct in principle, those of us who unfortunately have to support IE8 should make sure to have a default style set at the "Desktop" level (ie. desktop-first) and have the @media breakpoints kick in at lower resolutions. Otherwise, they may figure out the hard way (as we did) that their webpage looks like trash on browsers that don't support media queries.
- talmand 11y ago
  One philosophy is that if the browser is old enough to not support media queries then they should deal with the stripped down, mobile-first version of the site that they get anyway. At that point, just create a separate IE8 stylesheet loaded with conditional comments to fix the most annoying issues so that the site is at least functional for that type of visitor. There's no reason to bloat the main stylesheet with useless crap for old versions of IE.
evunveot 11y ago
I'm surprised how much the personal standards I've built up working solo for many years align with these. Regarding "Presentation-Specific vs Layout-Specific Styles," the way I've come to organize things is roughly "outside-in" i.e.: position, margin, border, width/height, padding, font/line-height, text styles. I also always put "display" and "box-sizing" first, if they're present, since they change the effect of several things that follow. I disagree with "Prefer nested selectors ... only if both .foo and .foo .bar need styling." I prefer nested selectors always, mostly because it's annoying to have to go back and nest something later when you realize the container needs rules, too. Also I sense that there's something beneficial about the nesting of the (in my case) scss matching the nesting of the HTML, but that might just be aesthetics. Also disagree with "Settle for a few (2-3) breakpoints and use those only," at least for the types of designs I have to work with nowadays. The prevailing style seems to consist of a series of striking, highly independent sections with their own internal layout (think the landing page of a typical, new open source project or startup, with a hero unit or carousel, a list of features in some number of columns, testimonials in some [other] number of columns, etc.). If you make each of those sections adhere to the same handful of breakpoints, either you carefully limit your design or you risk ending up with strange looking layouts in certain sections at certain "in-between" viewport dimensions. I tend to treat each such section completely independently and use as many or as few breakpoints as necessary for that particular internal layout. Sass definitely helps with this, since nested media queries get hoisted to the top level automatically, so you can put them in a natural context. As for mobile-first, I always work desktop-first. Part of that is that mobile-first is pretty much impossible when all you're given is a psd with a full desktop design. But I also find it completely natural to start with the desktop design, narrow the window until something looks off, throw in a media query to fix it, and repeat. And as someone else has already said, when you have to support IE8 to some degree, it's nice to have desktop as the default. I find most of the claims in the linked article about mobile-first [1] to be hand-wavy (you don't want to include "large heavy modules by default," or in other words, you must assume that desktop-first is going to end up slow and clunky on mobile) or contrived (the actual CSS example, where you can eliminate a selector because on small devices the element in question happens to have default styles). In my experience, in fact, things are usually "heavier" on mobile, specifically because you tend to need a bunch of javascript to deal with flyout menus and things having to expand and collapse that can just be there on desktop. In any case: I don't see how the supposed benefits of mobile-first can't be had desktop-first if you just take a modicum of care in your work. [1] http://bradfrost.com/blog/mobile/the-many-faces-of-mobile-first/ http://bradfrost.com/blog/mobile/the-many-faces-of-mobile-fi...

49 points by bevacqua 11y ago

Why not look at BEM? https://en.bem.info/ https://en.bem.info/ http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/ http://csswizardry.com/2013/01/mindbemding-getting-your-head... Harry Roberts really simplifies the idea of it.

matthewbauer 11y ago

Most style guides say to use namespaces for everything. I've never used them. What do I have to be worried about?

mikewhy 11y ago
If you have say a post entry: .post { border: 1px solid #000; } .post .title { font-weight: bold; } And you want to put it into a sidebar .sidebar { background-color: #ccc; } .sidebar .title { text-decoration: underline; } That post's title is now going to be underlined. That's one of the reasons for namespacing. If the classes were `.post--title` and `.sidebar--title`, this would be avoided
- austinlyons 11y ago
  Wouldn't you just instead write the CSS as follows? .sidebar.title { text-decoration: underline; }
  - talmand 11y ago
    That likely wouldn't have the intended effect as I find it doubtful that the element with the sidebar class would also be the title.
  - lstamour 11y ago
    Well, you could also write .sidebar > .title to be more specific than simply all .title elements in .sidebar, but the point is to not tie your CSS quite so closely to the HTML hierarchy I suppose.
- talmand 11y ago
  I had an explanation as to why your CSS was wrong but then I realized an HTML example is needed. I'm assuming you mean something like this: <section class='content'> <div class='post'> <h1 class='title'></h1> </div> </section> <section class='sidebar'> <div class='post'> <h1 class='title'></h1> </div> </section> If so, what you say would indeed happen. Also, I've never thought of .post--title as a form of namespacing. I always understood it to be more like .post .title, as in nesting with SCSS or Less. Not saying you're wrong, just never thought of it that way.
- armandososa 11y ago
  I've found that these cases are non-issues when you use something like BEM. The downside is that the HTML then becomes horrible to look at: <div class='sidebar'> <div class='sidebar__post'> <h2 class='sidebar__post__title'> Please kill me </h2> </div> </div> So… you have to chose between unmaintainable CSS or weird HTML. I think that, in the end, something like this is the only sane outcome: https://medium.com/seek-ui-engineering/the-end-of-global-css-90d2a4a06284 https://medium.com/seek-ui-engineering/the-end-of-global-css...
  - mikewhy 11y ago
    I probably wouldn't go so far as to use `sidebar__post__title `, just `sidebar--title` and `post--title`. That way if you want to style a post title in the sidebar, it's clearly `.sidebar .post--title` using something like BEM solves a lot of problems. Silly collisions and searchability are my big takeaways.
- jt2190 11y ago
  If not underlining post titles is so important, than the CSS rule should make that explicit: .post .title { font-weight: bold; text-decoration: none; } Leaving text-decoration out of the rule is basically saying: "I defer to my ancestor rules for advice on styling this, and I accept their decision."
  - mikewhy 11y ago
    It's not just that the post titles shouldn't be underlined, it's that one elements style should not creep into another elements style by accident
    - marcosdumay 11y ago
      Well, the "all descendants" selector is explicitly intended to do that. It's a bit too far to call it "by accident". There's rarely a real use for the ".sidebar .title" construction.
      - talmand 11y ago
        Rarely? I would think the vast majority of websites would have a version of that in place in several ways.
lstamour 11y ago
If you use SCSS and group your CSS by, e.g. a class in the body tag and additional nesting for components, or if your component-specific styles are loaded only when necessary (e.g. HTTP/2) then not much. The purpose of these techniques, or of prefixing your class names, is to avoid naming collisions. E.g. is your list supposed to have bullets? If you just say ul { list-style: none; } you've effectively said all lists shouldn't. But you might later say the opposite and not notice until your stylesheets are all compiled together and it's a race to see which one wins on every page. Or the other example posted (above, since this comment was downvoted for unknown reasons) where you move HTML around and your stylesheets aren't in sync. Of course, prefixing isn't for everyone -- e.g. https://github.com/twbs/bootstrap/issues/1235 https://github.com/twbs/bootstrap/issues/1235 -- some argue you should know all the styles on your page and how they interact, even if using a "CSS framework" and so naming collisions is just one of the things you'll have to worry about -- if you namespace, what's to prevent a naming collision even with your namespaces? :) This is also where it might be useful to point to https://speakerdeck.com/vjeux/react-css-in-js https://speakerdeck.com/vjeux/react-css-in-js

udfalkso 11y ago

Great guide. I'd suggesting adding a bit more about the "why?" if the goal is compliance. In some cases, there are performance benefits to the stated approach (like not deeply nesting classes or avoiding tag based selectors) but some readers may not be aware of this and may assume that it's entirely a style based preference which is easier to ignore due to personal preference.

jjar 11y ago

Ignore ID's? What? The point of an ID is it is a selector used to identify only one element on a page - A header or a footer for example. You can't replace that semantic meaning with classes, if you're only going to be using the style once on a page then change it to an ID. Example: <div class="header inset aboutUs"> or <div id="header" class="inset aboutUs"> The difference is the second option shows at first glance what the element is supposed to be representing to someone reading your code.

cng2 11y ago
When managing css in large projects, specificity is your worst enemy. ID are not styled, if there are any. If your worried about being semantic for the header and footer, use the html5 header and footer tags.
- BinaryIdiot 11y ago
  > When managing css in large projects, specificity is your worst enemy I couldn't disagree more. The more specific you are the less side affects you'll encounter in the rest of your project. When a project gets incredibly large if your styles are NOT specific you're going to run into a lot of unintended consequences. This doesn't mean I encourage using IDs all over the place; they should only be used when there can be a single version of that element on the page. But being specific also means using the cascade (e.g. html > body > div.mydiv versus just .mydiv).
  - tomjakubowski 11y ago
    > I couldn't disagree more. The more specific you are the less side affects you'll encounter in the rest of your project. When a project gets incredibly large if your styles are NOT specific you're going to run into a lot of unintended consequences. You can handle 99% of use cases for specificity just nesting classes. Using IDs to settle specificity is the same as bringing an ICBM to a Nerf gun fight. When I was doing front-end development, I spent more time fighting back against overly specific CSS, thanks to IDs (and fellow developers who just sprinkled `important!` on everything until it worked), than struggling because I couldn't get specific enough without IDs.

octocoupler 11y ago

What is so bad about frameworks? Isn't a simple framework with good standard classes a good thing?

ricklancee 11y ago
The author probaly never worked with a deadline before, where there is no time to build everything custom.

scotchio 11y ago

"Frameworks and Vendor Styles: Stay away from frameworks" I disagree - frameworks are awesome. I guess it's all contingent to the project you're working on though. For small projects, it speeds things up and stops you from reinventing the CSS wheel. With large projects, even if you don't use a framework, you [should] end up making one with a style guide (eg: http://walmartlabs.github.io/web-style-guide/ http://walmartlabs.github.io/web-style-guide/). Either way, to completely rule them out is not the best advice IMHO. Other than that, pretty great post/share.

pierotofy 11y ago

Lots of guidelines, many without an obvious reason.

armandososa 11y ago

I disagree on what this says about frameworks. I think frameworks are great. They are specially great when you come to really understand one and how it works and how it can be customised. The major problems I've seen with frameworks is that people just use the default look or try to add customisations on top of the default CSS, overriding styles. I mean, that is just setting yourself up for a world of pain. But most CSS frameworks are really, really flexible in the build stage. You can tweak a few variables that can dramatically alter the appearance of a stylesheet and give you an awesome base to build on. Pretty much for free. If you do all the CSS from scratch you're anyway going to write at the least a reset, some base typographic styles, responsive stuff, and some kind of grid system. Why not use something that is widely used, peer-reviewed, and very customisable?

donjh 11y ago
Do you have a particular framework you'd recommend?
- bwy 11y ago
  It must really depend on what you're looking for/doing. My favorite is http://getskeleton.com/ http://getskeleton.com/. I'm a noob, but I like that I can understand and completely customize the 400 lines of code (https://github.com/dhg/Skeleton/blob/master/css/skeleton.css https://github.com/dhg/Skeleton/blob/master/css/skeleton.css) easily.
- armandososa 11y ago
  I, personally, like foundation. Mostly because it's more barebones than Bootstrap, it's fairly easy to customise and it uses SCSS which I like better than Less. On the other hand, it sometimes feels like its development has stalled, while Bootstrap future looks bright https://twitter.com/mdo/status/591364406816079873?lang=en https://twitter.com/mdo/status/591364406816079873?lang=en
pookieinc 11y ago
Just to build on top of this, and syntax-aside, what about using frameworks like SMACSS, BEM, OOCSS, etc for organizational purposes? I've been hearing a lot about these especially lately and about their greatness for scalability and maintainability once implemented and relied on.

joshribakoff 11y ago

I like how he explains separating layout from presentation. When writing the layout code, keep in mind how its coupled to the HTML. This link mentions how "layout" like z-index is coupled to the structure of HTML, because nesting elements creates new stacking contexts (Z-index is hierarchical - an element's z-index only controls it's depth within the current context, not the overall document). http://philipwalton.com/articles/what-no-one-told-you-about-z-index/ http://philipwalton.com/articles/what-no-one-told-you-about-... This one advises using "js" prefixed classes for JS, so the JS is only coupled to the HTML & not the CSS: http://philipwalton.com/articles/decoupling-html-css-and-javascript/ http://philipwalton.com/articles/decoupling-html-css-and-jav...

piker 11y ago

This was very helpful. One thought on your "Mobile first" media queries segment. While absolutely correct in principle, those of us who unfortunately have to support IE8 should make sure to have a default style set at the "Desktop" level (ie. desktop-first) and have the @media breakpoints kick in at lower resolutions. Otherwise, they may figure out the hard way (as we did) that their webpage looks like trash on browsers that don't support media queries.

talmand 11y ago
One philosophy is that if the browser is old enough to not support media queries then they should deal with the stripped down, mobile-first version of the site that they get anyway. At that point, just create a separate IE8 stylesheet loaded with conditional comments to fix the most annoying issues so that the site is at least functional for that type of visitor. There's no reason to bloat the main stylesheet with useless crap for old versions of IE.

evunveot 11y ago

I'm surprised how much the personal standards I've built up working solo for many years align with these. Regarding "Presentation-Specific vs Layout-Specific Styles," the way I've come to organize things is roughly "outside-in" i.e.: position, margin, border, width/height, padding, font/line-height, text styles. I also always put "display" and "box-sizing" first, if they're present, since they change the effect of several things that follow. I disagree with "Prefer nested selectors ... only if both .foo and .foo .bar need styling." I prefer nested selectors always, mostly because it's annoying to have to go back and nest something later when you realize the container needs rules, too. Also I sense that there's something beneficial about the nesting of the (in my case) scss matching the nesting of the HTML, but that might just be aesthetics. Also disagree with "Settle for a few (2-3) breakpoints and use those only," at least for the types of designs I have to work with nowadays. The prevailing style seems to consist of a series of striking, highly independent sections with their own internal layout (think the landing page of a typical, new open source project or startup, with a hero unit or carousel, a list of features in some number of columns, testimonials in some [other] number of columns, etc.). If you make each of those sections adhere to the same handful of breakpoints, either you carefully limit your design or you risk ending up with strange looking layouts in certain sections at certain "in-between" viewport dimensions. I tend to treat each such section completely independently and use as many or as few breakpoints as necessary for that particular internal layout. Sass definitely helps with this, since nested media queries get hoisted to the top level automatically, so you can put them in a natural context. As for mobile-first, I always work desktop-first. Part of that is that mobile-first is pretty much impossible when all you're given is a psd with a full desktop design. But I also find it completely natural to start with the desktop design, narrow the window until something looks off, throw in a media query to fix it, and repeat. And as someone else has already said, when you have to support IE8 to some degree, it's nice to have desktop as the default. I find most of the claims in the linked article about mobile-first [1] to be hand-wavy (you don't want to include "large heavy modules by default," or in other words, you must assume that desktop-first is going to end up slow and clunky on mobile) or contrived (the actual CSS example, where you can eliminate a selector because on small devices the element in question happens to have default styles). In my experience, in fact, things are usually "heavier" on mobile, specifically because you tend to need a bunch of javascript to deal with flyout menus and things having to expand and collapse that can just be there on desktop. In any case: I don't see how the supposed benefits of mobile-first can't be had desktop-first if you just take a modicum of care in your work. [1] http://bradfrost.com/blog/mobile/the-many-faces-of-mobile-first/ http://bradfrost.com/blog/mobile/the-many-faces-of-mobile-fi...