DEV Community

stereobooster
stereobooster

Posted on • Originally published at stereobooster.com on

CSS: bad parts

There is a famous book (at least it was some time ago), by the person who brought us JSON - JavaScript: good parts. It basically teaches which part of the languages are nice to use and won’t get you in a trouble. Book was published way before ES6 and recent goodness. It was helpfull at the time.

(Image source: reddit)

I had a thought: what if we can write down bad parts - things that you should avoid - for CSS.

  • Global styles. Whenever I use styling based on tag names or use nested selectors I find conflict in styles eventually. Instead we can use unique class names for each element. This approach requires some tooling (for example, CSS Modules) or atomic styles.
  • Margins. See Margin considered harmful.
  • Z-index. Whenever you start using z-index, eventually you will get z-index: 999999999 or conflicting items (for example, custom select vs modal). Instead we can rely on order of elements in the DOM. See Z Index Wars.

by Evgenia Milcheva

  • Inline styles (Editor note: I would say use only external styles or only inline styles, never mix)
  • !important

What else would you recommend to avoid?

Top comments (20)

Collapse
 
codemouse92 profile image
Jason C. McDonald • Edited

I don't know that you can really avoid z-index. You have to use it sooner or later anytime there's overlapping elements, and it's at least in common with every single UX design toolkit and animation software ever. But I agree that z-index 9999999 (or -999999) is terrible. There's gotta be a better way; but since there isn't, we live with it.

P.S. I find it rather ironic how much thinner "Good Parts" is to the "Javascript" book in the picture. Sums up my feelings on JS quite well, ha ha!

Collapse
 
muhammedyousrii profile image
Muhammed Yousrii • Edited

We can use SASS to overcome this problem, we can achieve that by making a separate file, let's call it z-indexes-defaults which will contain all the z-indexes definitions for the main elements that will overflow on each other or on the base content,

That will prevent us from facing such a problem and all your all z-indexes definitions are in one place and its values are represented by meaningful variables names

Collapse
 
codemouse92 profile image
Jason C. McDonald

I dunno. Somehow this feels more icky than z-indices.

Collapse
 
stereobooster profile image
stereobooster

I don't know that you can really avoid z-index.

In the given example author managed to avoid using z-index for a modal. So I guess it is possible to do much less than we do typically.

Collapse
 
giorgosk profile image
Giorgos Kontopoulos 👀

Margins are inevitable though, can not do FE without them but need to have clear rules of which components can use them and keep consistent within an application.

For example all sub-component should generally avoid having OUTER margins and leave that to the parent or container component(s) to decide by way of padding perhaps. A sub-component should be allowed to define its own internal margins/padding (between its own elements) only.

Collapse
 
stereobooster profile image
stereobooster

You can refuse from margins, for example use grid and gap properties, or "spacer" component, or flexbox. (Padding allowed though)

Collapse
 
giorgosk profile image
Giorgos Kontopoulos 👀 • Edited

Grid not fully supported on IE 11 so not always possible to use grid ... Many webshops still support this browser. :)

Thread Thread
 
stereobooster profile image
stereobooster • Edited

According to Microsoft, IE11 is supported until the end of Windows 10 which is on October 14, 2025

I guess we can wait a bit :-) Or maybe use some kind of polyfill/transpiler, like this one.

Collapse
 
roelofjanelsinga profile image
Roelof Jan Elsinga

I hope you're also making a post about "The good parts"! If so, one of them is definitely utility classes like Giorgos mentioned. A great example of this is Tailwindcss. The speed at which I can now build nice looking applications is great.

I suppose that brings me to one of the bar parts of CSS as well: when you start to mix styling practices, your stylesheets become uncontrollable. So for example, mixing BEM and utility classes, with scope component styles. It becomes a huge mess and you start to replicate your code code to each fit a slightly different use case.

Collapse
 
stereobooster profile image
stereobooster

I hope you're also making a post about "The good parts"!

I'm not qualified enough for this task

Collapse
 
roelofjanelsinga profile image
Roelof Jan Elsinga

You definitely are! If anything, you'll learn something new. Give it a shot 😁

Thread Thread
 
stereobooster profile image
stereobooster • Edited

I'll leave it to you

Collapse
 
thorstenhirsch profile image
Thorsten Hirsch

Hey stereobooster, I've got the impression that a lot of "old school" developers really like global styles. They praise the cascading feature of css, which helps them keeping their code "dry". I think that's one of the reasons why many of them hate component based spa frameworks/libraries - they're "forced" (or advised) to split their css, too. Unfortunately I struggle to convince them that decoupled components are of much greater benefit than "dry" css.

What's your opinion? Can you give me some more arguments for my discussions?

Collapse
 
stereobooster profile image
stereobooster

It's a really big topic here (and to be fair, not what I aimed in this article). I will be not the first and the most significant author to talk on the subject. Maybe check those talks:

Collapse
 
giorgosk profile image
Giorgos Kontopoulos 👀 • Edited

I don't consider global code (classes) bad on their own sometimes it is needed. I think they are called utility classes with some of the css frameworks. And yes dry is one of the reasons to use it but another one is consistency. For example you want a certain animation done when hovering over a link on LOTS of parts of your site/app can be different components in modern web apps. Without a reusable utility class you are recreating the same exact code (perhaps with copy/paste) and might run into inconsitencies if you have to modify this behaviour later on but you are also bloating the final .css with the same code multiple times.

In that sense those classes are global and not part of any component and any component can choose to use them when needed.

Collapse
 
thorstenhirsch profile image
Thorsten Hirsch

Oh, I din't mean shared/global code in general, Giorgos. I only had global CSS code without namespaced classes in mind (...where you can shoot yourself in the foot with cascading selectors).

Collapse
 
emilcheva profile image
Evgenia Milcheva

Inline styles ("but look, it works so.... what's the problem") , !important ("just in case"); or id css selectors ("I have always did it this way") ... We have seen and heard it all, please don't ever do this unless you really need to !

Collapse
 
stereobooster profile image
stereobooster • Edited

Oh nice. I will add this to the list.

Collapse
 
scrabill profile image
Shannon Crabill • Edited

Interesting take on not using margins. I wonder how having spacer components are for bloat, accessibility and maintaining code.

Collapse
 
stereobooster profile image
stereobooster • Edited

I wonder how having spacer components are for bloat, accessibility and maintaining code.

I can't say anything about bloat and maintaining code. But accessibility will be fine, it is empty element invisible to screen reader the same way as margin 🤷‍♀️