Story time!
For further actions, you may consider blocking this person and/or reporting abuse
Story time!
For further actions, you may consider blocking this person and/or reporting abuse
dev.to staff -
Rachel Fazio -
Sanjay R -
Maina Wycliffe -
Top comments (41)
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...
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.
"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:
Everything on the page that could overlap is defined above.
Well, I had once assumed that
vw
andvh
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.
Everything that I write
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!
The horror when you realize that people begin adding inline css rules with
!important
...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 :/
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.
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: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.One of the worst CSS I usually have to deal with every once in a while looks something like this:
One of my colleagues thinks it's best to write "COMPRESSED" CSS from start instead of compressing it later on.
Somehow that has been my experience with every bootstrap based site I've had the pleasure to get my hands 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
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 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.
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){}
ie11 lol ;)