37 Theses on CSS and Web Development
Post from August 16, 2018 (↻ October 1, 2022), filed under Web Development.
CSS optimization is important because we, especially as individuals, don’t always write perfectly efficient, understandable, and maintainable code.
Writing quality code, however, is what makes us professionals.
CSS optimization does not entail “everything” that can be done with a style sheet; it entails what makes it more efficient, understandable, and maintainable, while looking for a good balance.
As professionals, we benefit from doing one (or two, or three, but not eighty-five) things really, really well; as web developers, it’s a good idea if CSS is one of those things.
It’s useful when we know our needs.
It’s sound when we develop for the present.
It makes our work easier when we keep it simple.
There’s nothing wrong with doing less work—by automating more of it.
There’s nothing wrong, either, with not doing any work, of a certain type—by automating all of it.
(There’s much wrong with not doing important work because we haven’t yet managed or automated the unimportant work.)
Code should be understandable and for that, it’s useful when it’s consistent and simple.
Simple CSS uses functional or generic names or avoids IDs and classes altogether.
Simple CSS also likes shorthands (yes).
Speed is important.
Selector performance doesn’t matter, and inline CSS is a crime.
(Web development is not software development.)
Some declarations may be slower than others but there’s rarely reason for panic.
Rule hygiene may be most important for CSS performance.
The most basic way to determine quality is through validation, and high error counts mean low quality scores.
Every piece of code gets at least touched twice.
For these last two observations, maintainability and maintenance are critical.
!importantis not an obstacle to maintenance; it’s a tool.
One of the most important principles is separation of concerns. Content, structure, presentation, behavior are different concerns.
In code, we don’t want to repeat ourselves.
Accordingly, in CSS, we want to limit the repetition of declarations.
Optimization for production is an important second step because, in production, machines use our code whereas, in operation, humans use it.
When we cannot production-optimize automatically, we should do as much as we can manually, as part of our craft.
For production, we remove all unneeded characters. All of them.
We typically want to reference one style sheet that includes all styles, though there are cases of high complexity where a modular approach leads to better performance.
(We cannot be absolved from thinking and making decisions about our projects.)
(Exceptions prove the rule.)
We regularly review our CSS, both pre-production and in production.
We are professionals.
As professionals, we feel responsible, we hold ourselves accountable, and we set high ethical standards for ourselves.
And, as professionals, we lead by example.
If you like this or are curious, get yourself a copy of the book.
I’m Jens, and I’m an engineering lead—currently manager for Developer Experience at LivePerson—and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.
If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!
Maybe this is interesting to you, too:
- Next: Web Development and the GDPR
- Previous: AMP, a Strategy
- More under Web Development, or from 2018
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try The Web Development Glossary (2020). With explanations and definitions for literally thousands of terms from Web Development and related fields, building on Wikipedia as well as the MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.