From Clearfix Hacks to Feature Fatigue

For developers who started in the early days of CSS, the current conversation about having “too much CSS” would have sounded absurd. The original web development experience was defined by workarounds: the clearfix hack to clear floats, the 100% padding trick for square elements, and randomly applying unrelated properties to coax Internet Explorer into cooperating. The browser was an adversary to be defeated with cleverness and obscure incantations, not a platform delivering well-designed features on demand.

A Decade of Rapid Change

That dynamic has shifted dramatically. Browser vendors are now actively seeking developer input, with teams using surveys like the annual State of CSS to inform their roadmaps. Google has even funded survey work and brought on Lea Verou to shape the questions. Safari and Apple face their share of criticism, but proponents point to individuals like Jen Simmons as evidence of genuine interest in developer feedback. Cross-browser collaboration has also improved through initiatives like Interop 2023, which targets inconsistencies between engines.

The result is a steady stream of new capabilities. CSS Grid has been supported in major browsers for about half a decade, yet many developers still reach for a reference guide when using it. Subgrid remains unexplored territory for plenty of working front-end engineers.

Signal Versus Noise in the Feature Pipeline

This abundance creates a real selection problem. In curating features for the State of CSS survey, Lea Verou and the author considered and rejected several potentially valuable additions, including:

  • The linear() easing function for more granular animation curves
  • The env() function for accessing browser- or device-defined variables
  • The scrollbar-width property for controlling scrollbar appearance
  • The margin-trim property for managing container children’s margins

Each of these would have been headline news during CSS’s leaner years. Now they compete for attention against larger announcements like the :has() selector and native CSS nesting.

It just seems that talking about The New Hot Thing™️ is always a good way to get views and gain popularity. What I care more about is practicality, not how shiny a feature looks at the moment.

— Sara Soueidan (@SaraSoueidan) October 8, 2022

That reaction is understandable, arguably even healthy. No developer can reasonably be expected to track every new property and function. There’s also a practical cost beyond individual knowledge: the more complex CSS becomes, the more difficult it is for new browser engines to enter the market, and the greater the burden of maintenance and documentation for existing ones.

Borders Getting Blurry

There is also a growing concern that CSS is expanding into territory better handled elsewhere. When Sara Soueidan reacted to the experimental CSS Toggles implementation (discussed in the CSS Working Group’s issue tracker), she echoed a sentiment shared by others:

I haven't read the spec yet so I may be missing something, but reading this tweet I'm already pessimistic about what this means to a11y. Tabs, carousels, etc. have different semantics & keyboard behavior. To suggest you can create them all using one CSS-only toggle is concerning. https://t.co/QOqA9uzZGC

— Sara Soueidan (@SaraSoueidan) October 18, 2022

Critics argue that managing toggle state through CSS alone may not be the right vehicle, and that accessibility concerns could be better addressed by introducing a new HTML element rather than handling such behavior purely in stylesheets.

Historically, when CSS has absorbed responsibilities formerly handled by JavaScript, it has generally been a win, reducing the amount of code browsers must load. There is cautious optimism that the CSS Working Group will address community concerns around toggles. But the episode raises a legitimate question about whether CSS might eventually overreach into areas that HTML and JavaScript are better suited to handle.

Rethinking the “Know Everything” Expectation

The more immediate issue may be expectations rather than the language itself. The assumption that a CSS developer should know all of CSS dates back to when CSS was a minor part of the job — that “little annoying syntax” needed to make a button blue and bold. Today’s CSS is another matter entirely.

https://twitter.com/housecor/status/1577668059652931586

In practice, specialization is already happening, as Michelle Barker notes:

Many “niche” features you only need to learn if you have a specific use case. I think it’s a good thing we have more features. Just like any other programming language, new developers don’t need to learn them all at once

— Michelle Barker (@MicheBarks) September 26, 2022

Accepting that mastery of every feature is unrealistic may actually be the point. New features will find their audience: someone will write blog posts, build demos, and give talks about them. Developers entering the field now may face a larger body of CSS to learn, but they also benefit from all the obsolete hacks and outdated properties that have been replaced by cleaner alternatives.

Meanwhile, the underlying environment keeps diversifying. The number of device types continues to grow, and there is broader recognition that people consume the web in different ways — due to disabilities, context, or simple preference. If CSS is meant to serve that reality, a certain amount of expansion may be unavoidable.