Repository navigation
Let’s Define CSS 4 #4770
Description
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.
Activity
chriscoyier commentedon Feb 12, 2020
Amelia Bellamy-Royds pointed me to the idea of these "snapshots" that you already do. That seems like a great idea to me, and a stepping stone to the marking panache that will get people caring and fight against what Jen rightfully called the exhausting "Just Keep Up" method of learning.
stubbornella commentedon Feb 12, 2020
In the constant stream of things we need to learn, it's nice to be able to tick the checkbox and say "yes, I have learned CSS4". I think it would drive developers to upgrade their skills, businesses to upgrade their tech stacks, and browsers to focus on cross browser compat. All good things for the web imo.
jensimmons commentedon Feb 12, 2020
re: Chris' comment above:
I believe the Snapshots and this should be two different things. The Snapshots are heavily dependent on the CSSWG process, and where exactly in the process a spec might be. It's official legally, etc etc... there are many considerations for what's included in or excluded from the Snapshot.
If we define CSS4, separate from Snapshots, we could focus on making a list that's designed for Authors. What is the word from the CSSWG about what is ready to use on websites?
davatron5000 commentedon Feb 12, 2020
+1 to this.
I wrote about "perceived velocity through version numbers" awhile back and came to the same conclusion that versioning would be helpful. It's indicative to me that CSS, despite huge advances like Grid, is generally perceived as stale and has been since it was announced there would be no CSS4 in 2013.
Meanwhile, JavaScript has seen a huge explosion in velocity and has published the following standards since 2015: ES6, ES2015, ES2016, ES2017, ES2018, ES.Next, ES7, ES8, and ES9.
It's a major bit of correlation, but I think it would be very helpful to have some sort of reference point snapshop or collection of features.
tallys commentedon Feb 12, 2020
I am in favor of anything that makes the work visible and valued. Defining CSS4 can join the many other ways progress and stability are communicated to those without their eyes focused on the world of CSS.
Anecdotally, I often find myself in the role of teacher and advocate for the new capabilities of CSS, and I am often met with either surprise or mild disbelief - more than a few engineers I work with feel concern that the new features in CSS might not really be production ready, and as a result, do not prioritize the time to delve into them. In a time-scarce world where things are being versioned with a vengeance, seeing CSS3 remain static sends a message. Designers and engineers constantly have to prioritize what to learn and what to keep up with. A clear and well defined list of "this is CSS4" would instead signal that these things are worth prioritizing to learn today, not later, and encourage trust so that the developers don't have to ask "but is it ready to use yet?" as the first comment on every blog or at every Q&A.
A 'major version bump' so to speak, from CSS3 to CSS4, will get designer and engineer attention and send a clear message of progress and stability. My hope is that it will also help to add weight to folks writing job descriptions, deciding on frontend architecture, and shaping team roles.
chriscoyier commentedon Feb 12, 2020
It's been so long since CSS3, the list is pretty deep.
The big ones:
smaller:
And what is the criteria for inclusion? Supported in 2 of 3 major engines or however we refer to it these days?
rachelandrew commentedon Feb 12, 2020
I'm not a fan of this idea, and it's been raised to me in person in the past, and I wasn't a fan then. The reasons being that I think what authors want out of a CSS4 is a declaration that a certain set of specifications are "ready to go", and can be used. However, this goes against the real situation which is that it completely depends on the project you are working on, what you are able to use. From talking with the developers I teach in workshops they work on projects with wildly differing requirements, based on the users of the sites and applications they build.
Then on a practical level, we have specifications where a big chunk of the spec is well supported in browsers, and then some of it has no support at all. As an example, Box Alignment, it was tricky enough to figure out how to represent support when documenting this for MDN, as we have properties and values that are supported fully by browsers in Grid, but not at all in Block Layout. We have gaps which are supported in Grid and Multicol, but not by Chrome in Flex. So where would Box Alignment live in our CSS4? What about Fragmentation - is that "production-ready" in any way that would make sense to authors?
I think on an ongoing basis this would also add extra overhead to the decisions we make as a group. Not only will it be a case of deciding whether to add a feature based on the maturity level of a spec in our own process, we will have this additional abstraction of a CSS level we are promising authors. It's more work, do we need more work?
Also, CSS is not just for web browsers, so how does this fit into the world of print?
I don't think that it's the place of the CSSWG to tell authors what is ready to use on their websites, because we don't know the support requirements of their websites. I think it would add extra overhead to our work, and store up problems in the future when we are then pushed to declare a CSS5, and have to figure out what that means for everything we work on.
I think if anything, as a group we can create better material to explain how the process really works, which would better enable authors to follow along. I think we are doing web developers a disservice to act as if they can't understand our process. It just needs clearly explaining. I've never explained how modules and levels work to a group and had people confused by that. And, if there needs to be any kind of "this is what is production ready for the web" that seems more like something which should come from web browsers themselves, it feels like the MDN Browser Compat Data would be a great start for that. I'm certainly not against coming up with guidance on this stuff, I just don't think that declaring a CSS4 is going to help.
mbarker84 commentedon Feb 12, 2020
I agree with @tallys:
A lot of people I encounter are not aware of newer CSS specifications, don’t realise how well-supported they are, or don’t have the time to prioritise learning them. To be able to package up a “syllabus” of newer CSS modules that are widely supported under the label of CSS4, would help developers prioritise what to learn, and may help shift the perceptions of some of those of the periphery of our industry too (clients, recruiters, etc.).
Yes, not everything is so clear cut in terms of what is supported, so nailing down inclusion criteria may be difficult, but there are a lot of specs (like the ones mentioned by @chriscoyier) that have very widespread support, and would be clear candidates. Most developers would have enough sense to understand that they would still need to discern whether something can be used in the browsers they need to support, and that inclusion in CSS4 doesn’t mean blanket support for older browsers. Whether it’s the CSSWG’s job to package it up in this way is a different matter, but I don’t see anyone else doing it.
bkardell commentedon Feb 12, 2020
As I mentioned in wg then this came up "js developers seem pretty ok with the es model, would css developers too? There's an added advantage of consistency there to... css-2019".
Just pointing to that both @chriscoyier and @davatron5000 have mentioned a similar connection here so it feels like.. Maybe?
mirisuzanne commentedon Feb 13, 2020
I think this is a great idea – and would help me both with clients and students. I also think @chriscoyier is on the right track for a next step here, diving into the first release:
Crissov commentedon Feb 13, 2020
JFTR: #4752 #4715
Crissov commentedon Feb 13, 2020
TL;DR: Introduce versioned “Web …” authoring competency profiles instead.
I was a fan of modularization when it started after CSS 2.0. However, not everyone had the same idea how it would or should work. In my opinion, we should have had started with splitting the existing spec into parts without adding anything new, but in reality, almost twenty years later, some modules and some external specs still need to reference CSS2. Another effect was that it took like a decade for the WG to agree that modules that build upon Level 2 would start at Level 3, whereas completely new modules would start at Level 1, despite “CSS3” being the popular term. Some modules are at Level 5 now (or soon). That is why I believe that “CSS4” in particular would not be a good marketing term.
We originally had some Profiles of CSS (e. g. for handhelds, TVs and printers) that bundled certain modules and, unfortunately, also picked single features out of other modules, which together would need to be supported to claim conformance. It was thought okay to not support entire modules if it did not make sense on the platform or for the vendor – nowadays we are closer to a monolithic ubiquitous and open “libcss” that tries to support everything than we ever were, despite some forks and a good, mature and also open alternative.
Today, all we have are supposedly annual snapshots released by the CSSWG for implementors and external sites documenting real-world support by custom criteria. Common, reliable test suites for objectively determining conformance are still regarded of secondary importance by many.
I did consider to suggest a numbering system for “CSS” that significantly differed from classic Levels, which individual modules shall continue to use, and did not imply annual updates which – letʼs be honest – the WG will never finish in time anyway. The system I preferred was loosely based on browser version numbers: CSS n would be (roughly) what could be assumed to work sufficiently well in all of Edge/Chrome version greater than 10×(n+1) and Firefox in greater than 10×n. The current state would therefore be between CSS6 and CSS7. I came to the conclusion that this is too unintuitive and unreliable, though.
What I do suggest are entirely new terms for bundles/profiles/sets of (ideally only full) modules, versioning independently of CSS module levels:
These would also include (parts of) other specs like HTML, SVG, JS and HTTP if necessary.
huijing commentedon Feb 13, 2020
I think @davatron5000 raises a salient point about how the TC39 chose to handle ECMAScript with "big" releases of each version seems to be received well with many people. But I think the key difference here is that CSS was modularised, which makes it tricky to do something similar like a CSS2020 or even CSS4 as per the original suggestion.
There is also a significant difference for the Javascript eco-system that goes beyond perception alone, which is Babel. Developers generally feel safe to use all the latest and greatest ECMAScript features because Babel is there to take care of the cross-browser/backward compatibility issues for them.
In relation to this idea, I find myself agreeing with @rachelandrew that the issues with adoption of newer CSS properties are also significantly dependent on how and when browsers implement them, especially browsers with significant market share. I'm very much for more explaining about the process.
That being said, I feel that I do have a significantly subjective emotional connection to CSS that perhaps clouds my perspective, which is one the majority of web developers probably do not share. The crude analogy I can draw here is you cannot unlearn how to ride a bicycle. And for me, understanding the process and embracing the varying levels of browser support is the bicycle I have learned to ride.
What is the best way to teach the general web developer how to ride this bicycle as well? But I suppose the heart of this topic to begin with was how to even get the general web developer to want to ride this bicycle.
The points I've seen repeatedly mentioned by people above this comment thread are:
And I agree with these observations because I see them often as well. I'm just not sure if CSS4 is the appropriate way to trigger "excitement" or push web developers to learn more.
SelenIT commentedon Feb 13, 2020
I'd like to link to my long comment in the related issue explaining why I believe that the value of CSS Snapshots for authors might be still significantly underrated.
The concept of separately progressing features finally getting incorporated into the yearly updated main standard is already familiar to web devs from the EcmaScript process. We are used to speak, e.g., about "arrow functions from ES6/ES2015", or "async/await from ES2017/ES8".
"CSS as a whole" has no versions, but it has a document with the short URL w3.org/TR/CSS that appears to suggest that it somehow describes the state of "CSS as a whole", with a section named "CSS - the Official Definition" (sic!). This document is also updated roughly every year or two, and the latest definition (CSS-2018) is the 5th update since CSS become modular, or the 7th "CSS definition" counting from CSS1. In other words, if we named "CSS revisions" after the edition numbers of the standard definitions (like ES3, ES5, ES6 etc.), we could call it "CSS7" – good match to @Crissov's estimation above (and the upcoming definition, CSS-2020, would be "CSS8").
The only thing I'd like to add that for web authors the union of the "Official defininion", "Deployed with rough interoperability", and "Safe to Release pre-CR Exceptions" sections would probably be more useful than the "Official definition" alone. This set of features appears to be "stable enough" for many practical applications, either well-supported or soon-to-be-supported in browsers, so developers would know that it's probably worth learning. Another useful part of Snapshots is that they explicitly exclude outdated parts of specs (e.g. CSS2.1 sections superseded by newer modules), clearing the confusion and reducing the cognitive load.
Looking through the history of CSS from this POV, we can roughly categorize its features by different CSS "revisions":
:first-line/:first-letter, box model, block and inline formatting, floats, font properties, #hex and rgb() colors, absolute lengths,emandexunits, "reference pixel":first-child,:before/:after,>and+combinators,@media,@page, table model,cursor,outlinedisplay:inline-block, new attribute selectors,::for pseudo-elements,:last-child,:nth-child()etc.,:empty,:targetand:not(),~combinator, hsl(),currentColorandopacity, CSS Namespaces,styleattribute standardwidth,orientationetc.)@mediaand@supports, CSS Cascade 3, new units from Values and Units 3 (incl.pxas absolute), calc(), multiple backgrounds,border-image,border-radius, linear and radial gradients, web fonts, Multi-columns,mix-blend-modeandisolation, updatedcursorandoutline, Transforms, Animations, Transitions, Flexbox:dir()and:lang()pseudo-classes,min-contentandmax-contentwill-change,filter, easing functions, logical properties, conical gradients,:focus-withinpseudo-classcontain, ... (to be continued)Doesn't this make sense?
118 remaining items
TKDev7 commentedon Oct 27, 2023
So anything happened at the 25th?
astearns commentedon Oct 27, 2023
@mrhbs we had to postpone. We are planning on taking this up on Nov 8th.
css-meeting-bot commentedon Nov 8, 2023
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 commentedon Nov 8, 2023
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 commentedon Nov 9, 2023
I missed the presentation. I'm reading the slides, but I'm very confused by the definitions in CSS Feature List (view), I guess they are wrong?
TBH the classification seems quite arbitrary. I guess authors basically care about when features ship in browsers (rather than just being specced), but how do you classify features that are implemented on a single browser?
Also, the classification seems to assume that features are never iterated on. For example CSS-Next/css-next#9 says
:nth-*selectors have been fully supported since 2011. But only the basic form, the<an+b> of <selector>syntax is much more recent. I'm worried that by classifying this as CSS3 (as opposed to some newer CSSx) will just generate confusion among authors who will be misled to think tat the entire feature is very stable.While I agree that CSS3 has been a successful brand, I'm not convinced that the circumstances that allowed it still hold. HTML5 has even more recognition than CSS3, and I haven't heard about plans for HTML6.
I'm reticent about all of this actually being useful at all.
SebastianZ commentedon Nov 12, 2023
Obviously, the descriptions of CSS3 and 5 just got mixed up.
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.
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 commentedon Nov 21, 2023
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 commentedon Jan 8, 2024
ngdangtu-vn commentedon Jan 13, 2024
SebastianZ commentedon Jan 14, 2024
SebastianZ commentedon Jan 14, 2024
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 commentedon Mar 8, 2024
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 commentedon Mar 8, 2024