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.

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.

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?

+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.

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.

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?

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.

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.

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?

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.

JFTR: #4752 #4715

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.

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.

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":

Doesn't this make sense?

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.



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.

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).

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.

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.

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.

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.

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!

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?

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. :)

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.

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

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

What a thread. Thanks so much to all the amazing people who shared their knowledge and ideas here. This made my day.

A few thoughts of my own, since this issue is still open:

• A community group was started but after looking at the mailing list, it seems empty. Has anything happened on this topic since the last comment on this thread? Is there a place I can catch up on the most recent discussion? In particular, I'd be interested in knowing if progress has been made in identifying a set of features.

• I agree with the benefits people have listed so far in favor of a CSS version, whatever its name. This would do a lot of good in our industry.

• I'm of the opinion that this "version" of CSS shouldn't worry too much about whether the features are implemented in engines, and how many. If this marketing term comes out of the Working Group, then it makes sense for it to be more spec-driven than implementation-driven.

  Meaning: these are the features the WG considers to be version N of CSS. It's not a snapshot of everything, and it may or may not be 100% implemented in engines, but it's a cohesive thing we can easily name, which makes sense, which we can learn about, build courses about, adopt, implement, etc.

I don't think you've missed out on any conversation beyond this - the group formed, but never picked up momentum. If you look at the dates, I think its likely COVID interrupted these conversations.

In the meantime I've noticed that the yearly 'Interop' projects fill some of this role. It's a nice yearly subset of new or new-ish features, with a clear story for marketing to authors. All the browsers have agreed to make this work by the end of the year. I'm not sure it's a perfect stand-in, but worth looking at as a related project.

I think @una is planning to start things back up with the WG group.

@mirisuzanne @captainbrosset I emailed everyone on the mailing list to pick a time to meet again, please let me know if you didn't receive this or would like to be added. I hope to start these conversations again within the next few weeks (end of this. month)

Super happy that this gets up and running again 🥳

Great!

So, let's define CSS4! 🙌🏻
✨❤️✨

Please avoid comments that don't provide new information. If you only want to show support, you can use the 👍 reaction.

I don't think you've missed out on any conversation beyond this - the group formed, but never picked up momentum. If you look at the dates, I think it's likely COVID interrupted these conversations.

This is absolutely what happened. After a lot of discussion by many people, I created the CSS4 community group as a place where we could do the work of figuring out details — on Feb 24, 2020. Less than two weeks later, I was very ill with COVID. And did not recover. When I left my job at Mozilla months later, I was automatically removed from the community group by the system. I don't currently have access. Lara Schenck became the chair by default (likely she’d signed up first).

I’m grateful Una is interested in picking this up, and moving things forward. I do still very much believe web designers and developers will benefit from having a clear definition of CSS 3 vs CSS4 vs CSS5. I still see recruiters asking for applicants with "CSS3 and HTML5" skills. I know front-end developers are a bit lost trying to know what's most important to learn next. And I'm glad to see enthusiasm in this thread to make this happen. My apologies for starting to facilitate this getting going, only to disappear from everything CSS for two years.

Hi all, a few of us have been meeting as a part of the CSS4 community group and would like to discuss our progress to get your feedback. We've been working on definitions and a pre-sort for features. We'd love to present some our work at an upcoming CSSWG meeting.

@una to give everyone a bit of time to prepare, shall we take this on in the October 11 meeting?

@astearns great -- can we actually placehold this for October 25? Our next CG meeting is October 16 so it would be good to put something together and get review (and I'm at an event on the 18th, so 25th would be ideal)

So anything happened at the 25th?

@MrHBS we had to postpone. We are planning on taking this up on Nov 8th.

The CSS Working Group just discussed Let’s Define CSS 4, and agreed to the following:

• RESOLVED: The CSSWG supports this CG's efforts in defining levels for CSS as a way for the community to understand batches of CSS features.

I'm very glad this is happening! Thank you @una for moving it forward. It's upsetting to see this is one of the very last things I did before getting so incredibly sick. (In fact, I missed the presentation today because I was in so much pain, I could not drag myself out of bed until after the meeting was over.) It's wild to imagine a parallel universe where Covid never existed… this effort probably would have happened 3 years ago, and what's in CSS4 vs 5 vs 6 would have been different. But never mind that... I'm grateful it is happening now. It's frustrating to still see job descriptions asking for "CSS3" skills! Soon, no longer.

I missed the presentation. I'm reading the slides, but I'm very confused by the definitions in https://github.com/orgs/CSS-Next/projects/1/views/2, I guess they are wrong?

• CSS3: This item hasn't been started
• CSS4: This is actively been worked on
• CSS5: This has been completed
• Next / Future

TBH the classification seems quite arbitrary. I guess authors basically care about when features ship in browsers (rather than just being specced), but how do you classify features that are implemented on a single browser?

Also, the classification seems to assume that features are never iterated on. For example CSS-Next/css-next#9 says :nth-* selectors have been fully supported since 2011. But only the basic form, the <an+b> of <selector> syntax is much more recent. I'm worried that by classifying this as CSS3 (as opposed to some newer CSSx) will just generate confusion among authors who will be misled to think tat the entire feature is very stable.

While I agree that CSS3 has been a successful brand, I'm not convinced that the circumstances that allowed it still hold. HTML5 has even more recognition than CSS3, and I haven't heard about plans for HTML6.

I'm reticent about all of this actually being useful at all.

I'm reading the slides, but I'm very confused by the definitions in https://github.com/orgs/CSS-Next/projects/1/views/2, I guess they are wrong?

* CSS3: This item hasn't been started

* CSS4: This is actively been worked on

* CSS5: This has been completed

* Next / Future

Obviously, the descriptions of CSS3 and 5 just got mixed up.

While I agree that CSS3 has been a successful brand, I'm not convinced that the circumstances that allowed it still hold. HTML5 has even more recognition than CSS3, and I haven't heard about plans for HTML6.

While it might not be as strong as CSS3 was back then, I do think labelling newer features with new levels will have some impact on the industry.

TBH the classification seems quite arbitrary. > I guess authors basically care about when features ship in browsers (rather than just being specced), but how do you classify features that are implemented on a single browser?

Which features make it into the different levels is obviously still under discussion.

I'd also say it's mainly about browser support. CSS3 back then was not fully supported when the term was coined. Though I believe CSS 4 and newer levels should cover all features that are broadly supported by browsers up to a certain point in time. That means, features that are only supported by one or two browsers should not be part of CSS x.

For considering which features should be added to a new CSS level, several sources are of help, e.g. WPT, the CSS snapshots, css3test.com (yep, there's the 3 again 😊; @LeaVerou that probably requires a new domain once we settle on CSS 4 😀), caniuse.com, MDN, etc.

Sebastian

I think "responsive" was much more attractive marketing word than CSS3. Companies did demand CSS3 because of responsive, otherwise, there would be no need

(Also media controls as an alternative to Flash for HTML5, which later evolved into "web applications")

For what it's worth, I am currently going through all the specs for defining what should be part of the CSS 2024 snapshot. And I suggested to add a bunch of specs to the official definition.

With that, I think this year is a good time to define CSS 4 along with it.

Sebastian

Hello! Front-end developer here who actively builds websites and works with CSS every day. I also published a book on advanced "CSS3" via Wiley in 2013.

I think the general concept here is absolutely a winning one. People will be falling over themselves to make CSS4 courses, publishers will be clamouring to release CSS4 books, and it will create a buzz that makes developers feel a sense of needing to get across it all. And the end result will be greater coverage, greater visibility and greater uptake for new CSS features.

We've literally already seen this pattern with CSS3, and I've no reason to think it would be different now. As many have mentioned already, naming matters and branding matters. Even if it's not "real", the impact in community uptake will be very real.

I echo the sentiments from others who have said that there's a general perception that CSS these days isn't something that needs to be kept on top of. People won't invest the time to look into a new pseudo-class, but if recruiters are listing CSS4 as a requirement, they will get that base covered.

As someone who covered CSS3 extensively at the time, I don't think 'production-readiness' needs to be a major consideration with CSS4. While I understand Rachel Andrew's points, the various modules under the CSS3 umbrella had very varying degrees of support at the time, and it seemed to be generally understood that some features had good support and some didn't yet.

My main concern at the moment is I think you'll need to be careful about what goes into the CSS4 bucket. Looking at this list, much of the proposed CSS4 features were, in my experience, covered back when CSS3 was the catch-all term. As I mentioned, I think CSS4 has the potential to hit the web dev scene quite hard, and if people then realise it's just Flexbox, Grid and other already mainstream features, it may be somewhat underwhelming and also a bit confusing. I may be wrong on this but this is my gut feeling.

To conclude, I personally think this is most definitely the way forward for CSS and am very excited about seeing this come to fruition! 😄