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.

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

[jongeorgeff]

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.