A modern responsive front-end framework based on Material Design

But there were two annoyances: Select elements (without .browser-default class) are display:none and only shown, when initiated via javascript and similarly checkboxes are put off screen and thus invisible if there's no corresponding label (in my case the ones to select rows in a table).

Of course they were easily fixed. But it seems odd to me, to make unexpected things like that the default behavior and – in the case of the selects – risk making your site/app unusable if something goes wrong in your js just to avoid a flash of unstyled content.

As to this specific case, though, I was surprised to see your "this will not work" comment and tested it. It worked: http://jsfiddle.net/brlewis/p0Locwgp/

At my last job, fighting about CSS and dev processes sometimes overtook actual coding and design. I'm glad to be free of control-freak colleagues. Smart and nice control-freaks, but control-freaks nonetheless.

No matter how you sell it, what you have here is a css tautology. It's a "list item", the element name is right there for all to see and use, including the machine. Yet, the first thing you do is give it a new slightly similar name "collection-item". And then the very next item you do it all again. And then to justify it all, call it "OOCSS" like it rolls off the tongue.

The machine blinks but renders your tautology anyway. The machine has no say in what is the most sensible approach.

On another example, let me say: There's nothing wrong with "#sidebar h3".

A typical house might have a garage at the side. Still part of the house, but different and permanent enough to have its own ID. It has furniture inside, as does the house. But garage furniture serves a different purpose. The point is, #main and #garage are perfectly fine and make a lot of sense. "Skinning" and code re-use can be achieved in different ways using CSS. As long as there's a coherent logical approach, you can have skinning, performance and a maintenance friendly site without ever touching frameworks. The other thing is that repetition of some code is not a problem. We don't need to be OCD about a handful of repeating CSS rules. There is not usually any progression into wild, unruly CSS just because a few repeats are found here and there.

Funny but ugly (and irrelevant) stuff in the smashingmag website HTML code...

CSS used "out of the box" is production-ready, and can perform incredibly well in all sorts of environments. CSS grids can be useful, but are not necessary. That's my opinion based on several years working in this area.

If you think "CSS grids gone wrong" isn't a thing, then think again. I'm talking about long term maintenance of the site where the "grid" becomes this "thing that someone installed ages ago that may or may not get the special attention it requires in future". Grids are needy, they have dependencies that may get compromised over time depending who is working on the site and how the design evolves. They have limitations, and they have underlying complexity that works to give the illusion of simplicity. Personally I prefer my illusions in the content, not the code.