Ben Halpern

Posted on Jan 15, 2020

Tell me about the worst CSS you've ever had to deal with

#discuss #css #webdev

Story time!

Top comments (41)

Zane Milakovic • Jan 15 '20 • Edited

I worked at a fortune 10 company, that had a 8 year old enterprise CMS. This is code for bulky, slow, confusing, and difficult to use.

The interesting this, is that the vender that owned the platform, had to outsource a lot of work to 3rd parties to meet timelines over the years.

So you ended up on pages that had knockout.js, jQuery, angular, and who knows what else all in the same place.

Well given the state of the JS, I am guessing you can assume how bad the CSS was. There was nothing to make it easier to write, no SASS or LESS.

It was all in a few single files. Nothing bundled them together.

Because some parts of the app were done in isolation, they may have had there own CSS that was not namespaces. So something could work everywhere but on that one page.

It was great.

Full disclosure, I convinced the business to start over and spent my next years at the company building a new platform they use today.

I feel bad for my colleges that got stuck maintaining the old one while the new one came to life...

Ben Halpern • Jan 15 '20

Full disclosure, I convinced the business to start over and spent my next years at the company building a new platform they use today.

So it was a full-on parallel rewrite?

How much of the change was HTML and how much was within the CSS?

Zane Milakovic • Jan 15 '20

It was everything.

The previous platform was on a CMS that was past end of life. The vendor no longer supported it. They had inherited it from a outside agency that use to do the IT and they were insourcing it.

The old sites were not responsive. They were dated. And we as a company did not understand them completely. For example, adding a 5th option to the top level omni-menu for on brand, broke it for the other brands in production. It slipped through QA. And that was 5 weeks to add essential another LI and Anchor tag.

So the replatform was a new design, newer tech stack with an updated version of the same enterprise CMS.

We made a strong case of all the problem areas it would address. With the vision on a long term future. Like no modifying the core CMS to the point you remove yourself from any upgrade path.

So from that point we got to throw away the old CSS. But because the project takes years to do, teams had to maintain the old product.

Basically, there were multiple white label brands, each with many internalized sites, sometimes over a hundred.

It would take 10k content authors around the world, about 5 years to launch all new sites in all markets. And that is after all the UI, authoring interface, and development was done.

They still may not be finished in smaller markets. I left the company a few years ago.

Peyton McGinnis • Jan 15 '20

Well, I had once assumed that vw and vh were good units for cascading font sizing throughout my whole UI.

I still have nightmares to this day.

Rohan Mishra • Jan 15 '20

Would never do that on a client website but I am quite sure I still have a CSS rule that does exactly that on my personal website.

I set out to rebuild my website to be the best I could do and honestly it doesn't at all. It is quickly climbing my "I dont want to deal with this" list.

Kenny Whyte • Jan 15 '20

"CSS: The !important Wars"

This would be great on a t-shirt.🤣

Dan Silcox • Jan 15 '20

The sequel will be “CSS: the z-index strikes back” 😂

Mateus Vahl • Jan 17 '20

Yup! Since I had this issue, I now follow this global variable approach:

$z-index: (
  menu: 10,
  offcanvas: 20,
  lightbox: 30
);


@mixin z-index($key) {
  z-index: map-get($z-index, $key);
}

Everything on the page that could overlap is defined above.

Corey McCarty • Jan 15 '20

Everything that I write

Achilles Moraites • Jan 15 '20

The horror when you realize that people begin adding inline css rules with !important...

Ted Goas • Jan 15 '20

I regularly work with HTML email code. Styling <table> cells, writing inline CSS styles, designing with CSS2 support, and the like.

But thing is, I like it 🏴‍☠️

Scott Czepiel • Jan 15 '20

Do you know of any good resource on best practices for writing email-friendly html/css? MailChimp have some guides but leave out all the important special sauce! I once started writing an email template for use in RMarkdown, eg. to convert a markdown post to be email friendly.

Ted Goas • Jan 15 '20

Yes, I have a couple!

Lee Munroe wrote an excellent guide on coding HTML emails.
I create and maintain an open source project that I use as my starting point for my email projects.

Felippe Regazio • Jan 15 '20 • Edited

I had to deal with a system that has lot of !important in pure css files along different folders in the project. The files were loaded sometimes twice in a page (because different modules was loading same .css). There was so many !importants that nothing was important anymore. I had to discover the scope and logic of dozens of files and re-arrange/re-order/re-write them all. Bad days :/

Rohan Mishra • Jan 15 '20

There was so many !importants that nothing was important anymore.

Saving this for future use.

Ben Sinclair • Jan 15 '20 • Edited

Ok. There's a chance this is still out there, on a site with tens or possibly hundreds of thousands of regular users, so I'm not going to be too specific.

<div id="my-super-specific-id" class="fw-500 big red well-padded non-semantic-utility-class">
  Content
</div>

So the HTML was full of DIVs as text holders instead of proper semantic emelents, full of non-semantic junk utility classes and, importantly, this thing called fw-500. What's that, then?

There were several CSS files with names like grid-768.css, grid-980.css, etc. You can guess what these were for, right? Right. So you'd have media queries in them like so:

/* grid-980.css */
@media (min-width:1024px) {

.fw-1 { width: 1px; }
.fw-2 { width: 2px; }
.fw-3 { width: 3px; }

/* ... */

.fw-767 { width: 767px; }
.fw-768 { width: 767px; }
.fw-769 { width: 767px; }
.fw-770 { width: 770px; }

/* ... */

.fw-1920 { width: 1px; }

}

Yes, there were (usually) 1920 of these lines. I only hope they generated them in the first place rather than typing them by hand, but who knows.

This was a crude column array, down to pixel level, that could be varied depending on viewport size even though you thought you were working only at desktop sizes.

But the filename didn't always match up with the media query it was using, because Things Change.

And then... and then a lot of the sizes had non-matching widths because of off-by-one error fixes or discrepancies between box-sizing in different browsers and so on.

Muhammad Arslan Aslam • Jan 16 '20

One of the worst CSS I usually have to deal with every once in a while looks something like this:

html { background-color: #e0e0e0; }
body { color: rgba(0, 0, 0, 0.87); font-size: 0.875rem; background-color: #f0f0f0; -webkit-font-smoothing: antialiased; }
*:focus { outline: 0 !important; }
a { color: inherit; text-decoration: none; cursor: pointer; outline: 0; }
a:hover, a:focus { color: inherit; text-decoration: none; }
button { color: inherit; }
pre { color: inherit; background-color: #f8f8f8; border-color: rgba(120, 130, 140, 0.13); }
blockquote { border-color: rgba(120, 130, 140, 0.13); }
small { font-size: 90%; }
sup { position: relative; top: -1em; font-size: 75%; }
.pull-center { position: absolute; left: 50%; }
.close { font-size: 1.3rem; }
.img-responsive { width: 100%; height: auto; }
.text-center { text-align: center; }
.text-left { text-align: left; }
.text-right { text-align: right; }
.pull-left { float: left; }
.pull-right { float: right; }
.center-block { margin: 0 auto; }
.avatar-profile{ width:100% !important}
.heading-settings{ border-bottom:2px solid #ccc; overflow:hidden; clear:both}
.edit-button a{ margin-top: 20px; margin-right:20px;}
.heading-settings h3{ margin:0;}