loading...
markdown guide
 

One for a popular marketplace that I can't mention, but let's say if I had to make a movie about it, it would be called: "CSS: The !important Wars" 🤣

 

"CSS: The !important Wars"

This would be great on a t-shirt.🤣

 

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

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.

 

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

 

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...

 

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?

 

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.

 

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.

 

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.

 

Once I had to re-theme a site. It used bootstrap, so I figured it would be easy to change the theme out.

After going through inline styles with hard coded colors, font sizes, margins... etc. in over a thousand files, I realized I was wrong.

Usually css is pretty straight forward so I haven't seen anything scary bad, but I loathe inline styles to this day.

If you don't have sass or less available, at least use utility classes in a single file. Please!

 
 

Yeah. Not as bad as it sounds though. They were static html files generated with templates. Once I figured out a few find and replace patterns it took care of 99% of the changes.

 

inline styles with hard coded colors, font sizes, margins... etc. in over a thousand files

Somehow that has been my experience with every bootstrap based site I've had the pleasure to get my hands on.

 

1000 files. Man I bet your Git history was amazing.

The merge request review process was just every dev giving up after they could not load the diff I bet!

 

You don't find it all in one shot. But yeah, some things aren't worth reviewing. Haha.

 

I've asked to fix a single page with "weird" bug. Turn out the previous dev had positioned ALL html div with "absolute". Every. Single. One. Pixel. Accurate. Manually.

 
 

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 :/

 

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

Saving this for future use.

 

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.

 

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 🏴‍☠️

 

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.

 

Yes, I have a couple!

 

Making emails look nice on all the different clients is a nightmare. It's getting better, but I still just use tables any time I need the layout to work everywhere, and don't try to do anything fancy. It's like writing code that would work in ie 6.

 

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;}

One of my colleagues thinks it's best to write "COMPRESSED" CSS from start instead of compressing it later on.

 

Beating inline !important

This is gonna be awful, so brace yourselves...

Had to work with HTML generated by closed-source, god-knows-what-language, third-party legacy script that had inline !important declarations. I kid you not.
It seems that dev really, really didn't wanted anyone to adapt their style. Any request to change that would fall into the "we don't know how to do that, the original dev is long gone and nowhere to be found" category.

I was tasked with changing those styles to better suit the website. "impossible" was my first thought, both internal !important and external !important would fall short to change such an absurd priority. Then I remembered the only way to beat internal !important: animations.

So the first step in fixing this mess was to create instant animations that used keyframes to beat the priority.

But it wouldn't be so "simple", oh no. The code didn't had classes or a structure I could easily target with element selectors, so I had to use attribute selectors targeting the style attribute that matched the properties.

Something the likes of

<!-- HTML with inline, important styles setting blue font -->
<p style="color:blue !important">test</p>
/* external CSS, the only thing I was allowed to change */
[style*="color: blue"] {
  animation: change-color 0.1ms forwards;
}

@keyframes change-color {
  to {
    color: red;
  }
}

And it worked. The final output of that code will be red text, beating the inline !important declaration that tries to set it to blue.

Of course the real case was much more complicated than that example, as there was lots of conflicting stuff that made the hack quite complex and fragile. Not fun. At all.

But at the end of the day I got the thing working, feeling extremely proud. And extremely ashamed.

 

In a "production" app that I had to work on after the previous developer left.
It was horrible.
There was 2 differents files, one of 3000 lines the other 600 lines.
The first one was actually a copy-pasted from something found on the web, with a few modifications, and many useless CSS class (but which one ? that was the question)and so many !important that were more !important that the last one...
It was based on bootstrap, but with 2 differents versions one upon the other (why ...?)
I had to progressively rewrite the whole thing, with scss, without bootstrap.

 

I need to have some changes in the live server, It was a wordpress project. Then I keep on ctrl + s (Save) on the visual studio and refresh the page. I did'nt know why the website doesnt change its css. It took me few hours to finally get that I was doing refresh on the local development website.

 

Going to make a point here which escapes most people. It kind of goes back to xslt, and in some ways links to svelte, react etc. If you can drive most code from meta data, it doesn't really matter if the css, or js is bad (of course it does, but...). The real issue is when managers and product managers won't let the developer do the right thing. There may be good reason why they won't.
I tend to look at most development as something which should/could be templated in the future unless it is domain specific. The question is whether we should go that extra mile.
Employ a css expert, Sql guru, python extroadinairre, but if they are still doing expertise two years in, something is l wrong.
This is why I am not a fan of code bashing/honour shaming.

 

I'm not sure if this is the worst I've dealt with but it's up there and is first on the mind.

At a previous job, I was leading the development of an e-commerce website (I really shouldn't have been but that's a different story, but it does add to the CSS issue) so we had a regular contractor to focus on the designs and styling of our pages as they were specialized.

We were using bootstrap 4, which they were actually quite happy we were. For a while throughout the development, I noticed a lot of pages weren't responsive; which was quite surprising considering bootstrap's rows and columns can do a lot of the heavy lifting towards responsive layouts, but it was known that they were "working on it".

Days before launch some of the major pages still weren't responsive which was making me tense, so I decided to take a look and I had found that they had created their very own column classes using CSS Grid that didn't account for different screen sizes!

I wish I still had the CSS to show snippets off, but the worst part about this CSS to me was just making worse copies of classes already given to us by a framework.

 

CSS I couldn't find in a Drupal site I inherited. It was inline and I just couldn't figure out where it was coming from. Searching the code base was futile. Finally I found it in a Views (a Drupal content display tool) configuration buried under a setting I'd never even seen used before.

 

Turning my own into BEM style when I learned about it. Removing padding and margins on every class was awful

Another one though is the material css lib which I found difficult to override multiple classes of for just a select field

 

I was hired to add new function to an in store application for a major electronics retailer. This Order Management system was written in AngularJs by a team of 2.

The app mixed in gui directives and open source animations. All tied very tightly together using Less.

Any small change broke the entire layoutl. Each time it required hours of debug time to find and fix. The worst were the directives because they ran within Angular's layout cycle.

This meant putting in debug statements which were only needed on the 20th time. The stacktrace showed the caller to alwys be Angularjs which was being invoked at any random unrelated async call. The directives were entry points into components controlled only by Angularjs cycles.

The devs had been let go two years earlier. I was first to ressurect project. Due to internal security our local instances could not reach internal servers to run. This meant every change had to be deployed to a dev machine.

How many tweaks are made to css/less? Probably 100 per day. 100 deployments eats up major time.

Take away... debugging css can be extremely hard. Especially when layout is not fluid. Directives which alter GUI open up entry points out of logical control and become very difficult to debug. Open source animation components,when they don't work, drag you into their internals to fix, this can take days. Internal security rules can be major impediment.

Finally, Grunt is evil.

 

When using a third-party webchat app that we were thinking of using, they told us we were able to brand it using CSS. One of my first tasks as someone who had recently learnt responsive web design was too brand it and make it responsive, as we didn't know what device we were going on.

Unfortunately nearly everything they had was inherited from some javascript I couldn't find, and no matter how specific I made my CSS it just wouldn't overwrite it. We could do basic colours and fonts, nothing more.

After weeks of trying and contacting their support, they finally told me "Oh yeah, we have no idea how'd you'd make this responsive as we've never tried to do that before, but we have a fairly good idea that you can't".

Literally over 200 hours of tearing my hair out, thinking it was simply because I was new to this, to be told that.

We did not use their product after that.

 

Even having a years of experience sometimes I had to deal with css for cross-browser compatibility. In past month I was working in a AT&T website and require to make it compatible with IE. I used flex to make the structure flexible. But When there is need to use "min-height" to set the content at minimum height. This code really mess in Internet Explorer 11.

It was really hard time for me to find an alternate solution. Because making change for all browser due to one small thing was so hard.

So I added some CSS IE Hack to make the things works as it require. I added the following.
@media all and (-ms-high-contrast:none){}

 
 

I was tasked with making a large number of seemingly small changes on an existing project. Most CSS changes I attempted broke the layout in one way or another. A simple task like increasing the font size of an element would turn into an hour-long task because it would break the layout of the element, its parent element and the parent's sibling elements.

I was the third or fourth developer to be brought in. Inline CSS everywhere (including in the HTML added to text fields in the CMS). Bootstrap + 1000s of lines of custom CSS.

The whole thing was a nightmare; not just the CSS.

 
 

One thing that makes it the worst is !important

 

"Your application will have to use the styles defined here."

One .css behemoth, 97 kb minified, no source code.

 

CSS files where the same classes were overwritten multiple times. 😅

 

Aligning elements using float:left and right and also using tags like center which i much later found out that those tags were deprecated

 
 

the headache of cross-browser compatibility.

 
 

For me, It was float:left or right whatever. But big relief when started using flex and grid.

Classic DEV Post from Jun 23 '19

What Advice Would You Give Your 20-year-old Self?

If you could go back in time, what advice would you give your 20-year-old self?

Ben Halpern profile image
A Canadian software developer who thinks he’s funny. He/Him.

Customize your DEV feed to keep up with the technologies you care about.

Get Started