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 S

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...