Why a Version Number Keeps Coming Up

For anyone who learned CSS in the era of CSS1 and CSS2, the absence of a CSS4 can feel like a missing milestone. The web platform moved from monolithic specifications to a modular system years ago, yet the mental model of numbered releases persists. Recent discussion in the CSS Working Group, sparked by an issue from Jen Simmons, has reopened the question of whether defining a formal "next version" of CSS would help developers, educators, and browsers alike.

The term CSS4 is used here as a placeholder for whatever such a versioned release might be called, since the naming itself is secondary to whether the approach makes sense at all.

How CSS Got Modular

CSS1 and CSS2 were written as single, monolithic specifications that contained every property and value. That worked when the language was small. But when work on CSS3 began, the Working Group split the specification into modules, each covering a distinct area of the language. Some parts of CSS2.1 were left untouched and remain defined there to this day, which is why modern modules still reference the CSS2 specification.

The split also changed how new features were numbered. Modules that evolved from CSS2 concepts, like Selectors, became Level 3 modules. Entirely new specifications, like CSS Grid Layout, started at Level 1. As some modules have progressed to Level 4 or Level 5, calling everything "CSS3" no longer maps to reality.

In addition to level numbers, each specification passes through W3C maturity stages on its way to becoming a Recommendation. Many features developers use daily are defined in specifications that haven't reached that final stage, which is why the Current Work page on the CSS WG site shows a wide range of statuses.

The Communication Problem

Much of the confusion around CSS versions stems from the fact that there is no single document that represents "the current state of CSS." People familiar with the process have written articles and created videos to explain how levels and maturity stages work, including pieces by Tab Atkins-Bittner, Rachel Andrew, and the Layout Land video series. But for the average developer, the internal workings of the W3C process matter far less than what actually works in browsers today.

Despite these explanations, the request for a version number keeps resurfacing. There are practical reasons for that persistence.

What a Version Could Offer

From an educational standpoint, a defined CSS version would be useful for both authors and learners. Publishers of books and courses could tie their materials to a specific feature set, giving buyers a clearer sense of whether their content is current. Proponents argue that a version boundary would also give developers a finite, approachable set of features to learn, rather than an endless stream of new specifications. As Jen Simmons noted in the issue, drawing a line around a set of finished features could help overwhelmed developers feel that catching up is achievable.

A versioned release would also restore the possibility of a test like the Acid Test series. Acid 1 and Acid 2 were tied to CSS1 and CSS2.1 respectively, giving browsers a clear benchmark for standards support. The Acid 3 test drifted from that model by covering a mix of features rather than a defined specification level. A formal CSS4 definition would give user agents a concrete feature set to declare support for, and would give developers a concrete threshold to reference.

Some commenters on the WG issue see a version number as a business tool as well. In pitch meetings, telling stakeholders that a site can't support a legacy browser because it lacks CSS Variables and Grid Layout is a hard sell. Framing the same situation as "the site won't support CSS4" could make the trade-off more compelling, especially when the browser in question is obsolete and insecure.

"[...] perhaps CSS4 could help to push their mindset towards a more secure and better web. During pitch meeting, it's hard to tell them we can't support IE10 because we want CSS Variables and Grid Layout. Stakeholders do not know and do not care. They just want to support as many browsers as they could (very typical FOMO mindset) and they have the dollars to throw.

However, if we could tell them we can't support IE10 because it doesn't have the latest CSS4 technology and throw them the "Are you sure you want your newly created website to be behind your competitors because of that?" question, that might ponder them (of course, on top of the fact that IE10 is completely obsolete and vulnerable)."

The question for the Working Group is whether drawing that line around a specific set of features is worth the effort, and whether it would actually provide the clarity that developers, authors, and stakeholders are looking for. The thread on the issue is open for public comment, and input from outside the Working Group is welcome.

Why Versioning CSS Falls Apart

Grouping "production-ready" CSS into a single version is not as simple as picking a list of finished specifications. Many specs are only partially implemented: some properties enjoy broad support while others lag for years, and features that developers treat as stable often sit inside Working Drafts next to items still being debated by the Working Group.

Multiple-column Layout is a good example. Most of its properties have been in browsers for a long time, but column-span only recently landed in Firefox, and column-fill has had details clarified only recently. Looking at individual properties instead of whole specs doesn't solve the problem either, because implementations differ by context. The Box Alignment properties are defined for every layout method where they make sense, but current support covers only Grid and Flexbox. So justify-self, defined for block-level boxes, absolutely-positioned boxes, and grid items, is stable in a Grid context but not in a block layout context.

Similar gaps exist in Box Sizing: the intrinsic sizing value fit-content() is supported for Grid track sizing but not as a width value, and no browser other than Firefox implements the intrinsic sizing keywords for flex-basis. Multicol adds another layer of difficulty — many of its perceived problems stem not from the properties themselves but from poor fragmentation support across browsers, which makes the feature seem broken even when the spec is implemented well. Untangling all these dependencies to assemble a coherent feature set is a genuinely hard job.

CSS Isn't Only for Browsers

CSS is also consumed by user agents that turn HTML into print-ready PDFs. These tools typically have strong support for Paged Media and fragmentation but lag browsers on newer CSS like Grid Layout. Any definition of "CSS4" needs to account for whether such user agents are part of the target audience.

Expectation vs. Reality

Some participants in the discussion expect a CSS4 release to include features that don't actually exist in CSS yet. As Joshua Lindquist notes in his roundup of comments, the approach may be easy for developers who don't track the latest developments — everything would feel new to them, even Grid and Flexbox, which have been in browsers for years. But for those who stay current, a "new" specification full of old features would only cause confusion.

Who Decides What Ships?

Someone would need to define what belongs in CSS4, and that decision is far from automatic. The CSS Working Group has maturity levels: a spec can progress from Candidate Recommendation to Recommendation once each feature has two implementations. But as shown above, specs often reach that point unevenly. If CSS4 were restricted to specifications at Recommendation status, it would include only:

  • CSS Color Level 3
  • CSS Namespaces
  • Selectors Level 3
  • CSS Level 2 Revision 1
  • Media Queries
  • CSS Style Attributes
  • CSS Fonts Level 3
  • CSS Writing Modes Level 3
  • CSS Basic User Interface Level 3
  • CSS Containment Level 1

Notably absent: Grid, Flexbox, Box Alignment, and many other specs developers rely on daily.

Defining a version separate from the existing W3C process would require a group with the time and authority to make these calls — not just for CSS4, but as part of a framework for future versions. Otherwise the same debate recurs in a couple of years over CSS5. The CSS Working Group seems an unlikely venue: it's already stretched thin developing new CSS, and adding this layer of abstraction on top of the spec process would complicate decisions further. Specs occasionally mark parts as "at-risk" when their inclusion might block progress to Recommendation — that's why subgrid was pushed to Level 2 of Grid. An additional versioning concern could only add more friction.

The Real Problem: Usability, Not Versions

Browser support keeps surfacing as the central criterion for what CSS4 should contain. That suggests the underlying issue is less about versioning CSS and more about developers needing clarity on which set of features is safe to use in production.

"One of the advantages of a CSS4 approach is that it signals two things. First, that there's a significant bundle of new CSS features that have been developed after CSS3 and which are ready for use and second, that they are ready for use. Not experimental or implemented by Chrome but no one else, but ready for broad adoption." — Rick Gregory

If browser support is the real concern, maybe the definition belongs somewhere like MDN, which all browser vendors already contribute to and which tracks implementation data that exposes partial support like Box Alignment's. MDN documents the web platform specifically, so it could sidestep the question of print or other non-browser implementations entirely.

Still, it's unclear that a CSS4 label would change perceptions outside a niche community, or help developers convince bosses and clients to upgrade browsers. When organizations ignore Microsoft's own upgrade guidance, the promise of CSS4 support is unlikely to move them. Even in the days when CSS did have numbered versions, browser upgrades were still slow. But a well-defined chunk of usable functionality could make discussions less abstract — if it were based on what works in practice rather than on specification status, and defined outside the CSS Working Group process.

"However, I must agree with several others that major marketing versions only have meaning in a compatibility situation. If we announce that CSS5 is finally here, it must mean all major browsers have full or near-full support. Without this compatibility condition met, I think some developers will be cynical, and return to feature or module based thinking, the current status quo." — Ferdy Christant

The debate is worth having beyond the CSS Working Group's GitHub issue. Developers can weigh in on the original thread or join the new Community Group to discuss the topic. What remains open is whether any version label actually helps — or whether checking support per feature on Can I Use or MDN remains the more practical path.