After working as a freelancer for many years, I have forgotten the names of many clients, the budgets of many projects, and even some of the websites I once spent weeks building. What I still remember, however, are the unusual situations that forced me to solve problems in ways I would never normally recommend. A few days ago, while looking through some old screenshots, I found a piece of CSS that brought one of those memories back immediately.
[style="float: right; margin-top: -2em"] { margin-top: 15px !important; margin-bottom: 15px !important; text-align: center; button { float: none; }
}Note: this is a part of a .scss file
I looked at it for a while and honestly could not believe I had once written it. From a modern code review perspective, it looks fragile, overly specific, and closely tied to the current HTML output. But once I remembered the context, the code made complete sense.
The job came from Freelancer.com many years ago. The task sounded simple: update a few layout details on an existing website. The unusual part was that I was only allowed to modify the CSS file. I could not change the HTML, PHP, JavaScript, templates, or any other part of the source code. At the time, I had probably just joined the project, and the client may not have trusted a new freelancer with full access to the application. Restricting me to one stylesheet was likely their way of reducing risk.
When the correct solution was not available
The layout problem involved an element that had no useful class or ID. Instead, it relied on inline styles and looked roughly like this:
<div style="float: right; margin-top: -2em"> <button>Continue</button>
</div>Under normal circumstances, the correct fix would have been straightforward. I would have added a meaningful class to the container and styled that class properly.
<div class="action-container"> <button>Continue</button>
</div>.action-container { margin-top: 15px; margin-bottom: 15px; text-align: center;
}That would have been cleaner, easier to understand, and much safer to maintain. But that option was not available to me. I could not touch the markup, so I had to work with the only unique piece of information the element exposed: the exact value of its style attribute.
The result was an attribute selector targeting the entire inline style string. It was not elegant, and it was certainly not resilient. A change in spacing, property order, or values could break it. The use of !important made the solution even less attractive, but it was necessary because the inline styles already had higher priority than the external stylesheet.
Engineering within real constraints
This is one of the things that becomes clearer after working in software for a long time: good engineering is not always the same as ideal engineering. In an ideal system, we have semantic markup, reusable components, clear ownership, proper access, and enough time to refactor the underlying structure. In real projects, we often inherit constraints that we did not choose.
Sometimes we only have FTP access. Sometimes production cannot be restarted. Sometimes the client refuses a refactor because the budget does not cover it. Sometimes a legacy system is too risky to change. And sometimes we are told that only one CSS file may be edited.
In those situations, the job is not to redesign the system according to our preferences. The job is to make a safe improvement without violating the limits of the project. The quality of the decision should therefore be judged not only by the code itself, but also by the environment in which that code had to work.
That small task taught me more about CSS specificity, inline styles, attribute selectors, and the cascade than many tutorials ever did. It forced me to use parts of CSS that I knew existed but had rarely needed in real work. More importantly, it taught me to separate a theoretically perfect solution from a practical solution that can actually be delivered.
Looking back years later
Today, I would handle the same situation differently. I would first explain the maintenance risks, document the temporary workaround, and recommend adding a stable class or data attribute when access became available. I would also make it clear that the CSS selector was a tactical fix rather than a long-term design.
Still, I do not look at that code with embarrassment. I see it as evidence of an earlier stage in my career, when I had fewer permissions, less influence over architecture, and fewer opportunities to challenge the constraints of a project. My responsibility at that time was not to produce the cleanest possible code in isolation. It was to solve the client’s problem with the access I had.
Years later, it is easy to look at an old snippet and judge it without remembering why it was written. Context changes everything. What appears to be bad code may have been a reasonable decision under severe limitations.
That is probably why this small screenshot still makes me smile. It reminds me that software development is not only about frameworks, patterns, or elegant abstractions. Sometimes it is about finding one narrow path through a system that gives you almost no room to move, and somehow making it work.