Code golfing is a type of programming where the goal is to accomplish a task using as few bytes as possible. CSSBattle is a code golfing battleground where players complete to recreate target images using CSS and HTML.
The rules are fairly simple:
- No external resources (sorry, no
- Your solution must render correctly in Chrome (just for scoring purposes)
This can be a pretty fun departure from day-to-day front-end work. There’s no need to worry about maintainability, semantics, performance, accessibility, or anything other than making a thing really, really small and still render correctly.
A golf solution in 12 attempts
This type of thinking is a pretty dramatic departure from how most of us are writing front-end code for production sites (I hope!), so I’ve been posting all of my solutions on GitHub in an effort to both share some knowledge and learn from others. As a fortunate side effect, it also means there’s a fairly detailed history of my submissions.
Here’s a start-to-finish account of my attempts CSSBattle’s 7th target, which looks like this:
The “just center the dang thing” method
A reasonable first approach is to simply stick an element in the middle of the page, slap a box shadow and a border radius on it, and call it done. If we were writing this “for real,” it might look like this:
< !DOCTYPE html>
But that’s 423 bytes! That won’t do for CSS golf, so let’s see what we can remove.
Attempt 1: 144 bytes
Here’s a golfed version. There’s definitely some weirdness going on here — no
< !DOCTYPE>, no
, no nothin’. The browser doesn’t need them (and, in fact, inserts them for us), so we save a lot of bytes by leaving them out. We’re using
since it’s shorter, and we don’t close the tag at all since it’s not required for things to render.
The CSS itself isn’t much different, aside from the fact that we’ve used a huge box shadow instead of a background on the body element (“
background” is long so avoiding it can be beneficial). It’s also inlined in the element since a
tag costs extra bytes.
You may have noticed that we used
5in for the spread in our last box shadow. Playing with weird units is a huge part of CSS golfing. In this case, we just need the shadow to cover the 400×300 canvas and ‘
480px) is shorter than any pixel value.
Attempt 2: 141 bytes
This introduces a pretty important golfing trick: replacing spaces with plus signs allows us to remove the quotes around attributes, saving a couple bytes. I’m not totally sure why this works. Someone suggested it may be related to this part of the HTML spec. If you have a better answer, please let me know!
This attempt also cleans up a couple of whitespace mistakes from the last attempt.
Attempt 3: 126 bytes
tag instead of a
- We no longer spend bytes setting height or width on a paragraph
- We get access to
bgcolor is a deprecated attribute that comes up often in CSS golf solutions. It only works on a few tags (
included), and does two great things:
- Saves us from spending bytes on “
- Saves us a byte by allowing us to omit
#in hex colors. Additionally, if a color ends in one or two zeros, we can remove them and it will still render correctly. For example,
FFFF00is the same as
There’s a golf regression in this iteration! Can you spot it?
The “border” method
By this point, I had spent quite a few hours tinkering on and off with this target and was getting pretty stuck. Fortunately, CSSBattle has a friendly community on Spectrum that is more than willing to lend a hand.
At the time, Praveen held the #1 spot with two bytes fewer than I had managed, so I asked for some help. He suggested leveraging both the
elements to position everything while using borders in place of a background color.
Attempt 4: 126 bytes
This is a pretty huge departure from our last strategy. Our body tag is gone and we’re using
to target the
tags that the browser inserts for us. The combination of
border nudges our shape exactly where it needs to be, and the
covers all the excess stuff you’d see from styling on
This was tough for me to grok, but Praveen made a diagram that explains things pretty well. Here’s a prettied up version:
b are the margin and border on
c is the margin on
. The right margin on
doesn’t do anything since there’s no room to push the
to the left and it already has zero width.
Once our box shadows are applied,
b is covered up and all that’s left is our target image.
There are still some optimizations missing here though. Dorus van den Oord was able to take the border method down to a lean 121 bytes, offering this cryptic bit of advice:
small hint for getting to that 121: What if you could move an element by a quarter of a …?
Attempts 5 and 6: 122 bytes
Turns out all we needed was a unit hardly anyone’s ever heard of (
q) (and the humble
vw). Having to write “
px” is rarely correct in CSS golf, so it’s something to be on the lookout for. Here, we can replace
q, or quarter-millimeter, is exactly that — 1/4th of a millimeter, or just under a pixel. The
q unit is a staple of CSS golf as one of two values (the other being
%) that require just one byte to express. I’ve combined my 5th and 6th attempts here since both were just unit tweaks. We’re still a byte off from 121 though!
Attempt 7: 121 bytes
We finally fixed that regression from the third attempt, thanks to a pull request from Praveen. A percentage doesn’t need a space between it and subsequent values, so we can save a byte in our
border-radius. This is a great example of how sharing code can help everyone involved. I had been stuck on this for a pretty dang long time.
The “funky margin” method
Borders aren’t the only approach, though! Enter Rasmus Fløe’s funky margin:
I got 123 chars on #7 by using
box-shadowand a funky
margin:75 400 75-150🙂
Attempt 8: 120 bytes
Here’s how this works, as Rasmus explains it:
positive right margin pushes it off canvas to the left — and negative left margin stretches the element to the wanted width 🙂
Here it is drawn out:
The right margin (
b) pushes the
element all the way to the left, collapsing it to zero width. The negative left margin (
a) then stretches it back to
150px wide (the width of the leaf shape), and then our box shadow (
c) is offset enough to be in view. This is awesome because we no longer have to deal with negative box shadows in order to get everything to layer correctly.
We’re also back to
bgcolor and get to leverage a nice quirk of background colors: because
doesn’t have its own background color, it inherits one from
Attempts 9 and 10: 118 bytes
With a bit more unit-wrangling we’re able to save ourselves two more bytes (props to Dorus, who was the first to discover this optimization). Adjusting the margins saves a digit (150 becomes 90), and, as a sweet bonus, we get to convert
70mm, which becomes
7cm. I’ve again combined two attempts here which were minor unit fixes. (I’m embarrassed to say I initially missed the
Attempt 11: 117 bytes
Romain Deltour was the first to find this 117-byte solution. Changing
85% means we get to omit a space after one of our values (just like we did with
border-radius), saving another byte.
Attempt 12: 115 bytes
I really love this because — not only is it dang clever — but a lot of people (myself included) thought the target had already been fully optimized. Viacheslav’s persistence both sparked a new round of discussion and added another CSS-Trick™ to our arsenal for future targets.
This seems awfully close to optimal to me but that certainly doesn’t mean it can’t be beat — why not give it a shot? There’s prior art to get you started, plenty of folks willing to help, and even some tooling. Happy golfing ⛳️
CSS Tricks Go to Source
Powered by WPeMatico