Since I first chimed in on the CSS4¹ thing, there’s been tons of more discussion on it. I’m going to round up my favorite thoughts from others here. There is an overwhelming amount of talk about this, so I’m going to distill it here down as far as I can, hopefully making it easier to follow.
- Jen Simmons kicked off a discussion on GitHub under the CSS Working Group draft repo. The best we have for developers trying to stay current on CSS right now is “just keep up” and that’s not working. Better to “draw a line” around certain things and say “Here, this. This part is ready. This part is done.”
- Michelle Barker says it’s hard to prioritize what to learn without guidance.
- Nicole Sullivan thinks if developers can “tick the checkbox” of CSS4, it would “drive developers to upgrade their skills, businesses to upgrade their tech stacks, and browsers to focus on cross-browser compat.”
- Dave Rupert sees value in the Perceived Velocity through Version Numbers.
- Natalya Shelburne says that, in “a time-scarce world”, engineers she works with don’t feel like new CSS is production-ready and don’t prioritize learning it.
- Rachel Andrew thinks that the browser support of features, particularly the complex and nuanced nature of subfeatures, is a barrier. Since we don’t know anyone else’s browser support requirements, it’s irresponsible to suggest blanket features to learn/use.
- Brian Kardell brought up that JavaScript is “versioned” yearly and it seems to work over there (Although Shawn Wang rightly mentioned that we should probably be asking them what has worked and what hasn’t). Personally, I prefer the idea of CSS2020 over CSS4 (I just like the synchronicity with JavaScript), and Brain Kardell thinks just because we use a year in the name doesn’t mean we have to do it every year. Chen Hui Jing mentioned that Babel throws a wrench in things a bit. Polyfilling new JavaScript is a different beast than polyfilling new CSS and that affects expectations.
- Miriam thinks we need to settle on a list of features, but that it should be criteria-based. I suppose criteria would be status of spec, browser support (“2 major browsers” is the most common theme), and some kind of importance modifier. My first article took a stab at a feature list and here’s another thought. PPK agrees that flexbox is too old, and favors grid and custom properties. Timothy Miller has a few ideas.
- fantasai doesn’t think this message should come from the CSSWG.
- The more we keep calling it CSS4, the harder it will be to call it anything else. If that’s how it shakes out, fine, but my preference is to mimic JavaScript “versioning”. I’m going to stop calling it CSS4 after this until a name settles in better.
I like CSS2020. Lump in whatever’s ready for production in CSS2020 and then push other features to CSS2021. Simple and easy way of showing what is and what isn’t in the spec at any given time, instead of the multitude of modules in varying states of readyness and versions.
The module system could easily be retained in a CSS2020 naming system, where CSS Selectors Level 3 (or 4 or 5 …) is the formal spec, but CSS2020 is more of a collection of this is ready.
CSS: The CPU Awakens
That footnote is way more important than it looks. It might even be too late! We might already be calling it CSS4, kind of by accident, and meaning “everything new since CSS3” (which pp-koch thinks might not be a bad thing). Is there any harm in CSS4 becoming a nickname for new things in CSS? Does it have to be officially sanctioned? And when we get sick of calling it CSS4 (it looks like that seems to take about a decade) we will invent CSS5.