Csswg-drafts: Let’s Define CSS 4

[jensimmons]

It’s come up quite a few times recently that the world of people who make websites would greatly benefit from the CSS Working Group officially defining ”CSS 4”, and later “CSS 5“, etc.

Chris Coyier wrote:

CSS3, and perhaps to a larger degree, "HTML5", became (almost) household names. It was so successful, it's leaving us wanting to pull that lever again. It was successful on a ton of levels:
• It pushed browser technology forward, particularly on technologies that had been stale for too long.
• It got site owners to think, "hey maybe it's a good time to update our website."
• It got educators to think, "hey maybe it's a good time to update our curriculums."
• It was good for the web overall, good for websites taking advantage of it

Nicole Sullivan wrote:

Unpopular opinion: CSS and HTML need to increment their version numbers again so we can convince business to invest in these technologies. 😂
and
Marketing isn't a dirty word, really! In fact I advocated incrementing version numbers for that very reason

PPK wrote:

I think that CSS would be greatly helped if we solemnly state that “CSS4 is here!” In this post I’ll try to convince you of my viewpoint.

I am proposing that we web developers, supported by the W3C CSS WG, start saying “CSS4 is here!” and excitedly chatter about how it will hit the market any moment now and transform the practice of CSS.

Of course “CSS4” has no technical meaning whatsoever. All current CSS specifications have their own specific versions ranging from 1 to 4, but CSS as a whole does not have a version, and it doesn’t need one, either.

Regardless of what we say or do, CSS 4 will not hit the market and will not transform anything. It also does not describe any technical reality.

Then why do it? For the marketing effect.

We do seem to agree that this is purely about “the marketing effect.” And for some, that’s a dismissive admission. They see that marketing is not core to defining or implementing technology. Some folks the CSSWG have argued this would take up a lot of time to figure out, and add little value to CSS itself.

On the other hand, if web developers are hesitant to adopt new technology, defining and implementing it is wasted time. How Authors perceive change, and judge when is the best moment to invest time to learn new technology — this has a huge impact on adoption.

”CSS3” was perceived as a singular thing, even if it was not. As Chris Coyier writes, a tremendous number of books, courses, and conferences were dedicated to CSS3. The perceived label gave rise to business opportunities, and those business opportunities drove education. Education centered around a single concept — ”CSS has changed. There’s a new, important, finite, known set of things to learn. Now is the time to learn it. Here’s a resource.”

I see a lot of resistance to learning the CSS that came after CSS3. People are tired and overwhelmed. They feel like they’ll never learn it all, never catch up, so why try, or why try now? If the CSSWG can draw a line around the never-ending pile of new, and say ”Here, this. This part is ready. This part is done. This part is what you should take the time to learn. You can do this. It’s not infinite.” I believe that will help tremendously.

Defining CSS4 purely for ”marketing”, to make the recently-shipped parts of CSS more approachable is definitely a different kind of thing than what the CSS Working Group has done before. It’s outside the culture of the group. It’ll require us to think a bit differently about what ”official” means, or why something is in or out of the list. This will be more subjective, more squishy. But I believe the past shows us that this is something Authors need. CSS2, CSS3, HTML2, HTML3, HTML4, XHTML, HTML5 — these were things people grabbed onto. Just saying ”oh, there are no new versions anymore, it's just ongoing... the Living Standard, the Just Keep Up method...” — this isn't really working.

I do not believe this is a project for anyone but the CSS Working Group. We are the only body with the power to say “This is CSS4. It’s official.”

I believe this work should start with a conversation with Authors. It’s not something implementors or spec writers should lead. It’s work that starts with a community conversation:
• Would it help to officially define CSS4, and what’s in progress for CSS5?
• What goes into those two buckets?

I’m opening this issue so we can hear from web developers and designers their thoughts about this. We would be doing this for them, and not for browser engineers or the CSSWG process itself.

[chriscoyier]

Amelia Bellamy-Royds pointed me to the idea of these "snapshots" that you already do. That seems like a great idea to me, and a stepping stone to the marking panache that will get people caring and fight against what Jen rightfully called the exhausting "Just Keep Up" method of learning.

I like that [snapshots] isn’t some brand new concept that you somehow have to get the whole community behind, it’s something that’s already being done. Just needs a little marketing crack behind it. If it were me, I’d hire a content strategist and a designer, and get them going on a microsite or landing page that delivers with crystal clarity what “CSS2019” is. I could get behind that. The snapshot landing page as-is is too dry.

[stubbornella]

In the constant stream of things we need to learn, it's nice to be able to tick the checkbox and say "yes, I have learned CSS4". I think it would drive developers to upgrade their skills, businesses to upgrade their tech stacks, and browsers to focus on cross browser compat. All good things for the web imo.

[jensimmons]

re: Chris' comment above:

I believe the Snapshots and this should be two different things. The Snapshots are heavily dependent on the CSSWG process, and where exactly in the process a spec might be. It's official legally, etc etc... there are many considerations for what's included in or excluded from the Snapshot.

If we define CSS4, separate from Snapshots, we could focus on making a list that's designed for Authors. What is the word from the CSSWG about what is ready to use on websites?

[davatron5000]

+1 to this.

I wrote about "perceived velocity through version numbers" awhile back and came to the same conclusion that versioning would be helpful. It's indicative to me that CSS, despite huge advances like Grid, is generally perceived as stale and has been since it was announced there would be no CSS4 in 2013.

Meanwhile, JavaScript has seen a huge explosion in velocity and has published the following standards since 2015: ES6, ES2015, ES2016, ES2017, ES2018, ES.Next, ES7, ES8, and ES9.

It's a major bit of correlation, but I think it would be very helpful to have some sort of reference point snapshop or collection of features.

[tallys]

I am in favor of anything that makes the work visible and valued. Defining CSS4 can join the many other ways progress and stability are communicated to those without their eyes focused on the world of CSS.

Anecdotally, I often find myself in the role of teacher and advocate for the new capabilities of CSS, and I am often met with either surprise or mild disbelief - more than a few engineers I work with feel concern that the new features in CSS might not really be production ready, and as a result, do not prioritize the time to delve into them. In a time-scarce world where things are being versioned with a vengeance, seeing CSS3 remain static sends a message. Designers and engineers constantly have to prioritize what to learn and what to keep up with. A clear and well defined list of "this is CSS4" would instead signal that these things are worth prioritizing to learn today, not later, and encourage trust so that the developers don't have to ask "but is it ready to use yet?" as the first comment on every blog or at every Q&A.

A 'major version bump' so to speak, from CSS3 to CSS4, will get designer and engineer attention and send a clear message of progress and stability. My hope is that it will also help to add weight to folks writing job descriptions, deciding on frontend architecture, and shaping team roles.

[chriscoyier]

It's been so long since CSS3, the list is pretty deep.

The big ones:

• Flexbox
• Grid
• Custom Properties
• Variable Fonts
• Logical properties

smaller:

• Filter / Blendmode / Backdrop?
• Independent transforms?
• Color function adjustments?
• Columns changes?
• clipping / masking?
• focus-visible / focus-within?
• ::marker and list-style stuff?
• object-fit?
• scrolling stuff like scroll-margin, overflow-anchor, etc?

And what is the criteria for inclusion? Supported in 2 of 3 major engines or however we refer to it these days?

[rachelandrew]

I'm not a fan of this idea, and it's been raised to me in person in the past, and I wasn't a fan then. The reasons being that I think what authors want out of a CSS4 is a declaration that a certain set of specifications are "ready to go", and can be used. However, this goes against the real situation which is that it completely depends on the project you are working on, what you are able to use. From talking with the developers I teach in workshops they work on projects with wildly differing requirements, based on the users of the sites and applications they build.

Then on a practical level, we have specifications where a big chunk of the spec is well supported in browsers, and then some of it has no support at all. As an example, Box Alignment, it was tricky enough to figure out how to represent support when documenting this for MDN, as we have properties and values that are supported fully by browsers in Grid, but not at all in Block Layout. We have gaps which are supported in Grid and Multicol, but not by Chrome in Flex. So where would Box Alignment live in our CSS4? What about Fragmentation - is that "production-ready" in any way that would make sense to authors?

I think on an ongoing basis this would also add extra overhead to the decisions we make as a group. Not only will it be a case of deciding whether to add a feature based on the maturity level of a spec in our own process, we will have this additional abstraction of a CSS level we are promising authors. It's more work, do we need more work?

Also, CSS is not just for web browsers, so how does this fit into the world of print?

I don't think that it's the place of the CSSWG to tell authors what is ready to use on their websites, because we don't know the support requirements of their websites. I think it would add extra overhead to our work, and store up problems in the future when we are then pushed to declare a CSS5, and have to figure out what that means for everything we work on.

I think if anything, as a group we can create better material to explain how the process really works, which would better enable authors to follow along. I think we are doing web developers a disservice to act as if they can't understand our process. It just needs clearly explaining. I've never explained how modules and levels work to a group and had people confused by that. And, if there needs to be any kind of "this is what is production ready for the web" that seems more like something which should come from web browsers themselves, it feels like the MDN Browser Compat Data would be a great start for that. I'm certainly not against coming up with guidance on this stuff, I just don't think that declaring a CSS4 is going to help.

[mbarker84]

I agree with @tallys:

I am in favor of anything that makes the work visible and valued. Defining CSS4 can join the many other ways progress and stability are communicated to those without their eyes focused on the world of CSS.

A lot of people I encounter are not aware of newer CSS specifications, don’t realise how well-supported they are, or don’t have the time to prioritise learning them. To be able to package up a “syllabus” of newer CSS modules that are widely supported under the label of CSS4, would help developers prioritise what to learn, and _may_ help shift the perceptions of some of those of the periphery of our industry too (clients, recruiters, etc.).

Yes, not everything is so clear cut in terms of what is supported, so nailing down inclusion criteria may be difficult, but there are a lot of specs (like the ones mentioned by @chriscoyier) that have very widespread support, and would be clear candidates. Most developers would have enough sense to understand that they would still need to discern whether something can be used in the browsers they need to support, and that inclusion in CSS4 doesn’t mean blanket support for older browsers. Whether it’s the CSSWG’s job to package it up in this way is a different matter, but I don’t see anyone else doing it.

[bkardell]

As I mentioned in wg then this came up "js developers seem pretty ok with the es model, would css developers too? There's an added advantage of consistency there to... css-2019".

Just pointing to that both @chriscoyier and @davatron5000 have mentioned a similar connection here so it feels like.. Maybe?

[mirisuzanne]

I think this is a great idea – and would help me both with clients and students. I also think @chriscoyier is on the right track for a next step here, diving into the first release:

1. Establish some criteria that work well for a first release (CSS4, or CSS 2020, or …?), and flesh out the list of features included.
2. Determine the format of a public "release" of this kind, and flesh out the first version. Unlike CSS3, it's not a spec – so what is it? A list of module-versions? A sort of snapshot based on support rather than on date? A summary or microsite of some kind? As in the discussion @AmeliaBR linked, what is the proper balance for a useful entry-point without requiring heavy ongoing maintenance?
3. Develop a plan for future releases (velocity, naming, etc) based on what we learn from compiling the first.

[Crissov]

JFTR: #4752 #4715

[Crissov]

TL;DR: Introduce versioned “Web …” authoring competency profiles instead.

I was a fan of modularization when it started after CSS 2.0. However, not everyone had the same idea how it would or should work. In my opinion, we should have had started with splitting the existing spec into parts without adding anything new, but in reality, almost _twenty_ years later, some modules and some external specs still need to reference CSS2. Another effect was that it took like a decade for the WG to agree that modules that build upon Level 2 would start at Level 3, whereas completely new modules would start at Level 1, despite “CSS3” being the popular term. Some modules are at Level 5 now (or soon). That is why I believe that “CSS4” in particular would not be a good marketing term.

We originally had some Profiles of CSS (e. g. for handhelds, TVs and printers) that bundled certain modules and, unfortunately, also picked single features out of other modules, which together would need to be supported to claim conformance. It was thought okay to not support entire modules if it did not make sense on the platform or for the vendor – nowadays we are closer to a monolithic ubiquitous and open “libcss” that tries to support everything than we ever were, despite some forks and a good, mature and also open alternative.

Today, all we have are supposedly annual snapshots released by the CSSWG _for implementors_ and external sites documenting real-world support by custom criteria. Common, reliable test suites for objectively determining conformance are still regarded of secondary importance by many.

I did consider to suggest a numbering system for “CSS” that significantly differed from classic Levels, which individual modules shall continue to use, and did not imply annual updates which – letʼs be honest – the WG will never finish in time anyway. The system I preferred was loosely based on browser version numbers: CSS n would be (roughly) what could be assumed to work sufficiently well in all of Edge/Chrome version greater than 10×(n+1) and Firefox in greater than 10×n. The current state would therefore be between CSS6 and CSS7. I came to the conclusion that this is too unintuitive and unreliable, though.

What I do suggest are entirely new terms for bundles/profiles/sets of (ideally only full) modules, versioning independently of CSS module levels:

• Web Typography
• Web Layout
• Web Media
  
  
  
  • Web Graphics
  
  
  • Web Coloration
  
  
  • Web Animation
  
  
• Web Interaction, Web UI
• Web UX

These would also include (parts of) other specs like HTML, SVG, JS and HTTP if necessary.

[huijing]

I think @davatron5000 raises a salient point about how the TC39 chose to handle ECMAScript with "big" releases of each version seems to be received well with many people. But I think the key difference here is that CSS was modularised, which makes it tricky to do something similar like a CSS2020 or even CSS4 as per the original suggestion.

There is also a significant difference for the Javascript eco-system that goes beyond perception alone, which is Babel. Developers generally feel safe to use all the latest and greatest ECMAScript features because Babel is there to take care of the cross-browser/backward compatibility issues for them.

In relation to this idea, I find myself agreeing with @rachelandrew that the issues with adoption of newer CSS properties are also significantly dependent on how and when browsers implement them, especially browsers with significant market share. I'm very much for more explaining about the process.

That being said, I feel that I do have a significantly subjective emotional connection to CSS that perhaps clouds my perspective, which is one the majority of web developers probably do not share. The crude analogy I can draw here is you cannot unlearn how to ride a bicycle. And for me, understanding the process and embracing the varying levels of browser support is the bicycle I have learned to ride.

What is the best way to teach the general web developer how to ride this bicycle as well? But I suppose the heart of this topic to begin with was how to even get the general web developer to want to ride this bicycle.

The points I've seen repeatedly mentioned by people above this comment thread are:

• [CSS is] generally perceived as stale (@davatron5000)
• new features in CSS might not really be production ready (@tallys),
• not aware of newer CSS specifications, don’t realise how well-supported they are, or don’t have the time to prioritise learning them (@mbarker84)

And I agree with these observations because I see them often as well. I'm just not sure if CSS4 is the appropriate way to trigger "excitement" or push web developers to learn more.

[SelenIT]

I'd like to link to my long comment in the related issue explaining why I believe that the value of CSS Snapshots for authors might be still significantly underrated.

The concept of separately progressing features finally getting incorporated into the yearly updated main standard is already familiar to web devs from the EcmaScript process. We are used to speak, e.g., about "arrow functions from ES6/ES2015", or "async/await from ES2017/ES8".

"CSS as a whole" has no versions, but it has a document with the short URL w3.org/TR/CSS that appears to suggest that it somehow describes the state of "CSS as a whole", with a section named "CSS - _the Official Definition_" (sic!). This document is also updated roughly every year or two, and the latest definition (CSS-2018) is the 5th update since CSS become modular, or the 7th "CSS definition" counting from CSS1. In other words, if we named "CSS revisions" after the edition numbers of the standard definitions (like ES3, ES5, ES6 etc.), we could call it "CSS7" – good match to @Crissov's estimation above (and the upcoming definition, CSS-2020, would be "CSS8").

The only thing I'd like to add that for web authors the union of the "Official defininion", "Deployed with rough interoperability", and "Safe to Release pre-CR Exceptions" sections would probably be more useful than the "Official definition" alone. This set of features appears to be "stable enough" for many practical applications, either well-supported or soon-to-be-supported in browsers, so developers would know that it's probably worth learning. Another useful part of Snapshots is that they explicitly exclude outdated parts of specs (e.g. CSS2.1 sections superseded by newer modules), clearing the confusion and reducing the cognitive load.

Looking through the history of CSS from this POV, we can roughly categorize its features by different CSS "revisions":

Year | "Revision" | Features added
----|--------|--------
1996|CSS1|Basic concepts of CSS: cascade, type, class and ID selectors, link pseudo-classes, :first-line/:first-letter, box model, block and inline formatting, floats, font properties, #hex and rgb() colors, absolute lengths, em and ex units, "reference pixel"
1998|CSS2|Attribute selectors, :first-child, :before/:after, > and + combinators, @media, @page, table model, cursor, outline
2007|CSS-2007, or "CSS3"|display:inline-block, new attribute selectors, :: for pseudo-elements, :last-child, :nth-child() etc., :empty, :target and :not(), ~ combinator, hsl(), currentColor and opacity, CSS Namespaces, style attribute standard
2010|CSS-2010, or "CSS4"|Media Queries 3 (width, orientation etc.)
2015|CSS-2015, or "CSS5"|CSS Syntax 3, nested @media and @supports, CSS Cascade 3, new units from Values and Units 3 (incl. px as absolute), calc(), multiple backgrounds, border-image, border-radius, linear and radial gradients, web fonts, Multi-columns, mix-blend-mode and isolation, updated cursor and outline, Transforms, Animations, Transitions, Flexbox
2017|CSS-2017, or "CSS6"|Writing modes 3, CSS variables, CSS Text 3, :dir() and :lang() pseudo-classes, min-content and max-content
2018|CSS-2018, or "CSS7"|CSS Grid, will-change, filter, easing functions, logical properties, conical gradients, :focus-within pseudo-class
2020|CSS-2020, or "CSS8"|contain, ... (to be continued)

Doesn't this make sense?

[zeldman]

COMPLEX issue. So grateful to you for raising this issue here, Jen! I totally get where you're coming from and agree with the big idea here. Ajax™ succeeded in part because they called it Ajax. Web Standards succeeded because we called them Web Standards. Names matter. One year, four brilliant people at An Event Apart presented a concept whereby media queries could make one design serve all devices. One of those brilliant people called it “Responsive Web Design.” It’s no accident that the Bible starts with The Word as God’s tool for creating reality, and the first thing that happens after creation is God tells Adam to name everything. For that matter, even with all the hard work you and Rachel Andrew and a few others put in, “Grid” and “Flexbox” might not have succeeded if they hadn’t had such catchy names.

Additionally, a point many folks here have brought up is also true: that version numbers suggest “newest thing to learn” and “progress is happening,” whereas sticking with HTML5 and CSS3 contributes to a feeling that there’s nothing new in the world of HTML and CSS … so folks motivated by learning new things (or folks who just constantly seek the excitement of shiny and new) tend to discount HTML and CSS as “done deals,” even though they clearly have continued to evolve.

That’s not the only reason respect for standards-based, progressively enhanced, accessible web development is in decline. We can find additional causes aplenty in startup culture with its constant shipping (sometimes for its own sake), and in the way startups evaluate worker performance (quantity of output), and in the corporatization of web development (along with the corporatization of politics, law, “justice,” basic human rights, etc.). Bootcamp culture and bootcamp training (versus slow self-training over years of experience) also tend to favor mastering the newest tools and prize developer convenience over user experience—because, after all, the corporation needs all those churning iterations, and developers who can’t ship fast lose out to those who can. Hence the obsession with shiny new tools. It’s not just a childlike fascination with new toys. It’s a cry for help in a ruthless and ill-considered employment market.

So I get why this proposal could be a very good thing.

But I also hear where Rachel Andrew is coming from. I won’t repeat it here since she makes her case with perfect eloquence. Although I have a thought about that, too: namely…

Perhaps, instead of setting version numbers based on a spec being fully supported in all major browsers, we go back to what happened in the old days: a spec was stabilized when at least two major implementations supported it, and other browser makers strove to catch up with that whole specification (i.e. to catch up with CSS 2.1, for example).

One unintended side-effect of breaking CSS into millions of small, evolving sub-species like CSS Grid is that it inadvertently encourages browser makers to pick and choose what they’ll support. That picking-and-choosing fosters innovation and testing, which are good things. But they also foster a buffet mentality that has led to a lot of fragmentation in browser support … which inclines many folks to throw up their hands and say, “It isn’t supported in Browser X, so forget it.”


Grouping together a series of accepted improvements into a single CSS 4, and telling browser makers to support THAT, would cut down on the impossibility of supporting everything correctly that frustrates browser engineers, and the lack of respect for HTML and CSS that pervades our current culture. And there would still be room for any browser maker who wishes to to support additional, experimental specs if they choose. But there would be enough specs that work across the board for people to get on board the Web Standards train again. At the very least, it would take away one big rationale some (not all) folks who design JavaScript-first wield as a cudgel when the subject of web standards arises.



[NOVALISTIC]

As an observer, I've seen the everyday categorization of certain specifications and levels as "CSS3", "CSS4", "CSS5" and so on, to be extremely arbitrary and even inconsistent between individual authors. There is no pattern to it — not even a year-/period-based pattern as far as I can tell. And as mentioned, different modules (and levels thereof) are written, tested, and implemented, at such wildly different paces across competing implementations that there is just no sane way to keep track of them all.

Anything that looks "newer" or "unlike traditional CSS3" is binned "CSS4", such as variables for example. Yet, some specifications like Selectors have somehow managed to survive most of this arbitrary categorization unscathed — level 3 selectors are considered CSS3, and level 4 selectors are considered CSS4.

I believe this work should start with a conversation with Authors

I can answer at least the first question, to some extent. I don't have the energy to comment on any specifics but I wanted to say something general right now at least while this is fresh in my mind.

Would it help to officially define CSS4, and what’s in progress for CSS5?

It would, provided vendors are willing to focus their efforts on each version or level of CSS-as-a-whole. selectors-4's FPWD was over eight years ago, and we still barely have any implementations other than Safari since 2015, and Firefox a little more recently, despite at least half of it being relatively stable and unlikely to change. If everyone's ready for CSS5, selectors-4 might as well be renamed wholesale to selectors-5, skipping L4 altogether (which I guess partly answers the second question).

If the CSSWG does decide to adopt some semblance of a snapshot system, I'd much prefer year numbers over version numbers, like with ECMAScript as mentioned.

The only feasible (if that) alternative would be going back to monolithic CSS, only with any number of subsections, each representing a module.

[folletto]

I'm in favor of the proposal, even if I agree it needs to take into account the criticism that has been noted above, and find ways to compensate it.

I think the main advantage is from a cognitive perspective even before the marketing angle. It's easier to wrap the mind around, which is why it's easier to market, which is why it gets marketed. While I totally see the downside of a misrepresentation, there are major upsides in creating every few years a form of "major snapshot" that is has a bit more weight than existing snapshots.

The downsides should be compensated however. Rachel Andrew has a point, and I feel that while doing CSS4 (and following) it's also important to use the chance to clarify these points too — whichever form it could take. Maybe it's a matter of defining stages of features inside these major snapshots, or else. In the end, we have the "Candidate", "Candidate recommendation" and "Recommendation" already, we could do something like that.

I'd add one note: these "major snapshots" should not happen too frequently. Let's think in terms of cycle of adoption and education, which I feel have a 2-5 years cycle ("feel", so research is needed), and plan these cycles in a sensible way (i.e. I feel "1 year" would be too short).

[jeremyfuksa]

Lots of great points here.

As many pointed out, it seems like moving to a naming convention similar to what ECMAScript adopted makes a lot of sense. And, there could be ways to delineate experimental features and account for @rachelandrew‘s concerns. Whatever is “ready” (e.g. @zeldman‘s suggestion of at least two major engine implementations) is in the CSS4/2020 spec. Everything else is experimental and could be adopted by browsers and implemented through config flags or browser prefixing.

As for how often this spec gets updated, I’m in @folletto’s camp that yearly might be too much. That’s just going to fuel the fire that we’re never going to catch up with the building blocks that are the foundation of our livelihoods. 3 years seems like a nice number because that will also allow for accumulation of features that make a new spec worth learning while (hopefully) minimizing that FUD of never catching up.

[pp-koch]

Wow, there is a lot of interest for this idea. Great to see. I can't go over all contributions that have been made so far, but would like to make a few points from my perspective.

When I started thinking about CSS4 I didn't see it as something that should be rigidly defined. In fact, I'm arguing for a fairly vague and hand-wavy approach, where we mostly leave it to individual developers to figure out what they would like "CSS4" to mean. That makes it much easier to raise excitement, I think, than going through a list of modules, some of which you don't need.

I'm not sold on the CSS2020, CSS20201 etc. idea, mostly because it conveys a sort of nervousness that I'd like to avoid. A new version every three years or so sounds about right to me. But maybe that's just me getting old.

Also, I hadn't considered the CSS WG taking the lead on this (though in hindsight I should have). The problem has already been described: if the WG takes the lead, that pretty much requires some sort of definition, which leads to a lot of work on the part of the WG.

My original idea was to take a few modules and make them the spearhead for CSS4 (see below for suggestions). After that, we might elevate any new specification to CSS4, and if enough developers are enthusiastic about a certain module or feature, we could retroactively elevate them to CSS4 level as well.

Yes, this is a vague process, but I'm not sold on the need to have a better-defined process. I would fully understand if the CSS WG wants to keep CSS4 at a distance for that reason and leave it to developers to decide what CSS4 actually is, though the WG should be sold on the basic concept and agree that CSS4 is a Thing.

To me the purpose of CSS4 is to reach out to people that are currently outside the hard-core CSS world; JavaScript developers in particular. That's why I feel that the first modules or features that get the CSS4 stamp of approval should be picked carefully to appeal to them.

In my latest piece I argue for custom properties to take on that role, both because they are already somewhat known (hey! CSS4 isn't hard! You already know some of it!) and because they will appeal to JS devs.

Also, I think grid should be part of CSS4, mostly because it's the most important step forward in CSS in many years, and also because it's already somewhat known.

We should also have a few features that are on the horizon but not quite here yet, and I'm especially thinking of container queries. I'm not up to speed with the current discussion around container queries, so I'm going to leave it at saying that for a marketing/outreach effort aimed at JavaScripters they make a lot of sense.

That's where I stand right now.

[jonbell-lot23]

A co-worker just pointed out that 5G is an interesting comparison. 5G means a lot of technical things, but picking one name helps to drive adoption in the real world.

I've often thought of it like a suitcase with a handle. So many odds and ends go into these discussions, and they're all valid and important. We can't just ignore them. But it's good to have a way of saying "everything in this problem space can be encompassed (or at least referred to) by a single name." It's like a handle on a big, complex suitcase of ideas.

[tzi]

Thanks @jensimmons for creating this official discussion!

I vote for a new CSS version, because as a French CSS developer:

• I witnessed very few books in France since CSS3 (except Flexbox & Grid)
• I witnessed very few training request since CSS3 (except Flexbox)
• I witnessed very few interest from JS developers since CSS3 (except Flexbox)

I vote for a yearly snapshot because it's predictable, regular, and it makes a breaking change with the old version number.
For the question of how the author will know which CSS they can use, I think the browsers will be very happy to announce their full support of CSS2018 or CSS2020, since it's very good for marketing. So I'm not afraid of this.

[impressivewebs]

I appreciate the enthusiasm here, and I think if the CSSWG can figure out a way to make this work, then I'll support it. But, as I stated in my response post, this is kind of bizarre to me because I feel like we're already doing this but on a different level.

For example, Nicole says above:

In the constant stream of things we need to learn, it's nice to be able to tick the checkbox and say "yes, I have learned CSS4".

We already say things like "I've ticked the checkbox and learned Flexbox and Grid Layout." I mean, can anyone here say that the marketing push for Flexbox and Grid Layout haven't been huge over the past 5 years? It's been equal to, if not better than, the marketing push of "CSS3". There have been no shortage of books and conferences talks and tutorials covering these subjects. I almost feel like meaningless phrases like "CSS4" actually are harmful to marketing, because they're not as immediately clear as to their practicality as something like "Flexbox 2" or "Grid Layout 3", etc.

I also don't think CSS's annual versions are going to bring the same excitement as, for example, ES6+ annual releases/snapshots have. And besides, there isn't a lot of excitement around the latest ES releases. Certainly not nearly as much as ES6 and the one or two releases after that. So what are we trying to replicate exactly?

Anyhow, I'm on board with doing anything that pushes the web forward, and I'll gladly help promote CSS4 if it becomes a thing. And I'll happily eat my words if this works. I just don't think the industry is lacking anything and I never really got the impression that CSS needed any more marketing. I think CSS is doing great!

[amazingrando]

_Puts on designer/marketing hat as I read this thread, so I'm jotting down some HMW's:_

• How might we get people excited about new CSS features, so that we spark new investments into CSS, education, and implementation?
• How might we do this in a way that respects the true status of CSS specs?
• How might we accomplish this with the resources and people we already have?

[fantasai]

I don't think that it's the place of the CSSWG to tell authors what is ready to use on their websites

I agree, and I think if we do this, the list has to be generated by the authoring community, CSSWG just makes it official by publishing it.

Let's think in terms of cycle of adoption and education, which I feel have a 2-5 years cycle

Agree 100% with @folletto's comment: 1-year cycles are too short to have the sort of marketing impact that this would be meant to serve. (And also I just don't think we have the capacity, we're struggling already to do the snapshots yearly even though they're less subjective. :)

[scottkellum]

Agree. CSS3 came out when we were still doing float based layouts and vendor prefixes were everywhere. Grid, flexbox, variables, calc, and more along with how they were rolled out have dramatically changed the landscape of CSS and I totally agree it’s time to version up.

In terms of _this is what developers should know,_ I’m curious if this can be an opportunity to do some housekeeping around some drafts that are widely implemented and used yet are still somewhat unstable. For example, the pure CSS parallax technique that relies on transform-style from the still in draft transforms level 2 recently broke in Safari. Finalizing and adopting drafts like these would be nice.

[ahmadalfy]

I am in favor of the proposal but I keep thinking about how are we going to transition everything that was modularized before?

[Crissov]

@ahmadalfy Nothing about the modular structure of CSS specifications needs to change nor will it change.

[sw-yx]

Hello - causal observer here! excited by this discussion.

Since @AmeliaBR and @mirisuzanne already brought up the idea of yearly versions instead of major versions, I just wanted to introduce the idea of talking to TC39 to learn from their experience. No doubt many here already do so I'm not sure if my comment has any value at all, but AWB and Brian Terlson had this fascinating exchange last year where they discussed the pros and cons of the yearly release model (not tagging them bc idk if they want to be pulled in here). For example something that seems to be naturally emerging is themed "waves" of features for more coherent design.

If we do this, regardless if we call it CSS4 or CSS2020, we're gonna need a plan for CSS5 or CSS2021. Could do worse than learning from the experiences of TC39. i agree with basically everyone here that keeping to a 5 year cycle minimizes churn and maximizes impact.

[jensimmons]

To be clear — both in response to @ahmadalfy's comment, and to some reactions I saw on Twitter: no one is proposing that the CSSWG put all the separate specifications back into one giant (now-extra-giant) single spec. That would change how the CSSWG works, and create a significant impediment to their process.

It's true, CSS1 and CSS2 were specs that had everything. CSS3 basically consisted of all the newly-separated specs, that had all been incremented to Level 3. Since the splitting-out of the specs, brand new specs (like Flexbox) are started at Level 1. Some of those have reached Level 2, even 3. Some of the other specs went on from Level 3 to 4 or 5... (For anyone who's unclear about this, I explain it with more detail in this video.)

If we define CSS4, it will include some specs that are at Level 1 or 2 (Like Grid 1 and Grid 2). It will include some specs that do happen to be at Level 4. It may include somethings that were added to a Level 3 spec much later than "CSS3", or include work that's in a Level 5 spec.

“CSS4” will be an umbrella term, meaning a bucket of stuff that happened roughly between 2011 and 2020, without any regard for the actual Level of the individual specs included. And it will have no impact on how individual specs are created or numbered by the CSSWG.

[bkardell]

I'd like to clarify my position somewhat. I see the value in what people are suggesting. At the same time I also think that "CSS4" is bound to cause confusion for precisely the reasons @jensimmons just listed. My own thought here is that calling is "4" isn't necessary and it's probably less than helpful for the inevitable confusion it causes. _Many_ other kinds of names could work for this purpose. I had said "css-2020" not because I meant an annual thing (though... there could be a world in which identifying the things we were all concentrated on trying to land is valuable maybe) but rather in order to break the naming system issue. If we identify "css-2020" now and don't have another until "css-2023" or "css-2025" -- that seems fine? The point is just no one can get confused with the existing or old versioning schemes here.

[fantasai]

@bkardell Calling the next collection of modules CSS4 has a few benefits over year names:

• Builds on existing familiarity with idea of CSS1, CSS3, CSS3
• Doesn't set up an expectation for yearly releases or get mixed up with the year-based spec-maturity "Snapshots"
• Allows us to build up and talk about CSS.next without trying to guess when we close its definition.
• Doesn't label the collection of technology with particular timing, allowing individual developers, who (as Rachel points out) have different ideas of when something is sufficiently mature to become relevant to their work, to decide what year it's "ready" for them.

[jensimmons]

@bkardell just wrote:

I also think that "CSS4" is bound to cause confusion for precisely the reasons @jensimmons just listed. My own thought here is that calling is "4" isn't necessary and it's probably less than helpful for the inevitable confusion it causes.

I don’t agree that labeling things from a Level 1, 2, or 5 spec as “CSS4” will be at all confusing to Authors. Why? Because 99.9% of Authors have no idea that CSS is born in specs that have Module Level numbers. Some of the biggest fans and best teachers of CSS Grid have no idea what's in Grid 2 vs Grid 1 & Grid 3. (Rachel knows. I know. But we are both on the CSSWG.)

Web designers & developers don't care. Spec level numbers are not part of _any_ conversation Authors have. It's the CSSWG who knows the level numbers by heart, and refers to them as a thing. It might be hard for CSSWG members to understand how little this will matter — but it won't matter. Authors will not be confused.

[ExE-Boss]

If we do use year numbers, then I’d prefer if we use the Holocene calendar (Gregorian + 10000):

12020 HE = 2020 CE

[shaunrashid]

I have been debating this in my head for the past week. Based on recent experience within the company I work for, I do think that packaging groups of CSS modules into "marketable" versions has more benefits than drawbacks especially when it comes to having the priority conversation with non-technical (or even non-frontend) stakeholders.

A recent example is that the team wanted to introduce custom properties into our code base. Using "CSS4" with stakeholders allowed us to frame the discussion as an upgrade as opposed to wanting to use a particular technology. The conversation with stakeholders is much more straight forward when we can say that we want to "upgrade to CSS 4.x" and outline the specs that make that up as opposed to we want to upgrade to use "module A, version 3", "module B, version 2", "module C, version 2".

While technically it makes no difference, I feel like having these "versioned groups" allows people who are not familiar with the specs to grok and scope what it means to adopt newer levels of the specs.

[shaunrashid]

On the question about who should be determining what "CSSx" is, I agree with @rachelandrew and @fantasai that it should be the authoring community that defines it. They are the ones writing the code on a day-to-day basis.

I also think it is also the responsibility of the authoring community to have a general understanding of how the specs are organized/released so that they can make informed decisions on what the "versions" should be as well as enable them to push on browser makers to prioritize/implement specific specs so that the versions can be practically adopted.

[mzaini30]

I hope there's .parent() in CSS

[bkardell]

Calling the next collection of modules CSS4 has a few benefits over year names...

@fantasai Yeah, I debated whether or not to use `a year name again even because, as I said - _many_ kinds of names could work, and I'm not actually trying to suggest one as much as that it _might_ be valuable to break with the current naming a to avoid confusion. Is that valid or valuable enough..... idk, honestly.

99.9% of Authors have no idea that CSS is born in specs that have Module Level numbers.

@jensimmons We spent a really long time publishing "there is no css4" stuff... Google returns a lot of pieces on this. The actual drafts and MDN documentation and posts and presentations and talks that say 'level 4' or 'level 5' or whatever -- that's all I mean: There is lots of opportunity for confusion floating around out there already. Again... does this really matter.. idk?

Please don't read too much into any of these replies: I don't feel super strongly on any of this and i'm definitely not trying to be argumentative about it. I just wanted to make sure that my own worries/thoughts were properly expressed. I fully agree that there are many very good points in this thread and I'm very happy to accept whatever the group/community decides here.

[mandymichael]

There are a lot of good comments here and I am torn between the options...for what it's worth though I agree with the statements around it helps the wider community understand that there are new features/ CSS suffers a lot from people not knowing that new things have been added, and as a result people keep focusing on older techniques that are not ideal, this often reinforces negative opinions about CSS.

When you move in circles of people who are deeply embedded in the CSS community it’s easy to think that people know and understand everything that CSS has to offer (or what is coming up) but in my experience we are the minority, not the majority. I consider myself to be fairly “in the know” about different CSS additions/upcoming features, but I don’t think the decision should be made based on someone like me. I would not be the target audience for a system like this, and it wouldn’t really be of any benefit to me either.

Thinking about it from that perspective, and given that CSS is already perceived as very different from other languages, I believe the best approach would be to choose a method that is easily understood by the vast majority (e.g. a standard versioning approach)

Reading through everyone’s comments there are excellent points for and against. But I also think we should think about this from the perspective of a back end developer who typically relies on bootstrap, or a developer who doesn’t have time to read up on blog posts and follow industry experts on twitter – the people who just need to get stuff done. It is largely a marketing approach, sure, but if we want people to love CSS as much as we do, then we need to show them why in a way that is easily digestible, and I'm not sure we can say that the current approach accomplishes that.

[bkardell]

One last point here which I realized I have failed to articulate but is maybe important... We have in the past wanted a 'label' like this and as @zeldman notes - lots of terms have come from the developer communities "Web 2.0" "AJAX" and "Responsive Design" all being great examples of similar things from the past that seem to have a lot in common with the ask here. It would seem to me that is it very possible for the community to actually try this today and this has the advantage of being non-speculative. I mean, I could imagine labels like "CSS Epsilon" and "CSS Delta" might even work - but that is just total speculation. However, if someone tries to do this, and whatever they call it or whether that even involves numbers in any way feels unintuitive, it seems to me the community will naturally pivot, offer alternatives and redirect more naturally and arrive at something which at least has some data "enough people seem to get this". And then we can, if we want, write it down - like dictionaries do -- officially... or even just use it. CSS WG members freely use terms that aren't born in standard or written down rigidly somewhere like "responsive design".

So I guess my question is: Is this an issue for the CSSWG, necessarily? At this stage? Later? Or is it just a way to discuss whether there might potentially be something that someday could be? Or...?

[marekgebka]

While agreeing that promoting the current evolment of CSS as a version 4 might re-create the former buzz of “CSS3”, let’s not ignore the fact that also many professionals weren’t able to use these then new features due to project constraints such as browser support and stubborn project- or tech-leads. I used to work for a company back then that forbid the usage of vendor-prefixes and every single CSS3 feature due to a “lowest common denominator approach” of ensureing browser support, as it was seen as a way to avoid “extra work”. The last agency I worked for, to this day, is trying to avoid flexbox since it is “hard to understand” and “is behaving unpredictably”. Although we have new and more efficient ways to progressively enhance our websites etc. I can imagine that this would still be a reality for a lot of developers out there. Also, perhaps you have noticed the usage of the word “might”. The status of JS back then was also a bit different. So I have serious doubts if CSS4 would actually create the same marketing effect today that CSS3 was able to generate.

Also I am afraid that browser vendors might slow down when it comes to implement these new features since it then would make sense to wait until a new version is “complete” of “worth” supporting.
Grid IMO was so successful because it solved a decade old problem CSS devs were facing but also due to the fast pace in which the browser vendors were picking it up (and great learning material by Jen & Rachel etc.).

I’d personally like to see a just as lively discussion about how we could push CSS & progressive enhancement more as a whole than CSS4 etc. since it feels like the more concrete lever to pull here.

[syriaca]

TL;TR thread, but it is a very interesting subject.

The main question coming to my mind is: where end CSS3 and where begin / end CSS4 ?
Who must define that ?

[laras126]

Would it help to officially define CSS4, and what’s in progress for CSS5?

Speaking from a developer and CSS teacher/advocate perspective, YES!!

And per the other conversation here, I love the prospect of continuously versioning CSS. Versioning is a familiar practice among other programming languages, and one that I believe would encourage developers outside of "the inner-CSS circle" to take CSS more seriously, and to approach it as a true language. (similar to points from @mandymichael)

On my team (and many others), there is a lot of reliance "the CSS person" to be in the know regarding new CSS features, and to decide what to incorporate into a code-base and when. I believe consistent, ongoing versioning would help make CSS more accessible to more developers, and provide a much clearer update path for applications like design systems and UI frameworks. "What new CSS should we use?" is a current conversation in the WordPress core community, and an explicit version and changelog would be extremely helpful.

What goes into those two buckets?

I am not intimately familiar with different levels and status of new parts of the spec, so this is very high level, but perhaps useful from developer's perspective and for thinking in buckets:

CSS4 (features most developers are aware of / starting to use regularly):

• Grid
• Custom properties ("starting to use regularly" is perhaps an overstatement, but still)

CSS5 (things uncommon outside the "inner-CSS circle", or things that are still in draft stage):

• Subgrid
• aspect-ratio
• Variable fonts

In terms of how the versioning works, there are many options for versioning out there in addition to JavaScript's – WordPress, PHP, and Python are a few that come to mind for me, _or_ – potentially better idea – reference languages that share characteristics with CSS (declarative, domain-specific), like SQL.

If a decision is made to consistently version CSS (I hope! 🤞), perhaps a next step could be outlining some different options for versioning and requesting community feedback via a formalized questionnaire?

[rickgregory]

Some thoughts from a humble developer...

I try to keep up but frankly, I learn about the new things that solve problems for me and often discover new CSS features while searching for a way to do something. That's got advantages - I spend less time learning things that aren't useful to me now - but of course I sometimes learn of something new and think "I could have used that in [list of projects]...". But as a day to day author, I simply can't spend the time to learn of new things, play with them and then not use them, especially if, when I hear of them, they're only supported in Chrome Canary.

So, yes, if a CSS4 gets browser vendors on board to full support a list of features, that would be great. However, I do think that we'd need to see new versions at least every 3-5 years. Decade long pauses aren't really going to solve anything.

In some ways, this is a solved problem. Back in the boxed software days (yeah, I'm older... ), a major revision (3 to 4) meant that the release had big new things in it. A dot revision (.0 to .1) meant there were noticeable new features but they were smaller. A really minor revision (.00 to .01) was often a bug fix release to the corresponding dot revision.

So, what's wrong with porting that logic to CSS? CSS4 would have Grid, Flexbox, etc. 4.1 would have smaller enhancements (I like @chriscoyier's list above). I don't think we need annual version revs, though. @davatron5000 said upthread that _"...JavaScript has seen a huge explosion in velocity and has published the following standards since 2015: ES6, ES2015, ES2016, ES2017, ES2018, ES.Next, ES7, ES8, and ES9...."_ and, honestly, I'm not sure that's a positive thing. Think about it from a front line perspective... do you need to keep on top of (counts....) NINE different versions that have all happened in the last 4-5 years? Is there engouh significant difference from one to the next to really deserve a version rev?

[mateusfg7]

how works CSS4 in react? :thinking:

[andreluizmartinsramos]

Hey Guys!

I'd love to have :parent selector. :shipit:

[eric-dos-reis]

Great idea, it will be amazing if we have a new version of CSS every year, like EcmaScript:

CSS2018, CSS2019, CSS2020 ...

Please, think about it.

[davidfitzgibbon]

The effort of maintaining this sounds crazy for all you lovely people who actually do this work ( so far I havent contributed ).

What if we just made a list of when each functionality was released? I've made an _extremely crude and poorly researched_ example of what that could look like here: https://cssiv.net/

I've called it CSS IV to mean CSS Inferred Versions. We can infer a versioning, without putting lots of people volunteering time to "waste".

That's if it is to be purely for people to use CSS4 / CSS2020 as a marketing tool. I see @jensimmons has set out a proposal for a group for CSS4. I hope the efforts of those who volunteer for that group come to something truly educational ( like Jen's own videos for the Mozilla Dev channel on YouTube ).

[luiscobits]

I'm not a senior dev, but I want to say that it would be good to also design generic logos for css and html (without versions)

The current "semi" official logos:

[troxler]

Having "releases" probably would make the discoverability of new features easier, at least for people who are not that deep into CSS. Having said that, I personally mostly agree with rachelandrew's comment. I think that better explaining material would help more.

With the existing CSS Snapshots (e.g. CSS Snapshot 2020), there is already some "versioning". But most people probably do not read those specifications and are more interested in what actually changed in between those snapshots. To make those more visible, I envision a document similar to release notes. But it might go more into the direction of "CSS Recommendations", i.e. it includes only features whose (as zeldman suggested) "spec was stabilized when at least two major implementations supported it". For example, "CSS Recommendations 2020" might include all new specs since the previous "Recommendation" that have at least two major implementations. In addition to that, some things have to be explained in very simple terms:

• One very important aspect in my opinion is to make it crystal clear that browsers do not implement versions of the specifications. Not for ECMAScript, not for HTML, and not for CSS. Instead they implement individual features.

• Two implementations is not enough for most websites anyway. Based on the data of caniuse (or similar), there should be an easy overview of exactly how many and which browsers support those specs individually.

So essentially such a document goes into the direction of CSS IV as mentioned by davidfitzgibbon but with more emphasis on the spec's stability and adoption.

I put "Recommendation" in quotes as I'm not sure this would a good name. And I know that this is exactly what rachelandrews argued against. Maybe such a document could be published outside of the official CSSWG channels (maybe on MDN?). But then it might also lose some of its marketing goal.

---

Off topic:

@davatron5000 @rickgregory

Meanwhile, JavaScript has seen a huge explosion in velocity and has published the following standards since 2015: ES6, ES2015, ES2016, ES2017, ES2018, ES.Next, ES7, ES8, and ES9.

That is not true (or at least very misleading). As of ES6, new ECMAScript specs were released in a yearly schedule (i.e. there is one new version each year). Since 2015 they released ES6 (=ES2015), ES2016 (=ES7), ES2017 (=ES8), ES2018 (=ES9), and ES2019 (=ES10). ES.Next is not a standard but a working draft.

[Crissov]

One kind of versioning has not been mentioned yet: arbitrary and opaque code names like the large cats and now Californian landscapes Apple is using infamously for their desktop OS or the sweets that designate major Android (API) releases. I think Ubuntu has a similar system as Google, wherein the initial letter is increased alphabetically, so it is not completely arbitrary in fact.

Example

1. CSS Level 1: CSS Aquamarine
2. CSS Level 2: CSS Blue
   
   
   
   1. CSS Level 2 Revision 1: CSS Azure Blue
   
   
   2. CSS Level 2 Revision 2: CSS Baby Blue
   
   
3. CSS Level 3, e.g. Defined as all modules that started at Level 3, because their features were already in Level 2, _and_ that reached CR before 2015: CSS Cyan
4. The current stable state: CSS Dew

PS: Texʼs version numbers are increased by adding another significant figure of an irrational constant like e or π, but that is hardly a good model for CSS.

[cosmicvibes]

If I may chime in purely as a user of these technologies (and no expert by any means), having a clear new numbered standard would help immensely.

I have long since fallen behind on what is or isn't current in CSS, no doubt mixing outdated stuff along with a sprinkling of new in my code. But I'd like to sit down and re-group myself - learn what is current, and what I should let go. But trying to work out which books, tutorials and blog posts are a) current b) not too bleeding edge that I can't use it - is a daunting prospect. I'm sure there is a way but having the label "CSS4" meaning "current and usable on most modern browsers (ok yes, realistically with a few caveats that are being worked through)" would have me buy new books and read new articles - and so actually adopt the new technologies, whilst letting the old ones go to rest. Rather than just sitting on the things "I know work". That surely is good for the web?

That's what the numbers did for me before. Yes it is a marketing term - but I think that should be embraced. The number should indicate to the wider audience that this is ready to use. Some will cry that it misses out on the latest developments, and maybe even encourages developers to rest on old standards rather than keep up with the new. But we are doing that already! Not all of us have the time to keep up with current events, and so rely on the number bump to give them a kick. I wager that not having "CSS4" keeps many using "the CSS3 they know" which does not include much/any of the new stuff. The excitement of the new release and learning path would likely make people go back and rewrite old stuff, pushing things forward further.

And yes, if I were a full time web developer then perhaps by not keeping up I'm resting on my laurels and so deserve any problems I get.... but I'm sure the web is built by more than just full time web developers. And indeed I'm sure it is also built by some full time web developers who are really busy and just want to easily know what is what!

[JoshuaLindquist]

(I am a self-taught "hobbyist" web designer who works on only a handful of projects, mostly personal or volunteer-based.)

I think the pros of a newly named release outweigh the downsides, but I do think that it should be easier to learn how the CSSWG processes in general. The _only_ reason that I understand the process now is from listening to @rachelandrew's conference talks. Prior to 2017, I had no idea that CSS had been broken into modules. I just assumed that there was no CSS4 because CSS3 had not been fully implemented or finalized.

I think it's important that it be easier to learn the process, but I would also find great value in just having a list of new properties/concepts that are "ready". My suggestion would be to use the "are there 2 implementations" milestone to decide if something is "ready".

I don't have particularly strong feelings on CSS4 vs. CSS2020 or the annual vs. every 3 years' ideas. I do think CSS4 could be confusing after reading/hearing so often that no such thing exists - but it also took me several years to ever encounter them. This might sound crazy, but maybe it's too late for CSS4 and it should just skip to CSS5?

Annual releases sound like a lot of work for the CSSWG, and it could either be good or bad for developers. On one hand, a short list of new features every year is probably easier to keep up with than a larger list. On the other hand, a short list every year would more greatly add to the feeling of "I can't keep up". It may be easier for developers to 1up their skills less frequently.

Others have suggested that the list of features should come from authors; I think that's a good idea, and I would also suggest that maybe the community/authors could take a larger role in defining and maintaining the versions instead of that work falling to the CSSWG editors.

Overall, I like this idea, but there are clearly a lot of decisions to be made and concerns to address. Even for someone, like me, who works on very few team projects, I can think of _several_ situations where it would have saved me a lot of headaches if I could have just said: "we're building the new layout with CSS4".

[brendastorer]

What an excellent discussion from an excellent proposal.

I am in support of CSS4. The only thing I can add to the conversation that I don't think has been mentioned, is how this could help developers outside of the CSS community find more modern techniques to solve their CSS problems in Google searches looking for "CSS4", maybe even freshen up the CSS answers on Stack Overflow.

[pp-koch]

This is a great discussion! Allow me to summarise and reply to a few points - all from my perspective as a supporter of the CSS4 plan.

First, some people are afraid that CSS4 will confuse CSS devs because it diverges from the current modular approach, and from earlier statements that there will not be a CSS4. I do not think this is a problem, because the huge majority of CSS devs has no idea how the W3C process works and doesn't want (or need) to know. If they want to learn we should accomodate them, but I don't feel that learning about the W3C process is mandatory for the average CSS developer.

If someone delves deeply enough into the specs that they see that there's a mismatch between module levels and the idea of CSS4, I think they're advanced enough to be let in on the secret that CSS4 is just marketing.

An alternative to CSS4 now and CSS5 in three to five years would be an annual CSS2020, CSS20201 and so on, similar to what ECMA is doing. I do not think that this would be advisable. A three-to-five-year release cycle is more in line with educational needs. With a one-year release cycle it doesn't make sense to produce books and workshops about the new release, because by the time they're finished the next release is just around the corner and your book or workshop will seem outdated. A longer cycle sidesteps this issue.

It is unclear to me why an annual release cycle would be better. I'd like to ask proponents of the annual cycle to clarify the advantages they see over a three-to-five year cycle. (And for me, "being more like ECMA" is not good enough.)

It seems CSS developers also want to use CSS4 as a feature list, giving them guidance as to what browsers support now or will support in the near future. I feel this can be achieved fairly easily.

I think we should take the CSS 2020 snapshot, which I believe is being created right now, remove the features that were added to browsers before 2019, and put all remaining features on the "CSS4 feature list". This should be a fairly easy process for the WG, since the snapshot will be created anyway.

The WG should continue to operate as always: work on modules and create a snapshot once per year. It should not be forced to take on even more work. As far as I can see, adopting the CSS4 proposal would increase the WG workload only marginally, with two extra tasks:

1) Create a short blurb about CSS4, as well as the initial feature list as described above. This would be a one-time extra workload.
2) Update the CSS4 feature list by reviewing recommendations from CSS developers. I think this can be pretty much a rubber-stamp process, where a feature is rejected only if it's too old (say, implemented in 2018 or before), or there are serious other reservations from multiple WG members. This should be only a small amount of extra work (he said hopefully).

That's where I stand right now.

[rickgregory]

@troxler -As of ES6, new ECMAScript specs were released in a yearly schedule (i.e. there is one new version each year). Since 2015 they released ES6 (=ES2015), ES2016 (=ES7), ES2017 (=ES8), ES2018 (=ES9), and ES2019 (=ES10).

I'm not sure that's significantly less daunting. That's still five versions to track. Also, an annual version bump is missing significance information. Is ES8 as big of a bump up as ES6? If not, why do they have the same version level? Versioning like that puts the onus of figuring out whether a given version is important or not on the reader.

A major/minor/trivial system (4.0/4.1/4.1.1) avoids that - CSS4 is obviously major whereas 4.1 would be relatively minor - and also frees the working groups from having to designate a new version every year.

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. I used to get excited reading about some cool new CSS feature on @chriscoyier's CSS-Tricks site only to get to the end of the post and see that it worked only in Canary or something. That kind of information is useful to a degree, but it's also very valuable for most of us day to day devs to know that a feature is ready to deploy widely. Right now, we have no way of knowing that except digging on our own and consequently, we mostly don't know about new-since-CSS3 features unless they solve broad problems, e.g. grid.

@pp-koch I think we should take the CSS 2020 snapshot, which I believe is being created right now, remove the features that were added to browsers before 2019, and put all remaining features on the "CSS4 feature list". This should be a fairly easy process for the WG, since the snapshot will be created anyway.

Hmm. well the problem with that is CSS Grid would be excluded. I think a better way to do this would be to look at post-CSS3 features and bundle those into CSS 4. Not al features need to be 'on the box' i.e. major features about which we talk widely. But we don't want to confuse people who hear of CSS 4, see a major thing like grid missing and wonder if it's official or not.

It seems CSS developers also want to use CSS4 as a feature list, giving them guidance as to what browsers support now or will support in the near future. I feel this can be achieved fairly easily.

This also helps some people sell using the features to internal stakeholders.

[dontcallmedom]

fwiw, the CSS4 Community Group which @jensimmons proposed last week as “a group to debate and define CSS4” was created earlier this week

[SelenIT]

maybe it's too late for CSS4 and it should just skip to CSS5?

I had exactly the same thought recently. There are a lot of explainers why there will be no CSS4 and why it's incorrect to refer to Level 4 features as "CSS4" (often citing @tabatkins's classic post). But for CSS5, _there was no such explainer/warning about it:)_

Again, skipping number 4 isn't something new for web developers – we already had it with JS (ES3 -> ES5, skipping ES4 aka "Harmony" draft), also after almost a decade of seeming stagnation. And such a "double level up" would probably also fix the impression that CSS is somehow "behind" the latest HTML, and clear the new umbrella term from _any_ possible old wrong implication.

[Crissov]

CSS π then, since π > 3 and π ≠ 4.

ducks and runs

[29thfloor]

This is a great conversation to be having and I'm not sure which side I come down on yet. I agree that "CSS3", "HTML5" and "Responsive Web Design" being Things™ definitely helped convince less technical stakeholders that something "new" was happening and that they didn't want to be left behind.

I think among the web dev community things like Flexbox and Grid are generally pretty well known but I don't think they are seen as the same sort of new paradigm that CSS3/HTML5 were. One of the things that I think really helped with CSS3 in particular(at least among devs/designers) were sites like CSS Zen Garden that really showed off what you can build with these new features. I'm sure there are similar things out there now showing what you can do with Grid, Flexbox and all the other latest CSS features, but I don't think many people outside of the web dev community really understand how much has changed since "CSS3".

Something I'm especially interested in is the CSS Paged Media spec and the CSS Generated Content for Paged Media Module. At my company we use the CSS defined by these specs to generate very complex PDF documents. And now with an open source project like Paged.js, we have a really good polyfill for rendering "print CSS" in the browser.

I'm curious how much people know about this "print CSS" stuff and how it fits into this larger conversation.

[rickgregory]

@29thfloor - it's not just less technical people who are helped by labels like CSS4 etc but front line devs too. It defines a package of CSS features that are all ready for prime-time... which brings me to a point that seems under-discussed... implementing by browser vendors.

One reason CSS3 and HTML5 worked well is that they were fully or mostly fully implemented in browsers. I'm probably eliding some issues because it's been awhile but if a feature set is not only part of a CSSX release but that release is also coordinated with browser releases then we know we can use them in production. Sure, we can always use advanced features with partial implementation as enhancements, but the reality of client schedules is that often you just don't do the enhancement at all because it's extra work and testing that only benefits some smaller percentage of visitors.

That's one reason Grid was so successful at rollout - we knew that browsers as of a certain date all implemented I, we could see when those browsers became the vast majority of the traffic for a client and then we could deploy.

Large features like Grid will get enough buzz that most web devs will hear about them and they have a name which addresses the branding issue. What I'm concerned about are the mass of smaller but still useful features which don't get that level of notoriety and so many of us don't know about them and so don't use them even though they'd make life better.

[29thfloor]

@rickgregory So how do you coordinate a marketing effort like this that depends so much on what browser vendors choose to do (or not do)?

For this to be successful, I think it needs to focus more on defining what sets of CSS features are actually supported in some subset of (currently available) browsers/versions and less on trying to coordinate with browser vendors to all support a set of CSS features on a timeline that allows it to be "marketed" ahead of release. I would hope that this process would eventually encourage vendors to coordinate with whoever is defining these CSS "versions," but it seems pretty ambitious to think that it would happen right away.

And no matter how a CSS "version" is defined, it will still be up to the front line dev to make a judgement call on what version to use/support based on their particular audience.

[rickgregory]

For this to be successful, I think it needs to focus more on defining what sets of CSS features are actually supported in some subset of (currently available) browsers/versions and less on trying to coordinate with browser vendors to all support a set of CSS features on a timeline that allows it to be "marketed" ahead of release

That works too. What I was trying to say was that we don't want to define a CSS version as a set of features that isn't informed by what people can use in the wild. One way to do that is to coordinate with vendors. Another is to publicize a version when it's got a threshold of support, which is likely easier.

As for "_... it will still be up to the front line dev to make a judgement call on what version to use/support based on their particular audience"_ of course it will. But knowing that a feature has broad support is a way to know "Hey, I can probably use that..." and for front line devs to a) hear about it at all (most of us don't lurk on the CSSWG comms) and b) it differentiates between a features that has broad support and one that is some earlier stage of development and doesn't work in released browsers.

That's the main value of a versioned CSS release to me. It's a very public way of saying "This stuff is ready for broad use" vs "Here's some new stuff that might or might not work in the wild." That has value because it encourages us to check out the newer advancements in CSS and not simply use CSS3 plus a few widely known things without expecting us to keep up on the release and supported status of every new feature.

[j9t]

I’d think we’ve witnessed both how useful living standards are, and how difficult complex standards are to version. Personally I do not deem the (introductory) views shared convincing enough to switch course.

However, it seems the main argument revolves around marketing. I see a great many great developer experts around, but are there any marketing experts involved? Can or could proponents of the proposal solicit and cite expert views?

Also, are there data and metrics to support the “CSS 4” proposal? Empirically it seems “CSS”, just as “HTML”, turns out to be used quite sufficiently, and inherently more accurately, when used without a number. Can or could proponents add data that back up how their views would actually be beneficial for the field? *

Unless I missed something in this and other threads I think adding both outside views and numbers would help, a lot.

* Where did the term “CSS 3”, for example, actually turn out to be used in a way that was useful? Empirically, those who emphasized the “3” often turned out to know even less about CSS fundamentals (“1” and “2”), and therefore may have hurt our field more than they did good—to an extent where some of us took “CSS3” (and “HTML5”) on CVs as hiring red flags (!). This may constitute marketing, too, but perhaps that kind of marketing is not the one that’s desirable or intended?

[rickgregory]

I'm going to not comment that you make negative inferences without any data but want data for any positive arguments. It's an annoying debate tactic but...

Here's an interesting Google Trends chart for the terms CSS3, HTML5 and CSS Grid (perhaps the biggest new CSS feature of recent years)>

https://trends.google.com/trends/explore?date=all&geo=US&q=CSS3,html5,CSS%20Grid

[fchristant]

Very interesting discussion. I'm torn between opinions. On one hand, if it helps, why not?

Yet I'm not convinced that it will help. The main basis for this idea seems to be the success story of the marketing terms HTML5 and CSS3. Which are undeniable. But that doesn't mean it is repeatable. Those version bumps had incredible tangible value due to a unique moment in the web's history:

The web had huge compat issues. CSS2 to 3 finally meant saying goodbye to a myriad of layout hacks and browser bugs, and opened up responsive design. HTML5 solved tons of parsing/error conditions across browsers. We measured browsers using standardized ACID tests. The web moved in terms of months or years, not weeks. HTML5 as a term got further launched into the stratosphere by Apple effectively killing Adobe Flash, HTML5 being the alternative.

In other words, these version bumps had a dramatic impact due to underlying conditions that are unique, not because we did a +1 on the version number.

These historic conditions no longer apply. We're used to a modular, fast-moving web where browsers auto-update. There is no standardized major version test to measure against, nor do browsers implement based on such grouping of modules. Hence, developers think feature-based, not module or version-based. They use caniuse.com to check what works.

This doesn't mean a marketing version has no positive effect, I'm just saying the dramatic effect it had for CSS3/HTML5 is not repeatable, and therefore we should not assume such large success.

I remain open the idea, because any positive effect is a gain. However, I must agree with several others that major marketing versions only have meaning in a compat situation. If we announce that CSS5 is finally here, it must mean all major browsers have full or near-full support.

Without this compat condition met, I think some developers will be cynical, and return to feature or module based thinking, the current status quo.

Despite some of my skepticism, I want to express that in recent years, CSS has been extended with truly revolutionary features. Just grids alone is something people 5 years from now will still be exploring and learning, and 10 years from now, people will invent new layouts based on what this foundational technology makes possible. It's that extensive and powerful.

I very much agree that these incredible advancements have not gotten the praise, appreciation and awe that they deserve. More important, the techniques themselves are underutilized.

[rickgregory]

I'm not sure I understand this assertion

Yet I'm not convinced that it will help. The main basis for this idea seems to be the success story of the marketing terms HTML5 and CSS3. Which are undeniable. But that doesn't mean it is repeatable. Those version bumps had incredible tangible value due to a unique moment in the web's history:

in light of this statement.

Despite some of my skepticism, I want to express that in recent years, CSS has been extended with truly revolutionary features. Just grids alone is something people 5 years from now will still be exploring and learning, and 10 years from now, people will invent new layouts based on what this foundational technology makes possible. It's that extensive and powerful.

I agree that 2 to 3 was a jump of the magnitude that we may not see again. That doesn't mean versions have no benefit unless they are of that magnitude. It means we shouldn't use them will nilly (hence my off the cuff aversion to yearly numbers... some years might pass with little of significance meeting the combat criterion).

We're used to a modular, fast-moving web where browsers auto-update. There is no standardized major version test to measure against, nor do browsers implement based on such grouping of modules. Hence, developers think feature-based, not module or version-based. They use caniuse.com to check what works.

Well, we HAVE to. As I've said upthread, this model puts the onus on devs to keep up with each and every feature with nothing to differentiate between bigger, more impactful ones and minor, edge case features. You need to parse the firehose to try to get the former and not let the latter distract you. In practice, what I find myself doing is ignoring the firehose of new things and only paying attention to what bubbles up. That, of course, could just be me.

[keith0305]

I've talked to a very senior developer who had never heard of flexbox, 5 years after the fact. Not mastering it fully...fine. Not having heard of it? What!? It means actively ignoring pretty much any web development news for years.

While I agree that never heard of flexbox after 5 years is pretty bizarre, the purpose of this proposal isn't just for the developers to keep up.

I am a vendor for a large cooperation that insists on supporting IE10 even though statistics show very little (<0.5%) usage in my country. You will never believe what I saw when I visit their office – most employees browsing with IE on their machine in their own cubicle. I know what you are thinking, but NO, it wasn't because of IT limitation or company policy. In fact, they are allowed to use Chrome or Firefox. It was because THEY LOVE IE. They refuse to switch, granted most of them are in their mid-40s.

So back to the topic, 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).

[jcjolley]

Full stack engineer here, throwing in my support for CSS4, and ongoing versioning of CSS that bundles modules together into easily identifiable units. Being able to see "Edge, Chrome and Firefox all support CSS4.3" is conceptually easier than checking for support for each individual module and would encourage me to learn that set of new modules since I would then feel safe to use them.

Party due to this issue, I currently use SASS for just about everything these days because I have no idea what aspects of CSS after CSS3 are cross browser compatible.

[opllama2]

its been a couple of years since i actually tried to keep up with what's new, that said i really like the idea of having an official version upgrade to CSS, me personally use these versions(not only in CSS) to make checkpoints for myself as to what i want to study and keep up with since trying to keep up with each module individually can be a bit tiresome tbh.

[onnodejong]

I think this is an eat your cake and have it too moment. There is no reason why the standards body should not continue to work as it does and that a consortium of designers call the new stuff with a moniker that becomes more or less standard over time. This is how browsers implement CSS.

[catalinred]

Great pros and cons and thank you for this good read!

I loved most of the comments above and here are my thoughts on why I think CSS4 is not a good idea:

• <title>Can I use... Support tables for HTML5, CSS3, etc</title>
  This is the current Can I use title and I think you all agree it's far from a perfect title. But it in a way reflects the current confusion when it comes to the current namings: "HTML5, CSS3, etc".

• Suddenly, all the articles' titles in the wild: "How to do this and that with CSS4",

• In order to achieve better browser support for new CSS features, as @huijing mentioned above, we miss Babel compared to the JS ecosystem. Therefore, from this point of view, we can't expect CSS4 to gain the same traction as ES6 and so on.

• Authors would need to edit all the existing content on "CSS4 is not a thing that exists" or "There is no such thing as CSS4"

• It's hard to properly draw a line where CSS3 "stopped" and CSS4 "began". How about CSS5 and so on? Who will draw and maintain those lines e.g. which is where?

• Is it CSS 4 or CSS4? Because we already know it's HTML5 and not HTML 5.

• Usually when you're expecting a "marketing boom", rarely that happens without a good plan and proper execution. W3C is known for lots of good things but not marketing.

• As @j9t states above, and from my experience, it's true that sometimes HTML5 or CSS3 can be considered red flags when it comes to hiring. When reading a CV, I'm interested in proper HTML and CSS skills and I wouldn't like to see CSS3, CSS4, CSS5 listed as skills in the future.

---

I'm a fan of CSS.

[srsgores]

I'll chime in here as an instructor at Canada's leading, intensive coding bootcamp.

In short, me and my staff nearly unanimously vote in favour of the version bump to CSS4.

As programmers, we understand the importance of naming things. Adopting the name of "CSS4" does not limit what the CSSWG can or can't add to the spec; just like HTML and its newer, less-understood cousin HTML5.1 (arguably also due to marketing). Rather, the spec lives on as the working group deliberates the feature set finally offered.

CSS4 Feature Controversy

A more pertinent question becomes which newer features to include in the CSS4 spec. At Lighthouse, we don't have any _particular_ opinion on which features we expect in CSS4, but for marketing purposes, it seems apparent to us that the spec include, at the very least _parent selectors_. Again, the working group doesn't have to have finalized the nature of these features at launch to change the name.

Major Benefits

Easier to Understand

We believe the name "CSS4" makes understanding the "new" features included in its spec easier to understand.

In the same way that our students initially struggled with the EcmaScript Standards Committee's transition from "ES6" to "ES2015", "ES2017", etc., we foresee students struggling with comprehension of "new" CSS features vs. "CSS3", "just CSS", and "new" CSS features like custom properties and grid layout.

Easier to Market

Using the name "CSS4" allows us to easily convey a subset of features and allows for increased marketing to those who have limited knowledge of CSS features. Current businesses may see the need to "upgrade" due to the increased affixed version number.

Known Downsides

Too New

Having to teach hundreds of students with little to no programming background every year, myself and my colleagues have observed a lack of interest in "new" technologies; our students, whether due to the nature of the fast-paced course, tend to gravitate to the tools we teach them to use during the course (React, JSX, Ruby, Express, NodeJS). At Lighthouse, we fear that CSS4 may fall into this category -- especially if support lacks in evergreen browser vendors.

Incomplete

If browser vendors fail to add support for the new features encapsulated in CSS4, we expect a decrease in interest from our students -- also potentially leading to the exclusion of such material from our course. In short, CSS4 will need major evergreen browser support in order for us to include and teach it.

Let's Call it "CSS4"

At Lighthouse, we still feel that encapsulating newer CSS features in a featureset known as "CSS4" will ultimately benefit the community (including the education sector). We predict that in the event of an incomplete spec or lacking browser support, this will motivate browser vendors to hasten and to prioritize development and support. Ultimately, we understand that features evolve and change over the lifetime of their drafting in the working group, and we feel that the working group can accommodate the inclusion through marketing channels and through the community.

Let's call it "CSS4". 👍

[lazarljubenovic]

First it's decided that CSS will not be versioned as a whole in order to allow separate specifications to grow independently, and not wait for one other.

Now we'll have "CSS Grid Level 7 is part of CSS 5"? Sounds like a great idea! Let's confuse everyone! Why? So a bunch of recruiters could update their job offers from meaningless HTML5/CSS3 to a meaningless HTML5/CSS4, and so web designers on LinkedIn can get endorsement for a new trending CSS4.

Just drop the numbers already. It's CSS, an evergreen language. When someone asks you what's your primary browser, you say Chrome, not Chrome79. Your library of choice is React, not React16.3. The version number is useful for developers. It's a technical detail. After GitHub added actions, they were still GitHub, not GitHub4. When they update an internal library, they're still GitHub.

CSS is like a monorepo of modules. They advance through levels separately. That was the whole point of that decision. What exactly is the problem with it?

If I understood correctly (I obviously didn't read everything in the thread), basically the ain driving force behind this idea is "previously the name HTML5 helped push browsers". Yes, it helped push browsers from dark ages of ridiculous inconsistencies and lacks of specifications. Now we have specifications, and almost every browser is "evergreen", always updating and always growing.

So what exactly are you solving with incrementing a number which we previously agreed to get rid of so the language can advance faster?

[axelboc]

I think introducing CSS4 as suggested would be a major step backwards for the web community.

Books based on specific versions of web specs are a thing of the past because the web moves too fast for them. Going back to this model would be doing publishers, schools and novice developers a disservice. Training models need to adapt to living standards, not the other way around. This is already happening in the form of living online books, training courses with regular updates, ... so why go back?

---

I do agree that something's missing though.

These days, the way I learn about new CSS and HTML features is by reading browsers's releases notes. If I miss one, I'm screwed.

In contrast, I learn about new EcmaScript features thanks to the TC39 Committee's yearly release process, which provides the community with regular opportunities to write blog posts that list exactly what's changed in the spec.

Selecting a number of CSS Modules at various levels, saying that this is what CSS is at this point in time and giving it some name (CSS4, CSS 2020, whatever) is utterly unhelpful when it comes to keeping up with changes.

What TC39 got right is granularity. It's not the editions of EcmaScript that go through stages, it's the _proposals_. When a new version of the spec is released each year, I just skim through the various proposals adopted that year and I'm up to date.

Unlike EcmaScript, CSS is a set of specs, so what I propose is to bring this level of granularity down
to CSS Modules. Learning that CSS Fonts Level 3 has achieved _Recommendation_ status tells me nothing. Learning that a specific proposal has reached maturity and been integrated into CSS Fonts, now _that's_ useful.

Once this level of granularity is in place, the yearly release train comes nearly for free as a way to solve CSS' marketing troubles. _CSS Fonts 2020_ becomes the reference point for all the proposals adopted that year into the living CSS Fonts Module, and _CSS 2020_ can just be the collation of all the adopted proposals.

[JoshuaLindquist]

I've had more time to think about this idea, and my thoughts are evolving. I am still overwhelmingly in support of doing _something_ to make new CSS easier to discover, learn, and understand.

>

In order to achieve better browser support for new CSS features, as @huijing mentioned above, we miss Babel compared to the JS ecosystem. Therefore, from this point of view, we can't expect CSS4 to gain the same traction as ES6 and so on.

I don't think better browser support is really an issue right now. There are many features of CSS that are already implemented in all modern browsers (and have been for years) that would likely be included in the CSS4 proposal. Considering the rapid pace of browser development, I think it would be beneficial for any CSS4 (or 5 or 6, etc.) proposal to _only_ include features that are already implemented in at least two rendering engines.

This would differ from CSS2/3 where the browsers were left playing catch up. Since CSS4 is about marketing, we really don't need to use it to pressure the browsers at this point. We need to use it to advertise the features that are already available that many authors are not currently using.

>

Authors would need to edit all the existing content on "CSS4 is not a thing that exists" or "There is no such thing as CSS4"

I don't think this is a compelling argument. The web is littered with outdated articles on any number of topics. Some authors might choose to add a disclaimer to outdated articles - and maybe we want to encourage that for articles written by members of the working group (e.g. Tabatkins article that was previously referenced) - but that's an exception more than a rule. Most websites didn't remove or update all of their articles from the CSS2 era about how to add rounded corners on boxes before border-radius. Those articles just exist forever.

>

It's hard to properly draw a line where CSS3 "stopped" and CSS4 "began". How about CSS5 and so on? Who will draw and maintain those lines e.g. which is where?

This is definitely one of the topics that will need to be discussed. But my understanding (and I could be wrong) is that CSS3 began when the specification was modularized. Existing specifications were given "Level 3" at that time. I think everything that began modularization at Level 3 is a part of CSS3. Anything that came afterward (either Level 4 of those same specifications or new specifications that started at Level 1) would be under consideration for inclusion in CSS4, etc.

>

A more pertinent question becomes which newer features to include in the CSS4 spec. At Lighthouse, we don't have any particular opinion on which features we expect in CSS4, but for marketing purposes, it seems apparent to us that the spec include, at the very least parent selectors. Again, the working group doesn't have to have finalized the nature of these features at launch to change the name.

I think @srsgores demonstrates a legitimate issue with the name CSS4 or creating a new designation at all, but it all boils down to communicating intent. While in favor of the idea, srsgores quickly asked that CSS4 include actual new features that do not exist in any spec at the moment (in this case, parent selectors/container queries). My immediate understanding of this proposal was that the actual intent is to package features under a new name and say "Everyone, this stuff is ready for primetime!".

When discussing authors that do not keep up with the latest developments, I think this approach will be simple to understand. Everything will _feel_ like it's brand new to them, even though some of these features, like Grid and Flexbox, have been in browsers for years.

But anyone who does keep up will likely be confused about why there is a "new" specification full of things that are actually old.

I think this is a solvable problem. It's just something to be aware of.

>

Now we'll have "CSS Grid Level 7 is part of CSS 5"? Sounds like a great idea! Let's confuse everyone!

Just drop the numbers already. It's CSS, an evergreen language. When someone asks you what's your primary browser, you say Chrome, not Chrome79. Your library of choice is React, not React16.3. The version number is useful for developers. It's a technical detail.

If I understood correctly (I obviously didn't read everything in the thread), basically the ain driving force behind this idea is "previously the name HTML5 helped push browsers". Yes, it helped push browsers from dark ages of ridiculous inconsistencies and lacks of specifications. Now we have specifications, and almost every browser is "evergreen", always updating and always growing.

First, it's important to reiterate that no one is suggesting that the modules be removed. This is purely for marketing. The way CSS advances would not change.

The driving force is not to push browsers - it's to help authors understand what is ready to use. Browsers have already implemented important new features, but it's difficult to keep up with what is ready. Most authors do not read the specifications or stay up-to-date with the efforts of the working group.

As @axelboc mentioned, the easiest way to learn about new features in a browser is to read the release notes (I do the same thing), but how many people are really doing that? And why should that be the way you figure out what is ready?

I also think the potential confusion about Module Levels vs. CSS# is overstated. I would argue that the average author doesn't know the modules exist at all, and most people that do work with and follow the modules don't really need to care what ends up with the "next version".

Books based on specific versions of web specs are a thing of the past because the web moves too fast for them. Going back to this model would be doing publishers, schools and novice developers a disservice. Training models need to adapt to living standards, not the other way around. This is already happening in the form of living online books, training courses with regular updates, ... so why go back?

I would label most or all of these things as "unfortunate side effects" or "necessary evils". I agree that we should encourage teaching the living standards and training models should (and possibly have) adapted, but what about all of the authors who are already trained?

I think that's the big concern behind this proposal. There are a lot of people already out there who have written CSS for many years, but that cannot keep up with living standards while also developing full time. How do we let everyone know that there is something new to learn? How will they determine that those new features are worth learning?

I do agree that something's missing though.

In contrast, I learn about new EcmaScript features thanks to the TC39 Committee's yearly release process... that list exactly what's changed in the spec.

Selecting a number of CSS Modules at various levels, saying that this is what CSS is at this point in time and giving it some name (CSS4, CSS 2020, whatever) is utterly unhelpful when it comes to keeping up with changes.

What TC39 got right is granularity.

Unlike EcmaScript, CSS is a set of specs, so what I propose is to bring this level of granularity down to CSS Modules. Learning that CSS Fonts Level 3 has achieved _Recommendation_ status tells me nothing. Learning that a specific proposal has reached maturity and been integrated into CSS Fonts, now _that's_ useful.

Once this level of granularity is in place, the yearly release train comes nearly for free as a way to solve CSS' marketing troubles. _CSS Fonts 2020_ becomes the reference point for all the proposals adopted that year into the living CSS Fonts Module, and _CSS 2020_ can just be the collation of all the adopted proposals.

I generally agree with this. Another important thing to note about the CSS4/CSS2020 idea is that it's all completely up-in-the-air. There's no consensus on exactly what it is or should be, and I would argue that it should be something similar to what you have suggested.

The biggest problem is that the initial release may be monstrous in size because it's been so long since "CSS3". After that, I think annual releases would be reasonably sized (or the discussion could move back to releases every 2 or 3 years if larger releases are preferred).

On that note, after having several days to think about it, I greatly prefer the idea of using years instead of version numbers.

I think @axelboc has it right by suggesting that the new version/specification include very specifically what has changed. However, I think it should ignore the typical W3C recommendation status completely (or mostly). Instead, I think it would be better to include only the features that have been implemented by two rendering engines and are no longer behind flags. This would give authors a realistic list of features that are actually ready to use, even if the entire specification has not reached Candidate Recommendation.

[phoenixrizin]

Adding my 2 cents to this, as I love the conversation around it both from development as well as marketing. I like the Idea of a CSS4, etc. not just because it creates a grouping of technologies to focus on, but also creates almost a history of why those things came about. For this reason, I think the best point for the split in my mind is Flexbox.

HTML5+CSS3 is where 2 important changes happened for the web. First, Media Queries gave the gift of covering multiple screen sizes with different layouts as users moved towards mobile, rather than previously where we expected the usual rectangle and saw a page like a "folded newspaper" (1024x768 will be forever imprinted in my brain). The second change was the combination of native video in HTML and CSS Animation/Transitions rendering third party plugins somewhat obsolete.

Flexbox, and later Grid, belong in the next phase: completely fluid layout. We're moving well past the days of memorizing a set of common sizes. Flexbox was also the first time I thought "I don't know if this is going to pan out in Internet Explorer." So in a way, flexible layouts were a big reason to actively start moving away from the last major non-evergreen browser.

So for me, CSS4 is Flexbox, Grid, and anything that either developed because of it, alongside it, or after it, especially if full support came post IE. Whether versioning should continue afterward or CSS4 should be "the last CSS version you'll ever wear" is a different story.

[LeaVerou]

I'll chime in too, in support of a CSS 4 umbrella, and even a CSS 5 one too. Or a year-based one, like ES. Anything, as long as it's a single, marketable number (or even word, like OSX versions, that'd be fine too!).
Yes, it's entirely marketing, and that's fine. That's what propelled CSS 3 forwards, and there was no such thing either. People need a term to put on their CVs, otherwise it's less attractive to them to invest time in learning the technology. People need a buzzword to convince their managers. I disagree with Rachel's point that this implies that specs are ready. CSS3 gained traction far before the specs were ready, or even in decent shape!
I don't think it's confusing to have a language version and module versions. Think of it this way: Software consists of packages and has versioning that is separate from the versions of its packages. Perhaps we can see it similarly?

[j9t]

I’ll renew a point made earlier, if “CSS 4” is a matter entirely about marketing, has anyone discussed this with domain experts? It could help evaluate the hypothesis and add value to the conversation. (I don’t think this is on those who oppose the idea of “CSS 4,” then, though we could also ask around and share views from marketing SMEs.)

[chriscoyier]

has anyone discussed this with domain experts?

I think a lot of people in here _are_ marketing experts, even if they don't self-identify that way. Marketing to developers requires some developer-to-developer authenticity, and y'all got that.

[rachelandrew]

I wrote this up with a bit more background context for Smashing Magazine, thinking we might have a slightly broader audience for comments.

[29thfloor]

has anyone discussed this with domain experts?

I think a lot of people in here _are_ marketing experts, even if they don't self-identify that way. Marketing to developers requires some developer-to-developer authenticity, and y'all got that.

I don't know if I would self-identify as a marketing "expert" but I do have experience in that area. I'm a designer/developer with several years of marketing agency experience.

I agree with @chriscoyier that this will require a more developer-friendly approach than your average marketing campaign so the feedback here will certainly be useful.

[nicoseijas]

I don't think this is something about purely marketing strategy, but a way to make a statement to the world: "Yes, we are actively working on CSS. We have new tools you can work with, check them out".

[Drewpeifer]

As a current developer, I am most interested in seeing:

A) A list of stable features presented in a relatively easy to understand structure, with option to deep dive (the team expert should not be the only one who can read the documentation)
B) That list should be documented and hosted by an authoritative organization / site (a github repo's README is semi-authoritative to devs, but not to anyone else)
C) Any best-practices determined by the authoritative organization / site should be glaringly obvious in their UI presentation (no excuse for ignoring them)
D) A clear list of the advantages of using these features / practices, and the perils of not doing so (crucial to bridging the gap from dev team to business team, it should not be on Joe Developer's shoulders to summarize and sell the entirety of CSS4 in a 30 min meeting)

As a former analyst, the above items are what I would have needed in my hand to take to leadership in order to convince them that we needed to take action regarding an upgrade, patch, or defining new practices. If any of these elements were missing, especially D, I think they would have likely interpreted it as a "developer want" instead of a "product need", and that's where the issue would have concluded.

[brunoais]

developer-friendly approach than your average marketing campaign so the feedback here will certainly be useful.

Developer here:
In my case, I prefer having some means to know when mainstream versions of mainstream browsers already picked up a certain feature and that feature should be stable.
For example, in JS, there was a shadow DOM v0. I don't want advertisements to ES about shadow DOM v0's because it can be killed, just like it was. Currently, I'm making sure that shadow DOM v1 won't be killed too.
With CSS, if a CSS feature is around for people to try and understand the mistakes in the design, don't advertise it as part of a CSS version. Instead, advertise as a CSS experimental or beta or canary or alpha.
I'm in favor of unstable versioning more closely related to semversioning than how ES is doing.

This versioning method is intended to use only the major and minor numbers. I'd use the following ideology:

1. Major version number changes when something believed to be a big deal or game changer. Usually something that required major javascript hacks to work (which probably didn't always work) and/or are too complex to be implemented reliably as polyfills or shims.
2. Minor version changes when a set of welcome features are released. These are usually some new attribute values or a small set of cosmetic attributes people will feel pleased to use because, due to them, less "HTML hacking" is required to get things done.

Examples:

1. Example attributes for 1: display: grid display: flex (alongside: grid-template-*)
2. Example attributes for 2: position: sticky scroll-snap-* text-underline-* display: flow-root
   Or the selectors for 2: >> :placeholder-shown :indeterminate :blank

Opinions/comments?

[JoshuaLindquist]

1. Major version number changes when something believed to be a big deal or game changer. Usually something that required major javascript hacks to work (which probably didn't always work) and/or are too complex to be implemented reliably as polyfills or shims.

2. Minor version changes when a set of welcome features are released. These are usually some new attribute values or a small set of cosmetic attributes people will feel pleased to use because, due to them, less "HTML hacking" is required to get things done.

This sounds very hard to do as a way to number the releases. I don't know if it would solve the current concern of CSS feeling slow-to-change or needing a marketing push.

Among your own examples, you have separated the same property into different types of versions with two values of display falling into # 1 while another value of display is considered # 2.

I like the idea of focusing on specific features instead of complete specifications. It just seems hard to separate them all into different buckets of "importance" (which is subjective).

[brunoais]

Good points, @JoshuaLindquist . Without much thinking, it appears to be good... It is good for developers. On hindsight, many times, it's hard to define whether a feature is that game changer or not. I thought the "believing to be" a game changer could help but maybe it is still too hard...

[benfrain]

I've gone back and forth on this in my mind. I think I am settling on no version numbers. Here's why:

I think the versioning of prior versions of CSS has produced a very long tail of expectance in the casual developers mind. From my own point of view, I'm finishing the 3rd edition of a book that first came out in 2012 and the title is still (as I write this), 'Responsive Web Design with HTML5 and CSS3'. Those numbers that once made the book feel fresh, now arguably date it, despite it being incredibly up to date in terms of content.

Should it be renamed 'Responsive Web Design with HTML5.3 and CSS4'? And then renamed for the next edition to whatever the most future sounding version numbers are? I can see how that might seem useful/desirable in the short term but is it sustainable? And ultimately, is it just more confusing for the beginner? Therefore I'm erring towards, "Responsive Web Design with HTML & CSS".

I think we (any CSS developer) just need to continue the process of explaining that in CSS land, there are no version numbers. Features are simply specced and implemented, and not necassarily in that order. A CSS Developer, as standard, should always consider the support for said feature before implementing.

[tzi]

@benfrain Thank you for your message. I think this is the heart of the discussion we should have about a possible CSS4. Name a book is a marketing choice, and it is for developers that do not read the specifications or CSS tricks regularly. I disagree with your conclusion, so I would try to resume my point of view about it.

When I see a book with the title "Responsive Web Design with HTML5 and CSS3", my mind translate it to "HTML and CSS from 2012".
If we really think that there is no version numbers in CSS, we should simply name our book "Responsive Web Design with HTML and CSS" (which I prefer personnaly). But people could translate it to "HTML and CSS from the 00's", so we don't.

For speaking with editors, they liked to have a CSS4 to show that their books are up to date. And people would buy it to discover the new shiny things that are inside, even if they already bought a CSS book in 2012.

[lazarljubenovic]

But people could translate it to "HTML and CSS from the 00's", so we don't.

Where's this coming from?

I don't see any of these books mentioning the specific version of Git, and I never saw anyone complaining why the version number isn't specified in the title. These kinds of books, if successful, eventually get a new edition, where they explain that "it's been revised for Git version 2". Even the most clickbait (readbait? buybait?) titles like "Teach Yourself C++ in 21 Days" don't have a version number in the title.

Somebody who has literally no idea about web design won't really know the difference between "CSS", "CSS3" or "CSS4". The numbers can only cause confusion at the entry level, where it literally doesn't matter which "version" you're learning. The reason why CSS Modules work as separate specs is that you can learn about CSS itself and then ignore certain features that you don't care about at the moment. Then, you can learn about them too. "CSS4" doesn't show that the book is up to date -- it uses a cheap ploy to trick people into the usual "bigger numbers means better and newer".

This is an evergreen technology. No book is up-to-date even a few months after publishing. A book about development should teach people how to use the documentation and how to be up to date with such technologies. Furthermore, having numbers in the title locks you down. "Learn ECMAScript2019" would already feel outdated to someone who doesn't understand that ECMAScript2020 isn't anything much different. Teach people what the version numbers are for, teach them how to remain up-to-date, show them how they can follow the progress of the technology. Stop praying on a layman's (mis)understanding by splashing a number to the title.

[onnodejong]

I still think this is a have your cake and eat it too moment, but can see the arbitrariness of the version number naming scheme and the mess it could turn out to be a few versions down the line. Why not append the year to the spec? Not HTML5 & CSS3 but HTML & CSS 2020? No need to do it every year, but when it feels right to enough to people who matter, then create HTML & CSS 2020.

[Crissov]

A book about “HTML and CSS from the 00s” would probably use XHTML. ;)

“HTML5” means anything after Hixie/WHATWG took over, and likewise “CSS3” means anything that came after modularization of the specification (also mostly post Hakon Wium Lie and Bert Bos).

[awford]

For developers building internal web applications, we are frequently locked into much older browsers, meaning no need to frequently check for new standards. I stopped looking after CSS3 came out. With no version number to tell me something has changed I have no compelling reasons to look for a new standard. Too much to stay on top of. If a CSS4 book showed up somewhere I would simply know it was ready for study. I've seen many discount this as "marketing". What product isn't concerned with marketing? What is the point of putting all this work into new standards and features if there is no clear way of announcing their availability? For that matter, what is wrong with sub-versions? If 3.1 supports flexgrid and 3.2 adds in "gaslight marquees", that's definable.

Obviously, I'm not heads down in the WG, but to stumble onto this discussion is both surprising and concerning. From the outside looking in it sure seems like beaucracy is winning what should be revision management 101. Maybe a new W3 standard for version control is what's called for instead, because this is the kind of mess a standards body was meant to avoid.

[awford]

Side note: "CSS 3+ Just Keeping Up" doesn't work well on a resume skillsets list. It doesn't say anything. CSS4 is a definable threshold when looking to hire specific skills. Version numbers affect so much more that the technical standards. Until I stumbled onto an article about this discussion I was unaware there had been progress since CSS3 or that versioning had been dropped. That's a failure both on my part and on the CSSWG's part. I'm unaware of anything in development more useful than clear revision and release communications. You could add a ton of features and fixes but without adoption it seems like a great deal of wasted effort.

[awford]

I wrote this up with a bit more background context for Smashing Magazine, thinking we might have a slightly broader audience for comments.

Thanks, your article is what brought this to my attention

[rickgregory]

With all due respect to @benfrain and other authors, the issue of book titles is entirely secondary. If you choose to add a version into the title, that's your (or your publisher's) problem and thinking that CSS should or should not use versions because of the effect on such things is "tail wags dog" land.

The heart of the matter to me is this - CSS adds things continually. Some of these are very minor edge cases. Some are major additions. Some are in between there. Right now, working developers have no organized way to track these additions and their support status. We might run across something by accident, think it sounds cool and find it's widely supported. Or find that it's Chrome only. Or... well you get it. Because of this, I think there's a lot of good CSS features that aren't getting the use they could get because most working devs simply do not have the time to haunt the WG's communications and there's nothing like a clear, organized feed summarizing new features and how widely supported they are.

Versioning is about two things. One, letting practitioners know what features both exist and are broadly supported in current browsers. Two, communicating to the edge players (designers, product folks, managers) that there's a new bag of features that it's safe to use. IF the WG and others want their work to be used widely, some kind of versioning will, I think, help that. Otherwise you have people working very hard to push CSS forward and seeing that hard work reach only a fraction of its potential audience.

[bkardell]

Not trying to discourage discussion on this issue but just to mention again, as it is obscured by comment collapsing now, that a wc3 cg was formed to discuss this topic exclusively

https://www.w3.org/community/css4/

Looking at the group and the associated mailing list I don't see any of these comments being brought over there so I'd like to make sure people are aware that it exists, has a mailing list, anyone can join, etc...

[fchristant]

@rickgregory

"I think there's a lot of good CSS features that aren't getting the use they could get because most working devs simply do not have the time to haunt the WG's communications and there's nothing like a clear, organized feed summarizing new features and how widely supported they are."

I don't entirely agree with this premise. I do agree that there's CSS parts that are not known well enough and therefore are underused, which indeed is a waste.

Yet I don't agree that this is due to a lack of tools to get to this information. Subscribe to any of the top 5 front-end newsletters or main web development blogs and it's impossible to miss what is going on with CSS. Spend the bare minimum of 30 mins per week and one will know what's going on. You won't master each topic, yet you will at least be aware that they exist.

When developers don't bother to use these channels, it may be due to other reasons. A general lack of interest/passion, being unaware of them (which means they didn't even try), or taking the very popular JIT approach to web development.

What I'm saying is that a well written, well organized CSS4 resource certainly won't hurt, yet the idea "build it and they will come" seems naive to me. There are already a ton of excellent educational sources out there. If these currently fail to reach a particular audience, I don't see how another new one would change that. Based on a version change only.

[benfrain]

I don't necessarily disagree with @rickgregory sentiments. I do however, think it is perhaps idealistic.

That approach was largely the way CSS3 went down. And it was not without problems.
The state of things being 'ready' or not was no different when we were all saying 'come and try CSS3'. You still had to check support, weep, and create workarounds for any semblance of cross-browser compatibility — and deal with vendor prefixes for extra fun ;)

Perhaps I am being overly cynical but saying it is CSS4, CSS5, CSS2020 etc is unlikely to change the reality of how these things are implemented. Stick what you want on a roadmap and give it a name. Even get all browsers to agree to it, but I don't think it is going to change the way 'the sausage gets made'. If a feature suits the business needs of one browser but not another, you aren't going to see it implemented. And that leads to 'CSS4' failing in the eyes of devs because 'you can't use it yet'.

I'm not saying that's good but I do think it is the reality we live in.

Things from the W3C side already get announced and updated on the W3C CSS homepage: https://www.w3.org/Style/CSS/Overview.en.html

There is an RSS feed too that's worth subscribing too. I know it's not widely circulated but there are means to stay officially up to date from a W3C point of view.

If you want more noise making about it then we all need to start making books with 'CSS4' in the title ;)

[benfrain]

@bkardell Hi Brian, sorry for the naive (genuine) question but what does joining that offer that we don't get here?

[bkardell]

@bkardell Hi Brian, sorry for the naive (genuine) question but what does joining that offer that we don't get here?

As I understand it, this is where such decisions and definition would happen. Since it references this issue as the start, and many of the people on this thread have joined.. maybe all of this is findable and it's fine? But a cg let's this group organize, collaborate, create documents, and have a bunch of infrastructure, like a blog and a mailing list and so on. There are other benefits for other problems (like IP related stuff) but I don't think they apply much here given the scope.

[peppergraphics]

Please consider students learning CSS. The textbooks for them still focus on old layout for desktop. We know phone visitors rule but the old texts still dominate college courses. If we want a creative new generation moving our industry forward then give them a label and courses to study it.

While we professionals can discuss it for hours, we leave students in the dust of our old horse paths. I’ve been teaching this new stuff in college now for five years including the switch to grid a few years ago, but if we can’t label it then it is buried as a new chapter in the middle of old books. Doesn’t the next generation deserve better?

Make students leap forward to the new techniques as the new default please. The newbies in the field are still “floating” down a very old stream. Please provide for identified growth for them to learn.

[rickgregory]

Yet I don't agree that this is due to a lack of tools to get to this information. Subscribe to any of the top 5 front-end newsletters or main web development blogs and it's impossible to miss what is going on with CSS. Spend the bare minimum of 30 mins per week and one will know what's going on.

The problem is 1) You need to know about those 2) you need to scan through the articles about other stuff if you just want CSS news (although you should probably keep up to date in general, of course) and then there's this... I see a lot of things touting a new CSS feature. I think it's cool. I read about it... and find out that it's supported in, say, Chrome Canary. What do I do? I shelve it because I have (literally, atm) 3 clients who need work done. This isn't theoretical, I run into this with some regularity on CSS Tricks for example. A writer covers a new features, does a great job outlining how it works etc... then at the end of the post, I find out it's supported in almost nothing.

Unless it's a major feature, a new CSS feature is unlikely to get a lot of mention on release, too. Something like CSS Grid was all over the place when it got support but most features simply will not get that attention.

@benfrain - the fact that CSS3 had problems is not an argument to not do versioning, it's an argument to ask if those problems were significant and, if so, how to avoid them. One easy way is to only include features in a versioned release that have a certain level of support in released browsers. Other features would continue as is and we could use them or not depending on needs. As they get browser support, they drop into a future version. This approach would argue for a yearly update... CSS[YEAR] is everything that in the last calendar year has been added and has support in some threshold level of browsers (FF/Chrome/Edge/Safari?).

Things from the W3C side already get announced and updated on the W3C CSS homepage: https://www.w3.org/Style/CSS/Overview.en.html

Relatively few devs are going to see that, I think we all know that.

There is an RSS feed too that's worth subscribing too. I know it's not widely circulated but there are means to stay officially up to date from a W3C point of view.

Emphasis added... :)

Trust me, after 30 years in software, I'm not naive about anything having to do with products. I get that browsers won't support everything or even, perhaps, most things. I just don't feel the current system works well for the average working developer.

[fchristant]

@rickgregory

"The problem is 1) You need to know about those"

True. Which would also apply to any new CSS4 resource. Realistically, we have to accept that some developers don't even take the minimum effort to stay up-to-date. It's not exactly hard to find good web development resources.

"2) you need to scan through the articles about other stuff if you just want CSS news"

Fair enough, if really a problem, I just found a CSS only newsletter in about 5 seconds. If such minimum effort is too much, I have little hope people will find (and read) a structural CSS4 resource.

Finally, I very much agree with the rest of your comment. CSS4 without compatibility is meaningless. A version has to be more than just a grouping, it has to work.

[rickgregory]

@rickgregory

"The problem is 1) You need to know about those"

True. Which would also apply to any new CSS4 resource. Realistically, we have to accept that some developers don't even take the minimum effort to stay up-to-date. It's not exactly hard to find good web development resources.

Sigh. The entire point of a version is that it would get more attention than a single feature. Come on.

"2) you need to scan through the articles about other stuff if you just want CSS news"

Fair enough, if really a problem, I just found a CSS only newsletter in about 5 seconds. If such minimum effort is too much, I have little hope people will find (and read) a structural CSS4 resource.

This is dangerously close to being arrogantly dismissive. Don't go there. It's not productive.

[JoshuaLindquist]

The current discussion all circles back to @jensimmons original post. This is about marketing. We can define CSS4, but that's not enough. We also need a plan to promote it.

Discoverability of existing resources is a problem for many reasons (as noted in this issue), but none of those resources have some kind of momentum to build around. CSS3 had that kind of momentum (or excitement) around it.

I don't know if we can replicate it - times have changed and the general situation is very different - but that's what it all comes back to. We need to define CSS4 and also make a marketing plan. That's what the CSS4 Community Group is for - this idea is bigger than this issue.

[fchristant]

@rickgregory There's no need to sigh, you can just disagree with a point.

No, I don't believe a version number automatically generates a substantial amount of additional attention as the historic conditions in which this did work (CSS3), don't apply today. So I consider it a hope, not a fact. Feel free to disagree.

I don't see what is dismissive about my take on learning resources. There's a wealth of free, high quality learning resources and they are at your fingertips, mere seconds away. Anybody that wants to stay up to date on CSS, can do so.

People that fail to make use of all this accessible material may not do that for various reasons: lack of interest, no time, whichever other reason. Regardless of the reason, they somehow don't. I simply translate that inconvenient truth to any other new publication one may invent. Not to dismiss the effort, instead as a reality check.

What you call arrogance is my take on protecting community leaders from spending a giant effort, that surely will include unpaid labor, on an idea that may not work or may not be as successful as hoped. A concern much better explained by @rachelandrew

Such a negative scenario (a lot of work without much impact) is unwanted, doesn't mean it's unrealistic. It doesn't dismiss the idea, it's being critical of an idea. Hardening it. Important difference.

[TimVevida]

Something I am missing in this discussion of using version numbers or not, is: what is the perspective of the web browsers? A lot of things are happening in the W3C working group, but how do I know what to use and what will be implemented soon? If feature A is not available now, when will it be?
If some kind of versioning helps to focus the browsers efforts on making a feature available in all browsers, I'm all for it.

Currently, it is not clear to me at all how browsers decide what to build and what gets less attention. Maybe that information is available somewhere, but then it is spread out over the different browsers backlogs. A common overview of which spec is being worked on / is completed by every major browser would be very helpful.

[JoshuaLindquist]

Currently, it is not clear to me at all how browsers decide what to build and what gets less attention. Maybe that information is available somewhere, but then it is spread out over the different browsers backlogs. A common overview of which spec is being worked on / is completed by every major browser would be very helpful.

The best all-in-one resource for this information is probably caniuse.com. The browser support charts are the most obvious feature, but if you look at the notes and resources below the charts, you can often find links to each browser's platform status.

A random decent example is the Caniuse report for initial-letter: https://caniuse.com/#feat=css-initial-letter. The resources have links to platform status for Webkit, Firefox, and Edge (though Edge will not really apply anymore).

It's not as simple as an official document noting the plans for each browser, but I think that's unlikely to be handled by the CSS Working Group. It would be an even greater task than CSS4 would already be because it would require constant communication with the browser vendors about roadmaps for implementation - which are subject to change for any number of reasons (even as mundane as the assigned engineer became ill).

[XorAndre]

They should have made it clear since the beginning of the development of CSS that such numbers mean version control. We can see that many developers are waiting for something from another world that will transform the entire reality of the web, but it will not happen in the way that they think. It may be that tomorrow new features will be increased, but it does not mean that it is a new technology. At this point, in addition to the crisis with CSS, there is still one with HTML, about "HTML6".
Marketing has been stumbling a little in the way of spreading the technologies to developers.

[Kaffesumpen]

With versioning it's easier to keep track of all the new stuff that comes a long.
It's easier to talk about to other developers.
It's easier to check off that I know all there is to know in a certain release.

[laukstein]

There was a reason why the versioning of HTML and CSS was dropped. We should stuck to it, and apply this consistency to all specs.
Imagine old issue of sniffing browser version... someone might relay it to CSS versioning falling into issues because spec changes. Now we instead use feature support check, same for CSS and JS.
I think for marketing you can use year, like "CSS new specs in 2020".

[XorAndre]

The structure could be redone in a way where growth is more organized. Even though I know that CSS takes time to come up with new features, something like this would be interesting: CSS-level1.1994 ... CSS-level4.2020, in this example I used the idea of ​​Laukstein.

[Nixinova]

I agree with the points OP raised, and think this should go further. It's quite haphazard how different CSS properties are supported at different times -- I think CSS should go the way of EcmaScript and have yearly releases with batches of new content in each. New ES editions get a lot of coverage, and this would help developers know what properties are supported and what is new. It's also much easier to remember (e.g.) "aspect-ratio was added in CSS2020" than "I think aspect-ratio is supported in most browsers now?". Having a set release schedule would help browsers reach more consistency in which features are supported -- if the CSSWG announced in, say, January what features would be exiting their drafting stage in that year, browser devs could (hopefully) coordinate releases.

[lazarljubenovic]

"aspect-ratio was added in CSS2020" than "I think aspect-ratio is supported in most browsers now?"

These are not mutually exclusive. Many ES features are available early, and some ES features of previous years are not yet available. "Modules are ES2015" didn't mean that they were available in 2015. It took several years to get them in all browsers. Tail call optimization is ES2015 and it's not available anywhere. Before switching to Chromium, Edge was missing a lot of well-known symbols introduced in ES2015.

So using "ES does it!" as an argument doesn't really make CSS2021 sound good at all.

If you want to be up-to-date with CSS, having a trailing year or a trailing version number in the standard name won't matter to you. Naming it "CSS Color Module Level 4" at least doesn't bring a false promise of a year. With ES, you still wait for the actual announcement from browsers to tell you that a ES2021 is available; you don't check the calendar to see if you can use something. With CSS you do the same.

[Nixinova]

What I mean is that you'd know which features are part of which version; features in "CSS2020"/"CSS4"/whatever would (mosty likely) have been implemented by 2021, so it would be much easier to figure out which properties etc are applicable and relevant. Browsers could just say "We support 'CSS2020'/'CSS4'/whatever now!" making it a lot easier for developers know what has been implemented, because otherwise you have to keep jumping to caniuse.com and looking at the mess there.

[lazarljubenovic]

They can say "We support CSS Color Module Level 4 now!", then six months later they can say "We support CSS Grid Module Level 2 now!". If these two were both grouped under "We support CSS4 now!", we'd wait six months for both (and we have even less information about what's new from just the name).

I still fail to see how would grouping things into larger chunks instead of smaller chunks make it easier to find a specific thing, both in the spec or caniuse.

[XorAndre]

If we are going to analyze it in depth, versioning control should be rewritten in the initial version of CSS3. Unfortunately it turned into a certain confusion and this made the imagination of many devs to create a calendar of something new and unique for each released version of CSS, we will not have another birth of style sheets. For the coming of CSS4 (new tool), I would have to make a new design and think much beyond CSS3.

[JakubKubista]

As Rachel Andrew mentioned in her article Why Are We Talking About CSS4?, that CSS5 is finally here, then it must mean all major browsers have full or near-full support. Also, there is a right point 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 (Rick Gregory). I agree with these significant thoughts.