I vehemently disagree with the recommendation on box models. I'm of the opinion that `border-box` leads to cleaner, terser css. Working around the default box model results in all kinds of CSS gymnastics that some poor person is going to have to figure out in a few months time when they pick up the project.

I also can't agree with the recommendation on using pixel values over relative values. I guess most people are using some sort of CSS preprocessor these days, so a pixel to rem mixin would be my recommendation.

Not to poo-poo the whole thing though. A lot of that stuff I agree with. A small amount I don't, and a couple of things I think are up for debate.

Lots of "whats", not many "whys"

Is there any explanation for the reason for a lot of these things?

Some of these examples are valid and should be common knowledge for all web developers (e.g.: treating CSS semicolons as terminators rather than separators; transitions; unitless values; all [+1]), and some of these examples are a bit questionable. The code style seems a bit esoteric, especially some of the ES. Also, not many of these examples would pass an HTML validator without warnings due to the lack of quotes surrounding attributes. Just a caveat..

I like a LOT of these comments, but some just leave me scratching my head:

// bad void function() { /* IIFE / }();

// good (function() { / IIFE */ }());

To me, the "bad" one was more readable until I noticed you were invoking the function. Personally, I don't like either notation, but the point is that this example (along with quite a few others) seems to need more explanation to get the point across.

I would maybe think about defining "IIFE" as well as maybe sectioning off the more "functional programming" sections.

Thank you for taking the time to put this together.

Several of the examples have an extra lambda like this. What does it do?

const toArray = (() => Array.from ? Array.from : obj => [].slice.call(obj) )();