This is a real worry these days. I’ve heard it from lots of lots of developers. The years tick by on their projects, and all they ever seem to do is add to their CSS, never remove. It’s not just a feeling, I’ve talked with companies before that track hard data on this. Over five years of tracking the size of their stylesheet, and all it’s ever done is tick upwards in size.
This could be considered problematic for several reasons:
- Files getting bigger is worse for performance
- The developers are afraid of the CSS
#2 being, in my opinion, a much bigger deal than #1. The overall file size of CSS is likely to be fairly small compared to things like image assets and even the JavaScript payload these days. Fancy tooling and the world’s internet speed ever-lurching faster will probably make #1 not that big of a deal.
But being afraid of your own styles is a bigger problem.
“Afraid” isn’t usually how this problem is talked about, but I think that’s what it amounts to. It’s often talked about in terms of how the global nature of CSS is problematic or that the middle “S” in “CSS” is the only one worth saving.
“Unusued CSS”
Part of this story could certainly be about deleting CSS that is determined to be “unused” in a project. I know there is incredible demand for this kind of tooling. I feel like there are some developers damn near frothing at the mouth to blast their CSS through some kind of fancy tool to strip away anything unneeded.
This worries me just a little bit. It feels like saying: “Yes, I am afraid of our stylesheets. I don’t want to understand them, I just want something to fix them for me.”
Here’s how one company I heard from was doing it:
- They injected a script onto the page for some subset of users.
- The script would look at the CSSOM and find every single selector in the CSS for that page.
- It would also run a querySelectorAll(“*”) and find every single DOM node on that page.
- It would compare those two sets and find all selectors that seemed to be unused.
- In order to get the best results, it would fire this script after a random amount of seconds, on a random set of users, in a random set of conditions. Even with this, it needed a lot of data over a long period of time.
- After that had run for long enough, there was a set of CSS selectors that seemed likely to be unused.
- To be sure, unique background images were applied to all those selectors.
- After applying those and waiting for another length of time, the server logs were checked to make sure those images were never accessed. If they were, that selector was used, and would have to stay.
Ultimately, the unused selectors could safely be deleted from the CSS.
Whew! That’s an awful lot of work to remove some CSS.
But as you can imagine, it’s fairly safe. Imagine just checking one page’s CSS coverage. You’ll definitely find a bunch of unused CSS. One page, in one specific state, is not representative of your entire website.
Websites have multiple pages. JavaScript runs on them affecting the HTML. Users may log into them, displaying things in a different state. Dynamic things happen on websites. In order to really know what CSS is used, you’d have to test every possible page in every possible interactive permutation, which is a tall order. I’m sure you can imagine some CSS that applies only to a select menu for a logged in user with an expired subscription who has logged in to update a credit card which happens in a modal window with a form that displays a certain way because the card is American Express.
All that said, there are tools that purport to help you find unused CSS
Chrome has a “Coverage” panel (in Canary as I write) that can tell you what of your CSS is used:

It’s pretty nice in how you can hit the Record button, click around and do a bunch of stuff (even changing pages) and it will continue analyzing how much of the CSS gets used. Then you can see what is used or not with the red or green bars next to the CSS.
It suffers from the same problems that I described, in how you just clickin’ around isn’t enough to guarantee coverage. You’re very likely to miss edge cases, and if you make choices on CSS to delete based on your incomplete testing, you’ll be causing yourself problems.
There are other tools that take a stab at helping remove unused CSS, UnCSS probably being the most popular.
UnCSS does some smart stuff, like allowing you to list a whole array of URL’s to test together, provide media queries to apply, and runs JavaScript. Here’s their example configuration:
var uncss = require('uncss');
var files = ['my', 'array', 'of', 'HTML', 'files', 'or', 'http://urls.com'],
options = {
ignore : ['#added_at_runtime', /test\-[0-9]+/],
media : ['(min-width: 700px) handheld and (orientation: landscape)'],
csspath : '../public/css/',
raw : 'h1 { color: green }',
stylesheets : ['lib/bootstrap/dist/css/bootstrap.css', 'src/public/css/main.css'],
ignoreSheets : [/fonts.googleapis/],
timeout : 1000,
htmlroot : 'public',
report : false,
uncssrc : '.uncssrc'
};
uncss(files, options, function (error, output) {
console.log(output);
});
I’d still worry that this would be difficult to configure (and keep configured) such that it provides 100% test coverage. Everytime you wrote a new CSS rule, you’d need to make sure it didn’t trigger a false positive here. That is, presuming you actually use this tool to delete CSS.
Not to mention that, while it does execute JavaScript, it’s not simulating interactions.
Another approach: frameworks
Imagine you used a CSS framework that provided every practical bit of styling you’d want to apply. Rather than writing CSS, you’d apply the classes that the framework applied to do what you needed to do. You’ve now tied your HTML classes pretty heavily toward this framework, but you’ve solved the growing CSS problem. Over the years, your CSS will remain flat.
I’m no expert in Tachyons, but that’s what it seems like to me. After you get used to using it, you get pretty speedy at coding up what you need with the side benefit of this rarely-changing static CSS file that nobody is afraid of.

This falls into a category that has come to be known as Atomic CSS, of which there are many players. A version of Atomic CSS is “programmatic”, in which you use special classes and a processing step generates the final CSS for you. The idea being that now you aren’t shipping a static framework of CSS, but only the very little bit of CSS you actually need.
John Polacek recently wrote about this. He’s finding that he both suffered from the growth of CSS problem, and found that Atomic CSS not only stopped the trend but reversed it:

Heck, even frameworks like Boostrap, Foundation, Materialize, or Bulma fit the bill here. The idea is that if you stick to the framework, you’ll never get to that undesirable state of being afraid of your own CSS.
CSS in JS
Managing styles in JavaScript (recommended reading) also can help with this problem. Styles that are entirely scoped to a particular module are, by nature, easy to delete. Don’t need the module, don’t need the styles.
Don’t worry too hard
I find all this stuff fascinating to watch and think about. As is often said: the web is a big place. All of us have unique circumstances. This problem affects some percentage of us, and dare I say, probably a fairly small percentage.
If you aren’t particularly worried about the size of your CSS and aren’t particularly scare of it, good! Neither am I, on most of my projects.
I just have a feeling (a prediction, really) that there is a modular future for CSS:
When we write styles, we will always make a choice. Is this a global style? Am I, on purpose, leaking this style across the entire site? Or, am I writing CSS that is specific to this component? CSS will be split in half between these two. Component-specific styles will be scoped and bundled with the component and used as needed.
What the prodominant tooling for that will be, I am unsure, if there even is one.
This post explains the very reason I don’t use certain very popular frameworks like bootstrap. I find when I run tests on sites using bootstrap there can be up to 90% of unused css. Bootstrap brings with it a lot of css, which simply isn’t necessary for most projects, nor is it good for SEO in any way.
Personally, I like to use smaller frameworks and build on them, like getskeleton.
Bootstrap is split into smaller components. You can omit the components you don’t need using the SASS version of it. Bootstrap shouldn’t be blamed for lazy developers.
The problem is that developers don’t know when to use Bootstrap, not in the toolkit itself.
When you are provided with a design and/or are working on a scalable project, Bootstrap should not be your choice. First, because it is messing with your CSS architecture, conventions and is very overwhelming when you need to overwrite styles.
Personally I (and I think most FE developers) can style my components if given a design faster than implementing bootstrap and spending time overwriting its classes.
Bootstrap in my opinion is good for some fast demo project, blog, or presentation site where you don’t have design and you don’t have to think about one that much. Anything besides that is not worthy. Much better start from scratch and build a reliable architecture with good conventions.
My latest approach is:
Main stylesheet only for global elements.
Dynamically add a stylesheet per page with the css for that page.
Ok so i end up having lots of files and each page accessed by a visitor there will be a file they need to download that is not in their cache but it is a small file and long run much more manageable.
You could in theory combine these two files into a single file, by importing the global styles into the page stylesheet.
Well, usually I am doing this in wordpress so I have all the css minified and combined when rendering.
So there are a lot of files on the server that I need to know what belongs where but I add a comment at the top of each file so I know what page/s are using it.
The css is not cached by the browser this way, I mean it is but each page has different css so even the global css needs to be downloaded on each new page view, but it means the css is tiny per page and much easier for us to manage. Right now this is the winning strategy for me but it may change in the future :)
Great topic and article. This is a painful issue in my experience as well. I think the main issue is that we can’t just remove old CSS. We need better tools to test CSS and styles.
Javascript components are covered with tests, which give me the confidence to refactor them. With styles, we don’t have a good way of testing yet.
There are semi-automated testing utilities (screenshot diffs mostly), but these still require people to go over, and sometimes it’s hard to say whether a change is intentional or a bug.
Would love to hear if someone has more ideas on how to tests styles. :)
From a freelancers perspective, there’s nothing more overwhelming than a face full of CSS – far easier to append than to amend. Which I think is the root cause of the Ever Expanding Style Sheet.
Perhaps a root and branch overhaul of how we manage CSS is needed – core styles which are sacrosanct and remain unchanged (only modified after an official review) and then modular styles which are added on top.
I’m thinking of Harry Roberts’ inverted CSS triangle here, something along the lines of https://www.groundwork.rocks/organisation/
My strategy is, one SASS file per markup file (in a static site this might be one for each page template, in a React site it would be one per Component file). Within each of those, the nested selectors directly mirror the markup structure, and use direct-child selectors (>) as much as possible. I make sure the component’s root class name is strictly unique using strong naming conventions, or in cases where each template represents a page, I’ll actually use an ID for each page. Using nested selectors and direct-child selectors both drastically reduce spillover effects, and breaking things up into modular files makes the whole thing much less scary.
I prefer this approach as well. Mostly working in WordPress, I tend to have Sass broken down to global, page, and plugin folders; global including Sass files for header, navigation, footer, and typography, page files starting as simple as archive and single, and plugins creating Sass sheets as needed to support custom styles – expand from there as needed. With Magento development I like to approach it similarly with global files and component files matching to modules vs. pages/templates in WordPress. When a plugin/module is sunset from the project just remove the Sass sheet, or when another dev needs to adjust the archive view it’s obvious where to go so folks shouldn’t have to feel worried about inadvertently removing something they shouldn’t.
Hi Chris,
I beg to disagree. CSS is a render blocking resource — unlike images and scripts — it is directly linked to perceived speed (UX). And don’t get me started on the “world’s internet speed”… :)
No, I’d get you started with “inject the CSS critical path into a
<style>
element in the<head>
and lazy-load the rest”.In reply to @MaxArt
Actually, it looks like you are agreeing with me when you say that.
Are you suggesting to do this to speed up page rendering (because CSS is a blocking resource) or are you suggesting that that is enough, that there is no need to go beyond that to increase performance even more? I’m confused…
This is one reason I try to separate my classes between functionality and styling. For example, when I want to give an element an on-click event I add a descriptive class to it like
js-toggle-menu
and hook to that in the JavaScript, rather than hooking directly to the class name I used to style it.I’ve worked on too many projects where mucking with the CSS classes inadvertently ruined some functionality—granted that’s more of a markup issue than a stylesheet issue!
One approach that’s helped me greatly be less afraid for looking back at old css is adopting a pattern for my styles: BEM.
Everything gets a class and classes that describe a modified state. It allows me to create uniquely designed components and generic components which helps reduce adding css to my projects.
Media bubbling using SASS helps a ton, too. Having your media queries next to each class is a boon for media query maintainability.
If you plan and aim for modularity in your CSS, you have maintainability baked in.
When css gets out if hand, probably one of the more frustrating and defeating problems in front end dev… Especially when you jump in on the project and are just greeted with a wall of heavily nested selectors.
Completely agree. Using BEM or similar naming convention brings an advantage of always having scope to the CSS block you are dealing with, so no overwriting of CSS happens. Combined with separate files for CSS blocks (BEM blocks), you are clearly notified of overwriting your CSS by creating duplicate file.
In some cases it might cause unnecessary growth of css, such as rewriting grid functionality several times, but that can be solved by creating some kind of “utility” class prefix (u- for example), which would be used for classes taking care of general stuff.
BEM helps create confidence in deleting unused CSS, but the style sheet still generally continues to grow over time. I prefer the practice of using Atomic CSS and then using CSS Modules that compose those atomic classes. So the styles for a module are accessible within its CSS, but the stylesheet never grows much.
On another end of the spectrum from UnCSS is PurifyCSS. It can be fed a bunch of html, js files (via a plugin for your favorite bundler/task runner), which it will parse for class names, tags, etc. and then prune your styles leaving only used rules behind.
I’ve been using that technique for years. CSS bound to a certain component is styled by that component’s unique ID, whereas CSS written for global use targets classes or elements directly. I find it very easy to keep my CSS tidy this way.
Nice article, I’ve even encountered websites where we had to split the CSS file because IE wouldn’t read them entirely (because of the selector number limits in old versions).
I disagree with you about the solution of styles within the JS: depending on the way you do it, the styles embedded may apply to the whole site, and not only your component, thus, when you create another component, you may inherit the styles of a previous component: you will use them without even knowing it, and the day you remove the initial component, you will lose the styles that were also applying to other components.
IMHO, namespacing is the solution.
I definitely go with BEM.
For most CSS in JS solutions, the styles are scoped to a component, so they won’t leak into another component. So I’m not sure where you are getting this idea from.
Thank you, thank you for this article. It helped me distinguish a core CMS system vs. a framework and how they interact. It guides me on better understanding the logic behind the coding.
This is why I’ve recently started scoping my CSS. All CSS that will go on every page, eg buttons, links, headings, will go in the main CSS file. Any extra CSS that is page specific will be in a separate file loaded only on that page. Any CSS which will be used by certain modules which are inserted into the code either by PHP include function or using Ajax, eg header, footer, commun popup dialogues, will have a separate file loaded within that Ajax or include.
This way each page only loads what it needs!
Atomic CSS. Nuff said.
As front end devs we used to created these amazing CSS components based content, give them names related to their domain, sometimes generic names based on what they do… It was beautiful.
Then, you walk into meeting one day and you get asked to change the way a component looks just for a couple of cases. No biggie, just add an extra style for that case… Wait. Did I say ADD an extra style… It has begun. The swelling CSS file is on its way. Eventually, you make so many changes, your not even sure what it does anymore. So, you just create a new set of styles. But, you can’t remove the old ones, because somehow along the way some completely unrelated component now relies on some part of the Frankenstein.
These components could also never be reused. It was as good as hard coding.
Atomic CSS, I use Tachyons, for reference, provide all the building blocks needed to create almost any style. No overrides, no ! important, just style as you go. First, it feels a little like repeating yourself, but then, the first time you need to change something, you just do it. No side effects. That’s the money. If you still need to feel componenty, just wrap the atomic styles in a class and apply that. I personally prefer to go all in and just chain those classes together.
It means you html actually explains the styling… You don’t even need to open the CSS file to see what’s being applied.
Tachyons is also a mathematical system, meaning you get consistency. No more arbitrary padding, margin, width and height depending on the developer.
Anyway, I have totally felt the burn of the growing season CSS, and I concur that atomic CSS resolved the majority of my concerns.
Great article!
I really dislike atomic CSS: not only it tightly couples the site to the framework used, but completely trashes the semantic value of classes in HTML.
If we put presentational vales into HTML we make a mistake as that value might be interpreted differently in some cases: what would classes like
p10
orhelvetica
mean for a screen reader? What wouldbg-gold
on an e-ink display?We’re tricking us into thinking they always do what we expect, and while removing semantic value from the page we’re also making our elements harder to understand and debug (what’s the purpose of that
<div class="p5 mh10 bodoni fl">
again?). Not to mention media queries get awkward.Yes, style sheets get minimal or non-existent (they could be generated), but also our HTML get populated by a plethora of tiny classes whose name is clear only to the initiated. And anyway CSS rarely brings a performance issue… if it does, it’s time to refactor!
I think the best approach is the modular one: small sheets for small templates, both maintainable and isolated in scope. We can get it in several ways, including transformers, CSS in JS and also using naming conventions like BEM if we don’t get to use more modern tools.
I’m sorry but there is no such things as “semantic value of classes”, at least not as you infer it; as far as I know, screen-readers don’t care about class attributes. You could make the case for “Microformats” and the like but that’s irrelevant to the discussion since their purpose goes beyond styling. More about this in this article I wrote.
CSS is a key player when it comes to performance (CSS is a render blocking resource). There is a reason why we have tools that extract and inline “critical CSS”.
In any case, “it’s time to refactor” is really something you hope you’ll never have to say; and the great thing with “Atomic CSS” is that there is no such thing as “refactoring”.
The best approach is the one that solves one’s problems and because not all devs have the same problems, there is no best approach…
Thierry, I’m sorry but you misinterpreted quite a bit of what I’ve said.
Sure there is. Of course, it’s not for the end user: it’s for the developer. Because code doesn’t have to just be consumed, it has to be maintained. Wasn’t that clear in my comment that I was talking about development?
There’s an old saying that goes by: “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” (John Woods, 1991). And also: “Programs must be written for people to read, and only incidentally for machines to execute.” (Harold Abelson, 1984).
Definitely not the point. It’s a blocking resource as long as the page is first loaded; with lazy loading the problem is basically solved.
That applies to any kind of resource that’s fundamental to make the page reactive as soon as possible, including scripts. The point is that you can have fairly big stylesheets weighing in megabytes, and still have browsers deal with them fairly well. Conversely, parsing and compiling JavaScript may cost significatively more (1-10ms per kb on mobile devices), and that always blocks the main thread, even when lazy loaded. Not to mention the execution.
The main performance impact of CSS is about painting and reflowing content. That’s the “execution” of CSS and that might render a page sluggish, and it’s not solved by atomic CSS.
Which still has to be applied to atomic CSS as a good measure anyway.
Fair enough. The bad thing is there’s plenty of reasons why atomic CSS isn’t the right choice anyway.
On the other hand, modular and scoped stylesheets basically eliminate the refactoring problem too (if a modular sheet needs to be refactored, it’s very likely that’s the whole component that needs it – the converse does not apply).
That’s a justification for spaghetti code and monkey patches too. I.e., technical debt.
I’ve coded stylesheets for a very large variety of sites and applications, from simple landing pages to large CMSs, I’ve tested atomic CSS too but it never seemed to be the right choice to me as disavantages greatly overwhelmed any possible gain.
The best use cases are indeed simple landing pages that don’t need to be maintained – but more often don’t even justify an atomic framework; and simple mockup pages, for the same reason – which could often be exported by design tools with all the presentation in
style
attributes or in CSS with classes that reflect layers and groups used during the design process.For the rest, I’ve rarely seen uglier and innatural solutions to modern web development than atomic CSS. Even things like CSS and HTML in JavaScript looks mich nicer in comparison.
@MaxArt
I’ll keep it short:
We came up with Atomic CSS at Yahoo! to reduce our styles sheets by more than 50% (greatly improving perceived speed), facilitate the sharing of components between teams, promote better caching, speed up time from prototyping to production, help on-boarding new hires, and more. All of those are big wins. “Ugly and innatural” may be a reason for you not to be willing to use it, but I don’t think it’s a valid argument against its use.
Hey, I see where you’re coming from. But I just don’t agree.
I’d like to know more about what you mean by semantic… Because it’s exactly that which causes some of the issues.
To the uninitiated, your single class may actually be harder to figure out what is happening, than my 8 small classes. You put more than one declaration in a style right? So now, I have to open up the stylesheet and see what’s on that class. Then that class may have a parent which is affecting it. So I have to go look there too, and so on it goes. Your wonderful cascade of styles makes sense to you, and only for today. Typically, you are also using your html structure to define styles. div > ul > li.fun is perfectly fine right… But what you actually do, is introduce a dependency. You can’t just change the style, or the markup. Things just get brittle.
Business domains change over time too, so you may think it makes sense to call it what it is in that sense, but you are wrong. Creating an .order class might be ok, but then again, nothing you put in that can be used anywhere else. What if your boss comes and says now we need to make this new thing, exactly the same as an order with a couple of differences, what do you do? Copy and paste the order module and rename everything to new name? Do you try to make the common stuff common and subclass the differences? In the end, you are forgetting that’s CSS is only meant to style the markup. It’s not meant to provide meaning outside of, what does this make that markup look like? That’s what CSS should convey. Not semantics.
Over time, atomic Css is easier to change, easier to discover, and easier to maintain. Well, in my experience anyway.
Thanks for the shoutout! I thoroughly agree that there is a modular future for CSS. Very excited to be working on this stuff.
I can’t help thinking the industry is wide of the mark, creating innovative approaches without understanding what the real issues are.
It doesn’t matter what CSS method is used, the CSS will grow and eventually become unmanageable if the approach to the design and growth is spontaneous, which, let’s be honest, is often the case.
The problem is that spontaneous design is badly communicated, for example, because there exists no reference manual.
This is particularly problematic for large projects. Suppose there are 1 or 2 designers, usually answerable to too many stakeholders. Often, other people produce the CSS – it’s a technical job, and inevitably there are areas where the design is vague, and clarification is not available.
Questions like “what if the data we show here wraps a lot of lines?” are often late or overlooked, and seed future spontaneity.
CSS authors, in turn, fail to communicate with the HTML authors, who need to understand precisely what HTML is required to meet the design.
It’s even worse if CSS authors assume HTML authors just need unstructured generic rulesets and will be able to piece together whatever they need by figuring it all out for themselves.
Give an undocumented CSS to multiple teams and each will produce similar but distinct HTML structures and by coincidence the CSS will style all efforts desirably, today – but future style changes will expose the fact that those structures differ.
A designer requesting a minor tweak to a page may result in the HTML author meeting the requirement by finding a rule set that is ‘good enough’ but was ultimately intended for another use. A future maintenance bug.
Equally, the CSS author will sporadically create new same-but-different rule sets, in reaction to defects like when component A contains widget B the alignment is a little off. This will result in the HTML author discovering multiple viable rule sets and not appreciating which is the most appropriate to use.
What’s usually missing, is not a CSS method, but the communication, some form of reference for the HTML author, e.g. a comprehensive style guide or pattern library, for the site.
I have a hunch that the positive feedback many innovative CSS methods receive is mistakenly attributed. The credit actually belongs to the process of the rewrite that was necessary to adopt the new method. The old CSS needed the restructuring more than it needed the new method, but the new method receives the glory.
It’s a fresh start, so of course we’re happy with the new version it meets the requirements of the site today, the same as when we were happy with the previous version that met the requirements as they were back then. But whilst we’re at it, please let’s create some documentation.
Don’t miss out, the documentation, if done right, will also serve as a comprehensive test suite. All the CSS rule sets can be demonstrated, tested in supported browsers, tested for accessibility, design conformance, all in one place.
If we have multiple development teams consuming our CSS, we need this, we do not want to learn how to navigate unfamiliar or difficult to reach pages (e.g. data setup, access rights) before we can even start troubleshooting a layout issue, that’s time-consuming.
Thanks.
I agree with you about having documentation, our paths to documentation may be different though.
The design of any UI MUST support the capacity to be spontaneous. Users can’t tell you how they feel about something from a mockup or even a demo. It is only once they actually use the thing, they get a feel for if they like it or not. Managers just go off what they think looks cool, and developers just have to guess until they get the feedback.
How many times have you come out of a feedback session to be told there are a bunch of UI/layout changes… do we want to have the design team go update the style guide before the developers can start implementing the concepts?
How about having a designer and a developer sit together, updating the UI, instead of living in functional silos? How amazing would it be for a developer to have the freedom to change ay part of the CSS/HTML, add whatever they liked, alter the structure and the styles, knowing, they were not causing any side effects?
So.. lets have a way of rapidly iterating, without the need for a swathe of classes and structures, then, when there is a general consensus about a particular component from the end users, lets wrap it up there and put it in some documentation and style guide for future reference.
I completely agree that documentation is worthwhile, but not before you figure out what works.
When I say large projects, I mean multinational corporations, or governments, that commonly have dozens to hundreds of services following the same corporate theme and guidelines.
In these organisations, there are not enough CSS authors to sit with every HTML author as they work, and most of the HTML authoring is distributed globally, even outsourced to other companies.
HTML authors have a range of skills and roles from application developer to WYSIWYG content author. It would not be amazing for HTML authors to make CSS edits, at all, even if they did have write-access to it, that’s chaos.
The ability to make such edits without side-effects is exactly the same chaos in the opposite direction. It may be trivial to create content that meets today’s corporate theme and accessibility requirements, but when the theme changes (e.g. company merger or other re-branding exercise, browser compatibility defect, accessibility defect), any service that deviated, overlaid or forked the CSS will require serious attention. Simple changes can accrue massive financial overheads.
I agree that you need to figure out what works before you communicate what to do and how to do it to your entire HTML author base. Hopefully the most experienced resources create and maintain the exemplary documentation, and the amount of prototyping and live-proving can be limited to a manageable amount.
The documentation is indeed iterative and never set in stone, a project team should be fully aware of the mechanism for reporting when they expect to encounter uncharted territory so they can get what they need in good time. Their service can be a ‘beta release’ for such new components to gain confidence before releasing for wider usage.
Most projects though, in these organisations, are not doing anything ground-breaking and just need to know exactly what to do. Often when such projects flag that they need something new, they have overlooked or ignored an existing pattern, especially when they are driving the design from a legacy system they are rewriting.
I understand designs are often imperfect and make it into production before it is fully appreciated. However, I don’t know if this justifies being able to respond spontaneously.
The stakeholders of the corporate theme would certainly be interested to understand the limitations of their designs so they can update their components and the guidance, and communicate the lessons learnt back out to the wider audience. It definitely should be iterative.
Yes, in that specific case, you might be right.
Although, I work in distributed teams, and it’s possible to get people together. I don’t feel the multinational factor has any effect here, more so what you are describing is functional silos with a reporting mechanism for requesting changes. In that case, everything will be slow and hard. Not just CSS authoring.
Despite this scenario, you made a statement about the industry in general creating solutions without understanding the problem. So of course, this way of authoring CSS may not work all the time, for all projects, and all teams… what a solution does? This does not mean the industry is off the mark creating it.
Although I do feel the large multinational organisations would benefit from this approach, even more so than others.
Yes, I already said it’s the documentation that’s missing, most of the time, regardless of CSS method, the HTML authors need to understand exactly what HTML to produce to conform to the design.
The CSS authoring is only slow during early iterations, where everything is new. Understandably, since a corporate theme is being created for countless HTML authors to follow, every penny invested getting this set up and communicated effectively, will be well spent.
Public or enterprise code repositories such as GitHub already have the tools to facilitate the feedback, reporting, and we can even invite pull requests should there be a HTML author with sufficient CSS authoring experience to do so.
I would expect a serious organisation capable of development at scale to have a handful of CSS authors, and an unlimited pool of HTML authors (especially over time, corporate themes have longevity, usually).
Therefore, I don’t think it’s productive to make the HTML authors write overly arduous HTML, just because it makes the CSS author’s life easy. Many HTML authors preference is to write mark-down with sparing use of HTML elements. CSS authors need to understand that it IS a bad idea to give all nested list item elements BEM-style class names, and force HTML authors to write unnecessary HTML.
Many CSS methods solve the CSS author’s headaches by over-complicating the HTML in this way. CSS fundamentals are designed-out; avoid specificity, avoid the cascade/nesting, avoid global scope – as if that’s even a real thing. They all boil down to ‘avoid collisions’.
Blaming specificity, the cascade, nesting, or global scope for collisions is making scapegoats instead of recognising that collisions happen when the CSS is not well understood, lacks proper documentation, is spontaneously edited without forethought, and the designer hasn’t taken the time to consider the most sensible, semantically-rich HTML structure for a component before deciding to style it.
Many CSS methods, discourage the fundamentals of CSS so much, that they are not CSS at all, they’re CSS-avoidance schemes.
For example, BEM, and Atomic CSS, litter the HTML with inevitably unpredictable class names (naming things well, is hard).
What’s particularly annoying is it’s more appropriate to select elements according to necessary HTML structure. For example, If the CSS selects an element according to an aria attribute value, HTML authors will only see correctly styled elements when they write accessible HTML. If the CSS author decides only to select elements by class name, the HTML author may get away with producing sub-standard HTML.
I’ve read a lot of people defending they create many small css files, on some cases one per html file.
This might work with certain cms or frameworks, or php, where the server only supplies the necessary styling. But if you are talking about standard html with css and js, has a downside. Although the files are very small, having to get a lot of files may take longer to download than one bigger file: for every file there is a get (a) command which needs to travel to server and back.
This is specially important with mobile connections where the latency is a lot higher compared to cable/dsl/fiber connections.
(a) I might be a bit unsure on most recent improvements and current standards get several files per get request.
just my two cents
It seems, anytime us devs have an issue we’re pointed to some framework. I agree that frameworks can be invaluable, but it really depends on the circumstance.
If you’re very controlling about your code, like me:
Frameworks have 3 problems:
Not only do you have to go searching for the name of the style in the documentation, you’re left with class names like .helvetica you have to use all over your HTML wherever you want that font, instead of just writing in your CSS, for example:
More importantly, instead of a framework, I think devs need to come together and share a process for writing and maintaining CSS code.
Over the years, I’ve discovered things by accident I wish I did years ago and now I can write code that is more maintainable than last year’s.
My go to philosophy before coding is: “How do I write the least amount of code for this application?” so that it is fast and maintainable.
like now:
I always write mobile first and place only the tweaks to the class needed for tablet and desktop in a media query in its own section. For example:
…later down the page…
This way if I make a change I don’t affect the class in every breakpoint on all devices. I know code at the top will always be mobile and across the board.
I also keep properties used often throughout the site in their own section and simply continue to append class names that need that property instead of repeating that property all over the place in every class, Such as (for example):
I’d love if we shared things like this all with each other.
Frameworks are good and I think they’re ok for supplementing but not for core CSS if you’re really designing websites and applications for production.
I’m sure there are so many devs out there who have brilliant ways of doing things. We just need a way to share our process with each other.
You are totally onto something here. Have you seen functional CSS? It is not a framework, rather a conceptual model for the process of writing CSS. More of a paradigm, rather than a framework. It has some similarities to what you are currently doing. There are some frameworks though which are constructed using the functional CSS style.
In twenty years, the only thing writing code on the web will be A.I. We (humans) won’t even be able to understand it. We’ll simply tell the A.I. what we want, and it will do the rest.