Why I participated in CSS Naked Day

This article, part of the writing collection, was published on .

CSS Naked Day has come and gone for this year, but I’ll be making it a point to participate for many years to come.

An annual event falling on April 9th of every year since 2006, the raison d’être of CSS Naked Day is to promote proper use of HTML, semantic markup, [and] a good hierarchy structure by completely stripping CSS from our websites.

How long is a day?

Although the event takes place on April 9th, CSS Naked Day actually lasts for 48 50 hours [1]. This is so that no matter where in the world a website’s visitor might be—in other words, no matter their timezone—if it’s April 9th on their calendar, our websites should be served without CSS.

For example, someone living in the UTC+14 timezone will arrive on April 9th first, whilst the rest of the world is still on April 7th / 8th, so we need to make sure that our CSS is disabled by then.

Likewise, someone in the UTC-12 timezone will be in the last timezone to tick over from the 9th to the 10th, so we need to make sure CSS is disabled until then.

This leaves us with a 50-hour period during which time participants’ websites will be served without CSS, stretching from until .

What’s the point?

In a time where the waters of front-end development were churning with the currents of strong opinions and a swiftly-changing development landscape, an individual strode forth to bear the storm’s fury. Suddenly, the currents dissapated and the churning waters relaxed until they were calmed, as the individual spoke clearly forth:

Be the browser’s mentor, not its micromanager

I’ve said it before, but I’ll say it again. Andy Bell’s talk, named above, is one of my all-time favourites. In it, Andy walks through building a website from scratch, and if you haven’t seen the talk, I urge you to do so:

Why am I bringing this up?

At the start of the talk, Andy runs through the high-level CSS technologies he’ll be using to build a website (here’s the website), and, most notably, that they’re all underpinned by progressive enhancement. This is important. As he continues through the talk, he shows that progressive enhancement can and should start way before where we have grown accustomed to thinking about it.

I don’t think it’s uncommon that progressive enhancement is thought of in the context of, I’ve got my page, and I’ll enhance it with this new CSS property for modern browsers, and I’ll even make sure my forms work without JavaScript. This isn’t wrong at all—these are good things to do: making sure that your unenhanced experience works just as well as a fully-enhanced one. Because one experience is enhanced should not mean another experience suffers.

But I think what Andy really drove home for me was that progressive enhancement can start all the way back at the inception of HTML and we can think of CSS itself as a progressive enhancement: we should aim to get as much of what the page wants to achieve just through carefully-crafted HTML.

This means that before we even apply styles, we should make sure that our page follows a clear hierarchy, provides semantic markup, etc. Hold on, this sounds familiar, doesn’t it…

Brass tacks

By stripping our websites of CSS, and even building our websites without CSS first, we are making a clear division between content and styles, and when we do this, we have to rely on the browser’s default method of presenting HTML. This seems to me like a reasonable place to start progressively enhancing the content with styles, so let’s make sure that the foundation we’re building off of is absolutely rock-solid.

We’re doing ourselves innumerable favours by building in this way, too. By making sure that buttons are represented by <button> elements, headings and menus follow a natural hierarchy, what is part of the page’s content is not tucked into a pseudo element, etc. we have baked functionality, styles, and even critical accessibility hooks into our webpages.

By removing veils between us and the browser, we get a much clearer picture of what the browser is doing when it interprets and represents out HTML, and making drastically more apparent when there are issues. Just by preparing my website for this year, I was able to quickly find and rectify a number of problems with relatively-trivial fixes. To name a few:

  • a more-complete understanding of the hidden/disabled/inert/aria-hidden attributes, and finding ways to better use them alongside visually-hidden classes, etc.
  • a number of semantic HTML fixes, not limited to:
    • heading hierarchy
    • presentational imagery
    • hidden content
  • order of content without CSS, where typically I would only concern myself with the mobile order and I am able to reorder items using Flex or Grid

Annual check-up

This was an extremely-rewarding task to work through, and I feel like my website is better as a result of doing it. I’ll definitely be participating for years to come. In fact, unless I change or break things, my website is already prepared for next year, and I just need to wait for the automatic build of my website to occur on April 8th in 2024.

Even though this is an annual event, I think there’s value in checking things out without CSS at regular intervals over a project’s life, if only to make sure everything is whirring and ticking along as it should. I think there are ways to lint or even automated test for some of the issues the practice has highlighted to me, so I’ll have to explore that. I’ve also proposed this to my team at work, and happily (and unsurprisingly, my teammates rule) they’re on-board with adding this to our regression testing!

Looking forward to participating next year and hoping to see your name on the list!