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.

[peppergraphics]

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

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

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

[rickgregory]

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

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

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

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

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

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

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

Emphasis added... :)

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

[fchristant]

@rickgregory

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

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

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

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

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

[rickgregory]

@rickgregory

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

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

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

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

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

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

[JoshuaLindquist]

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

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

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

[fchristant]

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

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

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

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

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

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

[TimVevida]

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

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

[JoshuaLindquist]

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

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

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

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

[XorAndre]

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

[browsermage]

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

[laukstein]

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

[XorAndre]

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

[Nixinova]

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

[lazarljubenovic]

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

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

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

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

[Nixinova]

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

[lazarljubenovic]

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

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

[XorAndre]

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

[JakubKubista]

As Rachel Andrew mentioned in her article Why Are We Talking About CSS4?, that CSS5 is finally here, then it must mean all major browsers have full or near-full support. Also, there is a right point that there’s a significant bundle of new CSS features that have been developed after CSS3 and which are ready for use and second, that they are ready for use (Rick Gregory). I agree with these significant thoughts.

[Zefling]

It's true that CSS3 encompasses so much, and that makes it so abstract that people don't really know what it is. When I see the number of modules more or less currently supported by browsers, it's a bit of jungle: https://css3test.com/

[captainbrosset]

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.

[mirisuzanne]

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.

[laras126]

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

[una]

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

[browsermage]

Super happy that this gets up and running again 🥳

[dannyjhonston]

Great!

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

[Loirooriol]

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

[jensimmons]

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.

[una]

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.

[astearns]

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

[una]

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

[MrHBS]

So anything happened at the 25th?

[astearns]

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

[css-meeting-bot]

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.

The full IRC log of that discussion

<una> https://docs.google.com/document/d/1ThJggjnuCbz94ckK5ds2UiedyrTrT5Y6V00RVTGgVEw/edit#heading=h.ynsedw1i03ds
<TabAtkins> una: I'm sharing a window with a presentation, link in chat
<TabAtkins> una: So issue 4770 started this discussion and this CG, but it's been going on for years before that
<una> https://docs.google.com/presentation/d/1V3kyGahIl2P2i2J0dlHYhT97ssdfqyQuGpQtUar1aqE/edit#slide=id.g28bb9aacdd6_0_576
<TabAtkins> una: quick overview of why this is important and what our discussions were
<TabAtkins> una: Ultimately CSS3 is a grouping of features covered in "level 3 specs", covers a wide range of features
<TabAtkins> una: So successful that it's still the most common term used to refer to "modern CSS"
<TabAtkins> una: It's how people teach CSS, recruit for CSS jobs, etc
<TabAtkins> una: Not hard to find CSS3 in job requirements, in teaching syllabuses
<TabAtkins> una: Saw an oklch() with CSS3 logo attached to it
<TabAtkins> una: If you search for CSS on google, about half the courses have the CSS3 logo in some way
<TabAtkins> una: So easy to see the impact of the term even today
<TabAtkins> una: Despite this being a fairly specific set of features that don't line up with today's features.
<TabAtkins> una: css3.now lists these features, but that's not how the community talks about it
<TabAtkins> una: How far we've come as an ecosystem, we ahve more features than we ever thought possible when CSS3 started.
<TabAtkins> una: CQ, layouts, interactions on the web platform
<TabAtkins> una: So important to change how people talk about CSS
<TabAtkins> una: Post from dev graham about "what is modern CSS"
<TabAtkins> una: "modern" is too broad of a definition, can't pinpoint a point in time or specific set of features
<TabAtkins> una: So that's hte CG. Initially called CSS4 CG, but might be beyond that, renamed to CSS Next
<TabAtkins> una: Looks to label features in a clear colloquial way to help people understand CSS across the ecosystem
<TabAtkins> una: Other options are Baseline or the CSS Snapshot. Great but don't think they provide the same impact as "CSS3"
<TabAtkins> una: Also runs into the same problems as calling something "modern"
<TabAtkins> una: They just don't have the same cachet either - ES2020, 2021, 2022 vs ES6
<fantasai> +1 the snapshots aren't appropriate for this use
<TabAtkins> una: So using "CSS" or "Modern CSS" just lacks the meaning we need
<TabAtkins> una: Better labels have value, even just from marketing standpoint
<TabAtkins> una: We talked about some goals
<TabAtkins> una: First, helping devs learn about CSS
<TabAtkins> una: Helping teachers teach about CSS
<TabAtkins> una: Employers hire about CSS
<TabAtkins> una: Help community understadn the evolution
<TabAtkins> una: Some non-goals
<TabAtkins> una: Affecting the specs themselves.
<TabAtkins> una: We're not doing anything with the specs themselves.
<TabAtkins> una: Also out of scope is official documentation, we're not writing docs
<TabAtkins> una: And not doing any spec work (should be done in the spec groups)
<TabAtkins> una: And not defining best practices or managing compat data
<TabAtkins> una: Our scope, isntead, is figuring out the community's understanding of CSS feature levels, developing and naming those groups, and educating about those levels.
<florian> q+
<TabAtkins> una: So far our resolution has been:
<TabAtkins> una: Here's the CSS3 set of specs
<TabAtkins> una: Roughly 2009-2012
<TabAtkins> una: CSS4 seems to work out nicely as things that postdate CSS3 for about 5 years and are things that are now stable
<TabAtkins> una: and CSS5 is new growing features, just landing
<TabAtkins> una: In the future CSS6 will be early-stage features just now in planning or not even there yet.
<TabAtkins> una: As part of this work we want to do some research, so we did some early sorting of features into CSS4 vs 5
<TabAtkins> una: Still working on the final analysis of this
<TabAtkins> una: So we want to do a community pulse check, checking with the user group and do some user research.
<TabAtkins> una: In terms of CSSWG, we're hoping for a few things
<TabAtkins> una: First, awareness of what we're doing, hopefully a positive signal from y'all
<TabAtkins> una: Another is general feedback, particularly in our early sorting of categories
<TabAtkins> una: In the process of making a prototype of the reseach
<chrishtr> This is an awesome proposal, and so needed. I love it!
<TabAtkins> una: Finally, join meetings - biweekly (correct meaning: every biweek), Mondays 8am PT/11 ET, 5pm CET. An hour before the CSS meeting, but on Mondays
<florian> q?
<Rossen_> ack florian
<TabAtkins> florian: I'm supportive of the overall effort. Think I like what you said about CSS4 onwards
<TabAtkins> florian: A little issue about CSS3 - we have a dfn of that but it doesn't match what you said.
<TabAtkins> florian: Currently our CSS3 definition says "everything after CSS2", so it can't be an immutable category.
<chrishtr> q+
<TabAtkins> florian: So someone needs to change the dfn of CSS3, either us or y'all
<TabAtkins> (Fine with just changing it, our dfn was based on "we're not doing any categories anymore")
<Rossen_> ack chrishtr
<TabAtkins> chrishtr: I think this is a great proposal and v important.
<TabAtkins> chrishtr: The impact of HTML5 on people's interest in the web, and getting momentum for people to build things that previously people didn't think were possible
<TabAtkins> chrishtr: This has tremendous potential to move the midnshare to make people recognize CSS has really advanced in leaps and bounds.
<fantasai> Slides: https://lists.w3.org/Archives/Public/www-archive/2023Nov/att-0002/CSS-Next_Community_Group.pdf
<fantasai> Archived link ^
<Rossen_> ack fantasai
<TabAtkins> fantasai: +1 to everything Una said, really excited you've picked up this idea
<TabAtkins> fantasai: super supportive of what y'all're doing
<TabAtkins> fantasai: I think if there's any conflict with our Snapshot we can just fix it
<TabAtkins> fantasai: And once the CG dfns have settled down and they're happy with it, I think we shoudl publish it thru CSSWG as a Note
<TabAtkins> fantasai: So have /TR/CSS3, /TR/CSS4, etc as a Note matching what the CG comes up with
<Rossen_> ack fantasai
<chrishtr> resolved, ship it!
<chrishtr> :)
<TabAtkins> fantasai: For the Snapshots naming, using the dated versions of the snapshots as a sub for this, that doesn't really work for this. They're designed for a different purpose.
<TabAtkins> fantasai: Even if they were better named they just wouldn't be suitable.
<florian> +1
<una> +1
<TabAtkins> Rossen_: Do we need a resolution?
<TabAtkins> una: I think it would be a positive
<TabAtkins> fantasai: proposed: The CSSWG supports this CG's efforts in defining levels for CSS as a way for the community to understand batches of CSS properties.
<florian> +1
<TabAtkins> +1
<fantasai> s/properties/features
<TabAtkins> 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.
<fantasai> s/understand/understand and communicate about/
<TabAtkins> chrishtr: Shoudl Una bring back specific proposals to the group about what is CSS4?
<TabAtkins> Rossen_: It's all in public, she can open an issue
<TabAtkins> fantasai: I think if Una has stuff she specifically wants reviewed, an issue will ask us for a review
<TabAtkins> fantasai: And when the CG thinks they're done, they can ask us to publish it as a Note thru the WG
<florian> sgtm

[jensimmons]

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.

[Loirooriol]

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 https://github.com/CSS-Next/css-next/issues/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.

[SebastianZ]

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

[aitorllj93]

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

[Ezekiel1349]

🙌

[ngdangtu-vn]

If CSS4 ever comes true, I wish you guy could change the syntax. The current CSS custom property is long, redundant and encourage sb to come up the function idea for CSS... The -- should be $ (this applies to CustomStateSet which create custom pseduo). No var() should be used. For fallback, we can just append the $custome-property(fallback-value). Don't hate me, I'm just a guy who use css var enough to see its hell once it growing too big.

Update, I'm thinking about a way to combine at-rule to avoid heavy nesting in near future :))

[SebastianZ]

@ngdangtu-vn This issue is about what of the existing CSS features should be summarized as "CSS 4". Your suggestion is unrelated to this effort. So please open a new issue for any idea you have (if there isn't already one)!

Regarding your suggestion to change the syntax of custom properties, that refers to the CSS Variables specification. Though the dollar syntax was discussed in the past and got rejected.

Sebastian

[SebastianZ]

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

[SteGreig]

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! 😄

[aitorllj93]

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! 😄

I think this thread is for some reason, blindly ignoring the "EVEN IF IT'S NOT REAL" part so probably CSS4 will be closer to a crypto than to an actual standardization over something already standardized. I thought you learnt not to sell smoke from the previous iterations. Totally out from the web community on this, see you in a future if there's real changes

🚀