I want to love every technique like this (or their more involved cousins like a typography "vertical rhythm" system)... but when it comes time to build sites with some visual and/or layout complexity (for a business client, not a blog that's a relatively simple stream of primarily-text articles), I always wind up with so many exceptions to the rule that I find these catch-all declarations to just be one more thing I'm working around.

For me, the single most useful technique I've discovered in the past few years has been "drop the 'C' in 'CSS'" and instead think in terms of modular components with virtually no cascading or selector nesting. E.g. BEM. Getting over the aesthetic ugliness of "class-itis" in my markup has freed me from a ton of agony trying to reason about why certain elements on the page are being styled a certain way.

Yeah, this is why the "You won’t need many" line is where I stopped reading. Developers who say "most of your LIs are gonna be indented" and "most of your elements will need a top/bottom margin" or "your font sizes will all be relative to the font size of the container" aren't building even slightly complicated UIs...but that doesn't stop them from passing around these "just write CSS, dummy" posts once every few months.

If you write CSS for your personal blog and want to mass-apply styles to save time, go for it, but I think the majority of people who write CSS as a part of their daily work will find that this attitude creates more headaches than time savings.

Sorry for the double reply...

> when it comes time to build sites with some visual and/or layout complexity I always wind up with so many exceptions to the rule

I've been looking for a LONG time for articles about consistent design and typography applied to UIs and boring CRUD apps. 99% of the article about vertical rhythm, spacing, typography and general design are about designing blogs and text-heavy sites.

I need something that teaches me how to design a functional, beautiful and user friendly reactor control dashboard.

> BEM

I'm partial to rscss (http://rscss.io) although that's another "technique" that doesn't seem to be used a lot in the wild. Just makes sense to me.

Thanks you for sharing CSS structure guide, It is very interesting, but I found a drawback based on my experience when the role of "person responsible the look & feel" is shared between team-mates. Some developers (who raised up when jQuery was must-be library in any project) have practice to supply implicit class selector i.e. when they search elements with class name '.link' via document.querySelector. I like the rscss(-like) way, because BEM which is very difficult to follow for newbies (especially now, when react is so popular). But, hey is it a next competitive standard as in famous xkcd [1]?

[1]: https://xkcd.com/927/

Thanks. rscss seems really interesting. I've mostly used BEM but I like the syntax in rscss more.

One thing I'm not sure about though is the child selector. I often have intermediate layers between the root of my component and the elements. Wrappers and stuff to make certain positioning possible. This won't be possible with child selectors only.

Your advice about dropping the "C" in "CSS" is good. I've done this and felt inferior because my CSS isn't as "good" as others. It made me feel like a hack for a long time before I finally started trusting myself and doing things the way I want to.

I've been saying for years that CSS is more trouble than it's worth if you're not writing your pages by hand. If I know that this element is an address field, I can style it like an address field, then and there. (Maybe optimize by using a uniquely-named class, or maybe not - pages are sent gzipped, that may well be good enough). Reusable, self-contained components are a great idea - but to be truly self-contained they need to include their styling.

You can do this with Vue.js - https://github.com/vuejs/vueify. And it includes scoped encapsulation.

Makes things so easy that it feels like cheating.

This is the idea behind the new-ish "shadow dom" feature that is slowly being implemented by browsers. (Part of the larger "web components" concept that will hopefully become a thing at some point).

In the meantime... with some discipline you can keep things self-contained just by using unique classes for each component (like what BEM and other similar naming conventions espouse). Could also look into CSS linters to keep you and your team honest.

> will hopefully become a thing at some point.

I replied to the parent comment here - https://news.ycombinator.com/item?id=12308352. You might find it useful.

Thanks for the pointer. I'm actually a big fan of Vue.js and use it in several product sites/apps. However, if one is just wanting some componentization/isolation in their CSS and not actually building a javascript app, then it's kind of overkill. Also, while it does allow you to keep your component code in different files, by the time the browser is using your CSS it's still all in one big "global namespace" (so to speak), so you still need to enforce some discipline on your css class names, even if they're in different files. (Or perhaps I'm wrong about this and vueify modifies your classes or selectors or something to avoid this?)

Sure, this is more for cases where you want to create reusable components. Which, if you work on multiple projects, might be often.

Yep, it renames them - https://github.com/vuejs/vueify#scoped-css

Adjusting font size with vw is fun, but often the rate at which the font scales is kind of loopy especially when compared to small type. This article takes the example you mentioned above and takes it much further. https://www.smashingmagazine.com/2016/05/fluid-typography/

Have used * + * before. It creates this huge dependence on the placement and ordering of your html you can't create psudo elements to pull off some style trick, there are often a bunch of exceptions when using it too that it kind of defeated the purpose of using it in the first place. Best to have a .class * + * in front of it to relegate it to a specific area.

That font size declaration stood out as a really clever way to get a 'responsive' page with minimal work.

My one concern is that it might get weird on mobile. Android apps, though maybe not mobile pages, have all kinds of awful problems with any font that isn't a convenient integer multiple of pixel size. I'm curious whether this renders gracefully.

The font size method is a little bit ambitious, sites I've worked on will always have caveats.

The margin application though is very clever and the right way to go about it, even in complex designs you'll be able to apply this to most components (maybe not using the body selector though).

These aren't used more often because many developers aren't very familiar with the complete power that CSS has to offer, take BEM for example it completely eradicates the most powerful feature that CSS has to offer.