As front-end developers, we’ve wished for a lot of things over the years — ways to center things in CSS, encapsulate styles, set an element’s aspect ratio, get finer-grained control over our colors, select an element based on its children’s properties, manage layers of specificity, allow elements to respond to the width of their parents… the list goes on and on.
And now that we got all we wished for and more, some of us are asking — do we now have too much CSS?
The dark times
If you, like me, came up in web development during CSS’s infancy, the idea of having too much of it seems ludicrous.
Back in the days, virtually the entire job description of a front-end developer consisted of dealing with CSS’s limitations. The clearfix hack to clear floats, the 100% padding hack to make square divs, not to mention semi-randomly applying unrelated properties to trick Internet Explorer into doing your bidding.
At the time, the browser was a devious foe to be defeated through sheer cunning and arcane incantations. Today, the perfect property is waiting and just a copy-paste away on MDN.
The new era of CSS
But today things are vastly different: not only are things moving much faster, but browser vendors actually care about making developers happy! I know, I couldn’t believe it either. But I run the yearly State of CSS developer survey (which is open now by the way — go take it!) and I know for a fact that browser development teams use the survey results (among many other data points) to inform their roadmap.
Beyond this, Google has also helped finance my work on the survey, and even hired Lea Verou to take the lead on selecting this year’s survey questions.
It’s not just Google. It’s become fashionable to bash Safari and Apple in general (sometimes deservedly so), but you can’t deny how passionate someone like Jen Simmons is about listening to developers and improving the web.
And not only are browser vendors improving CSS on their own; they’re even collaborating across battle lines with initiatives such as Interop 2023 to help reduce inconsistencies and incompatibilities between browsers.
Too much of a good thing?
The result of all this is that we are now faced with an embarrassment of CSS riches, and it can be hard to catch up. CSS Grid started being supported in major browsers almost five years ago, yet I still check a reference every time I use it. And as cool as subgrid seems, I’ve yet to even try it out.
During the process of selecting which CSS features to include or not in the State of CSS, Lea and myself considered many features, but we also rejected quite a few. Some examples of the feature we didn’t include are:
- The
linear()easing function, which lets you define easing curves with more granularity. - The
env()function, which lets you use variables defined by the browser or device. - The
scrollbar-widthproperty, which helps control a scrollbar’s appearance. - The
margin-trimproperty, which lets you control how a container’s children’s margins behave.
These are all potentially very useful, and would’ve all been big news during the CSS drought of past years. But in today’s context they have to fight for attention with much larger announcements, like the has() selector or CSS nesting!
Not excited
As Silvestar Bistrović writes, he is “not that excited about all these new CSS features.” This found an echo on Twitter, with Sara Soueidan stating that what she cares about is “practicality, not how shiny a feature looks at the moment.”
This may seem like a negative attitude, but I think it’s understandable. Nobody can be expected to keep up with so many new features!
Another unintended (or maybe, intended?) consequence is that the more complex CSS becomes, the more it raises the bar for any new company wanting to develop a browser engine — to say nothing of the added workload when it comes to maintaining and documenting all these new features.
CSS overreach
There’s also the very valid concern that CSS might be branching out into areas it’s not quite suitable to handle. That’s another thing Sara Soueidan pointed out when reacting to the new CSS Toggles experimental implementation (here’s a ticket discussing it):
Many have made the very reasonable point that this kind of behavior would be best handled by a new HTML element instead of managing toggle state purely through CSS, and that CSS may not be the best medium to ensure accessibility issues are properly addressed.
When CSS takes over something that was previously handled through JavaScript, this is generally seen as a good thing, as it often reduces the amount of code the browser has to load. So, I’m cautiously optimistic about CSS Toggles and trust that the CSS Working Group will properly address the concerns of the community. But there may yet come a day when we start to worry that CSS may be expanding beyond its borders and encroaching on HTML and JavaScript’s responsibilities.
New expectations
And maybe this is what needs to change: maybe we should drop the expectation that CSS developers have to know all of CSS?
This expectation stems from the days where CSS was an afterthought, that little annoying syntax you had to learn to make your button blue and bold just like the client asked. But I think we need to accept that today’s CSS might just be way too vast for a single person to master, especially in addition to other front-end duties.
As Michelle Barker puts it:
And that’s where I, myself, land in the end. I’ve made my peace with the fact that I will probably never use — or even know about — all possible CSS features. And this is coming from someone who runs a survey about CSS!
But these new features will surely be useful to someone. Someone will write blog posts about them, create cool CodePens with them, give talks about them. That person will be a cool, young, energetic developer who still have all their hair. In other words, it won’t be me — and that’s fine.
And maybe you’re worried that this new developer will be overwhelmed by all the stuff they have to learn at once. But do keep in mind all the things they won’t have to learn about, precisely because it’s been replaced by these newer alternatives. I know I’d take that deal anytime.
But think about it: in the past couple years, not only have we seen a huge increase in the number of devices we need to cater to, we’ve also started to recognize that we all consume the web in slightly different manners, whether due to disabilities, current context, or just personal preferences. Shouldn’t CSS adapt to this new reality?
Now, I have to confess this has all made me feel a bit nostalgic… so excuse me while I go clear a couple floats, just for old time’s sake.
As I mentioned, the yearly State of CSS survey is now open. Whether you think there’s too much CSS or not, the survey is a great way to let browser developers know how you feel, so go fill it out if you have 10 minutes.
Perhaps there needs to be a re-evaluation phase in the future: a time to step back and say “what features can we add that will replace three others while making the mental model simpler?” Or, “which features can be removed because there are already better ways to achieve every possible usage of the old way?”
I wonder if Houdini and the systems of adding actual logical programming to define layout and styles will go a long way to removing the need to have so many specific declarative properties in CSS.
Thanks for the article, I thought the same thing – the vision of controlling the smallest details of a site’s appearance and behavior is exciting – but it’s getting to be too much – it used to be possible to remember the names and predict how almost all the properties would work :)
Was there ever an expectation that a developer should have the entire CSS spec in their head?
The people that care about a11y are proactive in adding features that make a11y easier to implement.
The people that request the web to freeze in place for the sake of a11y are just stagnating.
I’m one of the new developers you’re talking about (c. 1 year self-taught) and here to testify that vanilla CSS is pretty easy to learn from scratch and doesn’t feel overwhelming at all. I know everything I use regularly (including grid/flex) and look up the rest on MDN or on here as it comes in handy; so not all that different really from using a large-scale API, except CSS has very good documentation ;-)
If I ran a browser I would certainly be focusing on devex. The more web apps there are as opposed to native ones, the more power and intel the browsers can gather. (I guess we’re in trouble if they start injecting ads…)
I would rather have 100 new features that people didn’t necessarily get excited about than just a couple which people were excited for.
So long as those 100 made making websites look and behave how I want them to a lot easier. It should be about practicality not excitement.
Consider that there are more than a million words in the English language, of which about 170,000 words are in current use, and 20,000-30,000 words are used by each individual person.
Do we stop adding new words that are relevant today, or throw out the 830,000 words that are not currently in use?
I would suggest this is similar to your query about there being too much CSS.
Natural languages are not declarative languages. CSS risks becoming C++, you can do 1 thing in 10 ways which is bad and in an ecosystem of frameworks and libraries further splits the community. On natural languages, the world too is split up by language too many ways to say bread.l
Not really. The amazing thing about all the extra CSS features (and hell, those in JavaScript too) is that they increase the number of things you’re able to make, giving you far more possibilities for interesting sites and apps.
So while I might not use certain features now, others might well find interesting uses for them in future. And probably create all kinds of stuff I’d never have imagined as a result.
I’ve been a web developer back when we had to use 9 images and a table for getting a box with rounded corners and a background texture. Yes, a lot of the newer features are incredibly useful!
An I really got the feeling, that the W3C, WHATWEG and browser vendors are much more focused on designing and implementing features that people actually need in order to do their daily job. Using floats for a multi-column-layout was fine back then, but using flexbox and grid just feels so much nicer than having to understand what a clearfix is.
Nowadays, we need way less strange hacks to accomplish what we need, which should make code easier to read. But now, that we got so many great features at hand, the fine-grained control over every aspect of a design often results in things 100 lines of CSS for a button and many levels of abstraction with custom properties.
On top of that, there are many properties of questionable use like
will-change,containorcontain-intrinsic-size. Of course, these are a welcome addition for complex apps, but many devs are feeling the pressure of using these in rather simple projects as well, adding unnecessary complexity with little gains.For me, there’s too much CSS to learn all of it in detail now, but on the other hand: maybe it is also not needed any longer to learn all of it.
W3C currently shows 559 distinct property names so apparently 11 properties have been added since october 5th!
For me, CSS has turned from easy and useful to frustrating. I don’t do CSS development all day, it’s just one of the technologies I sometimes have to use. At this point it seems no longer a language for humans.
There should be way better visual editors to develop screen (reader) elements, their definition, layout, transitions etc., and produce the actual CSS that will go into production. Get rid of the separation between design and develop, we’re all in the same team.
CSS features are here to give as much flexibility as possible to design exactly what designer imagine. It’s great how it’s developing.
If someone feels CSS has too much features it means it’s not for them.
Maybe jobs will divide again into more specialized.
so people are complaining about too much css, but isn’t bothered that a new js framework keeps popping out every day?
Is there any mechanism by which to deprecate or remove obsolete CSS features? Surely they can’t all be the current expected way to approach the problem of layout and styling.
We’ve had to move to “evergreen” browsers for HTML updates. Might as well take advantage of that to simplify CSS.
Even if it’ll be years until we can actually clean up the spec with a CSS 3000, and we can only mark features as “legacy” support, being able to define a reasonable, modern, usable subset would be a great step forward.
While I partially agree (tab carousels and such are a bit too generalized), I disagree with your statement that CSS has become “too complex.”
CSS is the primary means by which programmers style websites. Because of the sheer diversity of ways in which people might want to style elements, the diversity of CSS features is arguably necessary.
I like how CSS manages complexity: dividing properties (roughly) into two classes. On the one hand, you have “Common CSS” (a term I’m making up). This is the manageably small set of features which everybody uses every day, such as
marginandfont-size. Nowadays, you could also includeborder-radiusandbox-shadowdue to their prevalence in modern aesthetic styles. On the other hand, you also have “Advanced CSS”, a huge set of specialized features which are rarely used but are nevertheless extremely valuable whenever you need to do whatever it is they handle (a good example is thelinear()easing function you mentioned). You do not need to know Advanced CSS by heart in order to write good CSS; it is sufficient to know Common CSS and be able to search the MDN docs for Advanced CSS features.more knowledge we have about CSS its hard to catchup
@Moaz, you are correct not only is CSS becoming more advanced but an overwhelming amount of CSS is included in many websites. After some research, you can see that CSS tends to drift during development, and styles and properties become useless and abandoned. I did find an article that was kinda interesting on removing dead code: https://appcode.app/how-to-remove-unused-css/
You are right, there should be some development in making CSS easier to work with.
I was a specialized HTML / CSS developer for a long time. I was specifically hired by bunches of companies for my skills of translating .PSD files into HTML, even pre-CSS. Then there were the dark days of CSS hacks for supported browsers (&*^%$ IE6,7,8,9). Fast forward and companies no longer want specialists, they want full stack experts at everything including being a DBA. It is amusing to watch Junior Engineers using the latest and greatest css that’s supported only by Chrome or Edge and get frustrated when it doesn’t work for Firefox or Safari or any 12000 flavors of Mobile Chrome.
I appreciate all the spiffy new CSS but holy hell the learning curve can be quite steep. But very often less sexy techniques work just fine with no muss or fuss.