CSS: The bad bits and how to avoid them

There&#x27;s nothing wrong with styling on an id.<p>You could put the style right in the HTML tag, or on the page where it&#x27;s used, but with dynamic pages (and static stylesheets) both options will cost you bandwidth.<p>And they split up your styles into separate places.<p>So putting the style on the id is the right thing to do, and I don&#x27;t understand why the author is against it.<p>If I need my footer to look a certain way, then #footer {} is exactly what you should do.<p>Not add some bogus class based style just in case someone decides we need two footers on one page.

Never understood why people prefer verbose and repetitive BEM classes over custom properties and appropriate CSS selectors.<p><pre><code> &lt;div class=&quot;my-block my-block__my-element my-block__my-element--my-modifier&quot;&gt;</code></pre> becomes<p><pre><code> &lt;div my-block=&quot;my-element my-modifier&quot;&gt; </code></pre> This solves for specificity, and uses built-in CSS features instead of a &quot;manual&quot; workaround.

I&#x27;m a huge fan of 1 &amp; 2, so I end up using CSS with only class names.<p>This helped me deliver maintainable and reliable stylesheets that other devs like.<p>Most importantly using only class names you will gain :<p>1. Your HTML &#x2F; CSS is easier to maintain.<p>2. Is faster to develop.<p>3. Is faster to refactor.<p>4. Is more portable.<p>5. Is faster for the browser.<p>I even wrote a blog post about it [1].<p><a href="http:&#x2F;&#x2F;www.drinchev.com&#x2F;blog&#x2F;css-with-only-class-names&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.drinchev.com&#x2F;blog&#x2F;css-with-only-class-names&#x2F;</a>

The advice to use CSS variables to handle Z-index confusion is a good first step, but IME that&#x27;s only the right way to handle global z-indexes like modal lightboxes and menus. For local z-indexes, you should also know how and when to create a new stacking context with position: relative.<p>This is the go-to article I send to newbies struggling with z-index. <a href="https:&#x2F;&#x2F;hackernoon.com&#x2F;my-approach-to-using-z-index-eca67feb079c" rel="nofollow">https:&#x2F;&#x2F;hackernoon.com&#x2F;my-approach-to-using-z-index-eca67feb...</a>

Using CSS-in-JS to enforce component-local CSS (and also allow easy dynamic updating of styles, by making a “getStyles” type function) is the best thing to happen to styling for a long time in my opinion. Recently I’ve been using the “styled components” pattern (using the Emotion library) and despite being initially sceptical, have found it really nice to work with.<p>So much more logical to write and maintain than plain CSS for a site of any reasonable complexity. You can still apply global styles where they make sense (e.g. styling all body text) and making use of JavaScript patterns for reusing common chunks of styling feels much more robust than the CSS equivalent.<p>As someone who can do CSS but doesn’t do so that often, I can confirm that it’s getting better with things like Flexbox and Grid, but it is still full of maddening quirks! I do have a lot of respect for people who are CSS experts.

I&#x27;ve heard about BEM many times and been forced to use it on a lot of projects. It seems to be reasonably commonplace I was hoping for some smaller tips so here&#x27;s one I use very often.<p>Vertical height of text comes up a lot in CSS. It seems many people do not make liberal enough use of the line-height property. Line height is a magic bullet when you need some text to take up the correct amount of space.<p>With it, and your element styled to inline-block, of float left, or however you are using it. You are able to modify the font size later on without having any effect on the element&#x27;s surroundings. It&#x27;s also automatically centered vertically and you can change it without much effort.<p>Not enough people using line-height.

In my opinion, most CSS bad bits are a byproduct of bad use, not a problem of the language(?) itself.<p>SASS, BAM, OOCSS, etc are all good practices. You can&#x2F;will abuse those as well without proper understanding and planning.

I&#x27;m surprised nobody mentioned using the Shadow DOM yet. That provides you with a very good means of scoping your CSS; e.g: within custom elements. Just look at Polymer.

For z-indexes, we&#x27;re using a slightly an approach that I find a bit clearer:<p><pre><code> $some-element-z-index: 1 + max( $other-element-z-index, $should-be-below-z-index ); </code></pre> This way the relationship between elements that should be below or above is more explicit.<p>In my head, it works a bit like a spreadsheet. You update the z-index value of an element somewhere below, and all the z-indexes that depend on it update their value too.

I tend to write CSS for projects by hand without a pre-processor, borrowing from previous projects only when called for.<p>One of the things I&#x27;ve been doing recently that helps debugging a lot is to group the attributes within a css class into three, separated by a line.<p>1) Things that control where the item shows up.<p>2) Things that control the overall appearance of the item, like size and background.<p>3) Things that control appearance of things within the item, like font color.

There is a different and IMO better way to solve the global scope problem in CSS. Adapted from the Paul Irish method of executing JS you can use data attributes to conditionally write CSS. For example a new user controller would output the controller and action names as data attributes on the body. I then have a separate css file under `assets&#x2F;users&#x2F;new.scss` which only contains css for that page. Your Sass code looks something like:<p><pre><code> [data-controller=&quot;user_controller&quot;][data-action=&quot;new&quot;] { .header { background-color: blue; } } </code></pre> This method keeps you organized and completely removes the biggest problem most people have with CSS.

I have been writing a lot of CSS (well SCSS) lately and this seems like a good time as any (though I admit somewhat off topic) about a question I have regarding the newer Combination &amp; Multiple selectors <a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Learn&#x2F;CSS&#x2F;Introduction_to_CSS&#x2F;Combinators_and_multiple_selectors" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Learn&#x2F;CSS&#x2F;Introduct...</a> and Attribute Selectors <a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Learn&#x2F;CSS&#x2F;Introduction_to_CSS&#x2F;Attribute_selectors" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Learn&#x2F;CSS&#x2F;Introduct...</a><p>This stems from the fact that I have inherited the task of re-writing a very large (at least for one person, I feel) task of re-writing an internal framework that is really gotten too burdensome to add anything to. I have been contemplating instead of trying to get crazy with a ton of different selectors where you end up with a pattern like this:<p>``` .selector .selector1 li, .selector .selector1 li a { some-style: some-value; } ```<p>Which I find A little crazy compared to something like this:<p>``` [class*=&quot;selector selector1] { some-style: some value; } ```<p>or my person favorite:<p>``` ul &gt; li &gt; a { color: blue; } ```<p>While these examples are I think very simplistic (I don&#x27;t wanna junk up the page with tons of stuff) I&#x27;ve met alot of resistance to this idea, and splunking other frameworks for inspiration (Shout out to <a href="https:&#x2F;&#x2F;bulma.io" rel="nofollow">https:&#x2F;&#x2F;bulma.io</a> ! I like their work, its really wonderful FYI.) I don&#x27;t see alot of this.<p>While the resistance I&#x27;ve met from others who have some input on this project (and rightly so, they&#x27;re also part of our stellar in house design team) seem to resist this idea, but haven&#x27;t articulated why.<p>I was wondering if it comes down to: is there actually an issue with using these heavily vs some of the older semantics or, which I feel is quite possible, people have done things for so long one way its hard to see another way?<p>While its seemingly less verbose sometimes (not always) I feel like the new selectors give you a way to combat specificity problems by controlling when context around your classes is better than having ton of different classes and nesting those over and over.<p>Am i missing something?

&gt; Often there’s an argument to use tags to create a default set of styles. For most sites, it’s usually a good idea. However, if you’re just overriding those styles pretty much everywhere, I’d say don’t bother. Put them in generic utility classes (e.g. .paragraph, .heading-1, etc) and use them as you need.<p>Please don&#x27;t. Tags have semantics for important reasons. Even if you&#x27;re removing one of those by overriding the default styles, the semantics of tags are still used e.g. for screenreaders. It&#x27;s not a mistake that HTML 5 added a ton of new semantic tags like &lt;article&gt;, &lt;header&gt;, &lt;footer&gt;, &lt;aside&gt; and &lt;nav&gt;.

One bad thing about CSS is cascading. Too bad that&#x27;s the main thing. Some styles like colors and fonts move like a plague into every nook and cranny, all children elements get infected. Others like border get applied only onto the targeted element. Heavily nested selectors is another one, good luck overriding a style on a bootstrap element, their selectors strictly follow html nesting levels. You want to override a td style by a adding a class, you mean .table &gt; tbody &gt; tr &gt; td.yourclass. Ugh. Sass only helps you write even more convoluted CSS if you don&#x27;t know what you are doing, it&#x27;s like C and C++.

Just like WASM allows us to implement new languages as alternative to JavaScript, could it one day become practical to implement an alternative to CSS?<p>EDIT: Perhaps by implementing the whole browser in WASM? Would that even make sense?

CSS Grid really helped me understand&#x2F;wrangle z-index and stacking contexts. For example, within a grid you can use grid-row&#x2F;grid-column to position an overlay over a grid item. The z-index will be scoped to that stacking context.<p>Modular CSS I think is a huge step forward - I totally agree that global scope is killer. As much as people love to hate on CSS-in-JS, I enjoy using styled-components a lot. I&#x27;ve noticed since using it I&#x27;ve been composing CSS instead of inheriting or overriding styles.

I think tooling is coming a long way to help with these - take for instance BEM. CSS modules is a great way to avoid needing BEM, as the bundler is handling the uniqueness of the classname for you (during minification etc.).<p>This is just the nature of web development - almost every tech in the stack is flawed, but tools and best practices make some sanity out of the chaos.

Best workaround for all the problems of the class discussed in the article: stop trying to be pixel-perfect.

Add another class to make your element more specific. You can have many classes in one element! Then you never have to use !important again.<p><pre><code> .rabbit.drivingACar.onIce.withRocketBoosters { color: pink; &#x2F;* pretty specific *&#x2F; }</code></pre>

Shadow dom and proper scoping (whichever popular method you chose for that) is a god send. I really dislike BEM though, we have files that have more classnames than content and tags combined :D

Just wondering how much more complains and valid critique against css is still required to get real alternative.<p><a href="https:&#x2F;&#x2F;ishoudinireadyyet.com" rel="nofollow">https:&#x2F;&#x2F;ishoudinireadyyet.com</a>

Bad bits? More like code correctly, use already existing CSS features to your advantage, and use common sense when naming things. Then the so-called &quot;bad bits&quot; tend not to happen.

I&#x27;d add one thing: avoid multiple classes on a single element; use mixins to avoid duplication. I tend to do so even for classes that have some toggle state, i.e. .some-class-active.

<i>Best workaround: Quit front end web development. If that’s not an option, tough, you’ve got to use CSS.</i><p>Instead of quitting front-end dev, you might also consider using <a href="https:&#x2F;&#x2F;www.styled-components.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.styled-components.com&#x2F;</a><p>Styled-components solves all of the issues the author highlights in his writeup.<p>Bonus: styled-components works both on web and on React Native! So you don&#x27;t have to throw out all your stuff to participate in the post-browser future...

&gt;If you told any back-end developer that they had to use a programming language that gave all variables global scope, made every object’s internal state visible, let any other developer override their code, they’d probably resign on the spot<p>Isn&#x27;t that the case with Javascript?

Use CSS Modules imo.

Keep going!<p><pre><code> z-index: 2147483647;</code></pre>

Stop using CSS and go with modular SCSS

The world really doesn&#x27;t need another &quot;What to Avoid with CSS&quot; list.<p>This list also assumes the use of a CSS pre-processor.