Cale Byers

CSS Refactoring for Better Design

Updated . Posted

My website has been through many phases in the last 3.5 years, and I wanted to reflect on the journey. At one point, I was just putting up plain html with no styling, and even a plaintext file. As I learned more things and observed others' design choices, I included them, bit by bit, like a decorator crab. I learned how CSS works, eventually buying a book and jotting down important ideas.

My CSS file had become a sprawling mess, exacerbated by learning about media queries. The end result was conflicting rules, where stuff would be overwritten by certain later rules. My file didn't have an optimal layout, and my structure enabled this deficiency. After reading a helpful article on generic-first CSS, I knew it would solve these issues. However, I had no incentive to make the changes. It wouldn't change the appearance of my site, only make my CSS slightly smaller and faster for rendering a page.

My site lacked a coherent and consistent design, so I decided to re-do it while quarantined under the COVID-19 hysteria. I have long admired the sites of Zoe Pinheiro, Chloé Jarnac, and Chris Hieronimus. For desktop layout, all three sites feature a left sidebar, and an image gallery to the right. The look is clean, simple, and effective. Some scroll vertically, some scroll horizontally, and others use a grid.

Currently, the desktop breakpoint at 801px is more polished. The mobile layout needs some work. I started out by defining boundaries. For screens 801px or wider, the header of my site would occupy 25% of the left, and the main portion would take the other 75%, so that a definite structure was enforced.

header {
    position: fixed;

I then played with the list styling, using the <details> and <summary> elements to provide an expanding photos list within the navigation list. By adding an open attribute, I made the list stay open when on specific photo pages. It is closed for all other pages, like the blog, or the homepage.

A lot of people don't understand that you can click on a <summary> element, so you have to style it like it's a button, or a link. Here's what I do for anything in the main section.

Click me for code example!
main summary {
    border: medium solid grey;
    border-radius: 10px;
    padding: 0.5rem;
    cursor: pointer;

It took some time fighting with conflicting CSS rules, so I ended up creating a new CSS file, and starting from scratch. This enabled my new visual layout to guide the structure of the new CSS. I wrote with generic-first principles in mind, and I found it very easy to work this way.

For simplicity, I chose to only have two breakpoints: less than 801px wide, and then anything above 800px. This is the approach taken by Chloé Jarnac's site, which I am particularly fond of. In the CSS file, I start with constant rules, which will not be modified by media queries for different sized devices. However, I go even further and only put the common ones at the top. Less common rules go towards the bottom of my file. I don't know if it makes a difference, but I don't need the browser to parse those rules if they're uncommon.

I need to determine if the ordering of my constant rules makes a difference. If they are all at the bottom, then they would overwrite anything in the media query sections. So further experimenting is needed.

Next is the set of rules for phones and some tablets (less than 801px). Then a segment of rules for anything larger sized. After that, the other constant rules, but for things that are uncommon, like inputs, buttons, and special elements, like preformatted text, or details. Things that are uncommon but important nonetheless.

I have a media query for printing, so when people print my résumé, it looks more like a printed résumé and less like a webpage.

.will-print {display: none}
@media print{
    html {font-size:12px}
    header {display:none}
    .wont-print {display: none}
    .will-print {display: initial}

All of this refactoring saved over 100 lines of CSS. My file is now much smaller, and it has an intuitable architechture. I know how it is structured, and I know how it works. I know why it is the way it is, and I know how it contributes to the visual layout of my site. Without defining a coherent structure, I wouldn't have had the desire to optimize my CSS in a generic approach. My blog was previously on its own, not part of the rest of my site's layout. Now, everything is the same. All pages have the same structure, and the resulting site is much more polished. It looks nice. It is clean, and it's simple. My CSS file is tiny (less than 5,000 bytes), and my site loads quickly.

I'm in the process of implementing responsive images, using the sizes attribute, to specify which file is best for particular sized screens. Once I get that finished, I'll make another post, though much has already been written elsewhere. I'm only focusing on the dimensions and why I chose them, based on device compatibility. I also have the loading=lazy attribute, and I preload my CSS and JS, so that modern browsers can load my site even more quickly.

At this point, the major task is to go through recent photos and update my portfolio. Eventually I would like to have a grid, like Chris's site, but I don't have time to deal with it. I'm starting some classes and am only able to work on this site in limited bursts. Once I get there, I'll be using the modern CSS grid, which is pretty exciting. I'll probably update my barba.js library to the 2.0 version as well.

Web design is a lot of fun, and I like to implement efficient versions of common design patterns. The templates I linked to are all very large. My site doesn't have the same set of features, and I've invested a lot of time into it. I could've spent this time shooting more photos, making food, or doing anything else. I think for a lot of people, it makes sense to pay for web design, either by hiring someone, or using a slow templated site. At the end of the day, you probably aren't shooting for clients in Arkansas or Africa that are on throttled 2G networks. You're probably marketing yourself to affluent, white people with fast internet. So you can ignore the structural problems of a templated site and force people to have the latest iPhones to have a good browsing experience.

However, I actually want to learn about web design, and I want to have a quality site. The code behind a webpage is as important as the visual layout. Don't believe me? Go visit your friend's Wix site, and twiddle your thumbs while it loads. It is probably going to take 5-15 seconds, and it will load 2-10MB. On the other hand, my site loads in less than a second, and it's very small, generally less than 0.5MB, but sometimes more for higher resolution photos. That's to be expected. A javascript payload the size of a 2048px photo is unacceptable.