Or: When all you have is a CSS hammer, the world looks like a CSS nail.

Whenever I hear a perfectly nice comment like, “Yeah, representing the tech field!” in response to my pure-CSS art, I get a sharp feeling of panic.

Like many people who work on UIs for a living, I have difficulty applying the “tech” term to myself without feeling like a fraud. Impostor syndrome is a hard thing to shake. A front-end specialist? Oh, you mean the stuff that isn’t really code? That amps up the feeling from impostor to villain.

Even though 90% of my daily work revolves around JavaScript, I feel as if the “tech” label is a shiny trophy that I greedily snatched from someone more deserving. As if there are nameless, starving computer science grads out there and I’m stealing the ramen right out of their mouths.

Take for example this scenario that computer-science schooled people are probably familiar with:

CS Course Problem: Write a script that sorts then randomizes this dataset N times, but for every 8th Q print 12 trees stacks queues void flip flop and you don’t stop rockin’ till returning the sum of the results 4x + 3y. My proposal: (12 hours and eight gallons of coffee later) Done! Here are 1,200 lines of beautifully formatted code! There are forty-three loops, thirty-two if/else conditions, and eighty-three lines of comments because I keep getting lost in the file — but I’ve achieved the exact desired result! CS Course Answer: Use three lines of recursion. My response: …%#@& you.

An exaggeration, but it’s helpful to be regularly humbled like that. It helps you grow as a programmer, problem-solver, and human. Plus, it prepares you for real-world scenarios in your career where you will regularly come across interesting challenges that require a bit of creative thinking.

When it comes to the CSS side of things, no employer will ever ask you to produce a detailed painterly CSS art piece. If they do, you really should immediately report that as harassment to HR. But it is very common to have a small and sometimes unusual request. One that may not have an obvious solution right away.

The “tech-free” CSS — with its glaring lack of programming functions — may not immediately come to mind when given such a challenge. But make no mistake, it can be one of the most valuable tools in your algorithm arsenal! For example:

CSS Course Problem: A disclaimer message needs to pop up into view as a warning when a user clicks a certain input field. Proposal: Piece of cake! We use our trusty friend JavaScript to trigger a click or focus event on the input element. Then we load the disclaimer template. Then we make an Ajax call for content. Once our Promise() is resolved, we append the element to the page and find where to insert it by way of finding the event.target ’s parent element. After the disclaimer is loaded, we need to ensure that we’ve handled another click event on the actual disclaimer itself to toggle out of it. Once we’ve toggled out of it, we destroy the element. If the input is clicked again, we repeat this process. CSS Course Solution: input:focus + .disclaimer { display: block; } Response: …%#@& off.

Again, it’s an exaggeration (and the world’s least efficient JavaScript solution), but it’s only a slight exaggeration. I see those types of proposals being put to use way more often than you’d expect. Being able to provide ridiculously quick solutions to what have long been thought of as lengthy JavaScript problems? That’s one of the ways in which CSS allows me to feel like a master of tech.

This is just one of the many things I love about CSS. The limited set of rules is exactly what makes it so fun. You don’t expect CSS to fulfill all of your needs, which is what makes it all the more rewarding when you end up finding a way that it can.

Now, say there’s a design challenge. You’re asked to implement this shape in the browser:

Proposal 1: “There’s no “reverse-border-radius” property to create that shape in CSS, so that’s not possible. Just embed an image. Duh.” Answer 1: Okay fine, don’t learn CSS for all I care.

No please come back! I want you to learn.

It’s true that no one will penalize you for using an image. There are no CSS police enforcing this rule. Hell, there aren’t even any computer science police stopping you from using a terrible billion-line algorithm instead of a beautifully simple recursive one. But if there’s any concept to be shared between CSS and CS it’s that “not possible” is hardly ever the answer.

So let’s try a brute-force method, shall we?

Proposal 2: Start with a black rectangle, then notch out the sides with two border-radiused <div> elements that match the white background color, like so:

Answer 2: Alright! Now we’re getting somewhere. The shape is coming together. But what if the background is varying? Or a gradient? Or an image? How would that look?

Hm. No longer looks quite as nice. So how we do allow our natural background to shine through, while still keeping a sloping-inward shape — something that CSS isn’t natively built to support?

Proposal 3: Keep the rectangle. Keep the curved divs. But don’t fill the rectangle with color, and don’t fill the curved divs with color either. Instead, spread the black color outside of the curved divs, using box-shadow . The rectangle will simply need an overflow: hidden; to keep that box-shadow color contained within its boundaries.

Answer 3: Well done! Beautiful!

The above technique has been described in even better detail in Ana Tudor’s excellent post on scooped corners. And it’s an excellent concept to keep in mind when presented with “not possible with CSS” problems. It’s one that I love to use when creating art.

Take, for example, this portion of one of my CSS paintings:

The human neck unfortunately does not usually come conveniently packaged in a perfect rectangular shape. But HTML does, so that’s what we have to work with.

But wait, isn’t that neck-shape pretty similar to the curvy black shape that we outlined above?

Yep, it all started with a big rectangle. In this case, our outward-curving divs just used a softer blending on their box-shadow.

Outside of work, I keep coming back to CSS for artistic inspiration.

Because something about those limitations just calls to me. I know I’m not alone when I say that a rigid set of restrictions is the best catalyst for creativity. Total artistic freedom can be a paralyzing concept.

That can sometimes be the case with programming. If you have the most powerful programming languages in the world at your disposal, it starts to seem natural that you should then have no difficulty solving any programming problem. With all these amazing tools offering countless solutions to solve the same problem, it’s no wonder that we sometimes freeze up with information overload.

Sure, CSS can be thought of as not being a “true” component of the tech stack. I would not even argue against that. Let’s face it, pure CSS is not about recursion or data storage or database-querying. Its primary purpose is indeed for prettification — which doesn’t exactly help the stigma of front-enders not being “real” techies or programmers.

CSS never made any bold claims or promises. It has merely offered assistance, and it just turns out that its assistance can be downright heroic.

If you are a front-ender who has to deal with a bunch of DevOps folks mocking their CSS, just wait and see what the response is when you sneak a body { display: none; } onto production. We’ll see who’s laughing then!*

* They will still be the ones laughing because you will be fired. Please don’t do this.