RFC: Initial CSS Level Categorization #92
Replies: 18 comments 21 replies
-
|
I may have missed it (and I know the list is a work in progress) but I can't see Nesting within CSS5, is that correct? Out of interest, did you consider a smaller window than 5 years? Anecdotally, CSS feels like it's been moving relatively quickly in the last few years and, if that's set to continue, I wonder whether a 5-year window could be too long? ECMAScript versions come every year with only a few new features, for example. This is an interesting idea — looking forward to hearing others' thoughts! |
Beta Was this translation helpful? Give feedback.
-
Nice find. It could definitely be interesting to at least mention it. We did consider shorter periods for future CSS versions. I also believe that this could still shift. Changing the time between versions on the other hand could become a problem as there would be no clear point on when to "close" a version. But I'm very interested to know why you think a shorter timeframe would be beneficial (and also, how much shorter) |
Beta Was this translation helpful? Give feedback.
-
|
I'd prefer that approach too... The lists and timeframes defined above feel too long. As mentioned below, it might be worth putting more weight on major browser support than on initial spec date. Potentially even synchronize this somehow with the Interop Project?! |
Beta Was this translation helpful? Give feedback.
-
|
With the cadence of development in css would it be beneficcial to adopt a naming structure like Ecmascipt? Such as CSS2025/CSS2026 for future versions, perhaps even retroactively CSS2013-CSS2024. I think the shorter time frames would make it easier to communicate what is actually new and when people should consider picking up new features. With an annual version it is easier to identify these are the new stable features in/comming to CSS as the ammount of new features will be less than in a five year cycle. Since the motivation for "abandoning" CSS3 in favour of CSS4/CSS5 is clarity I would argue more granular clarity would be beneficial. |
Beta Was this translation helpful? Give feedback.
-
|
I fully agree. Aligning with ECMAScript on yearly releases (ES2023, ES2024, ESNext, etc) has several benefits:
|
Beta Was this translation helpful? Give feedback.
-
|
+1 for the mindset of working with Agile Release Train. From the outside, the ECMAScript methodology seems functional, so why not? I'm also missing the stage methodology they use, I would love to see it applied to CSS. I have been many times confused about the progress of new features, e.g. color transformations felt close to production, then completely reworked, then in production but I was never clear on its stage. The argument used in https://www.smashingmagazine.com/2024/08/time-to-talk-about-css5/ for why not, I don't understand it:
This feels delusional, too authors-centered, and not enough user-centered. Who cares about eras? Who cares if many changes happen in a year or few? I care about what features I can use, when, each in isolation. |
Beta Was this translation helpful? Give feedback.
-
Exactly, what matters to me is what I can expect to reliably work. Also, this eras thing feels way too wishy washy. It might be because we're technically still in CSS3, but ever since CSS3 got "finalized" new features have just started floating in whenever they're ready. New things in CSS hasn't felt holistic in a long while, but more of a "new feature ready!". Perhaps that could change with a CSS4/5/6/7 era thing, but I still think an anual snapshot is a better way of capturing what's going on, and especially to chowcase that CSS is rapidly evolving. |
Beta Was this translation helpful? Give feedback.
-
|
Poorly said I think an "yearly release" could be too often, but apart from this, I do agree that a CSS definition would be definitiely clearer and easier to use than a "meaningless" number |
Beta Was this translation helpful? Give feedback.
-
|
Why would a yearly release be too often? |
Beta Was this translation helpful? Give feedback.
-
|
Why did you choose to make the specification date the primary criteria? I feel like when talking about what is "modern" and what is "future" CSS the availability should be the most relevant thing to look at. Having an early spec is nice but as long as it did not land in the browser it "only" has educational value, since polyfills are not really a thing (at least as far as I know). So the CSS advancement is only finished when the new thing is supported by browsers. I like the grouping by topic like "view transition", I think it might be useful to group the shadow DOM related things in a similar fashion. |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to challenge the purpose of this work.
What is the confusion in recruitment profiles? Is this when a recruiter / hiring manager sees CSS3 in a resume and incorrectly assumes that this person knows anchor-positioning? Or the reverse, that a person who knows anchor-positioning is passed over because they only wrote CSS and not explicitly CSS3? Perhaps the solve is to start listing the properties that the candidate is proficient in that could be useful to the hiring team. In teaching materials, isn't this a matter of updating the materials to simply say CSS instead of CSS3? What value is the 3 in CSS3 meant to provide? Is anyone authoring CSS2? Same goes for documentation. I think this'll be further confusing when the browsers don't support a CSS version number. Does Safari support CSS4 or CSS5? Wellllllll... they support some CSS4 and some CSS5. Which parts? Wellllllll... you need to look up each part. I'm not confident that categorizing will solve the difficulty in educating about new features. People seek out the CSS they need to solve the problem they have, and knowing the version where that feature was added doesn't seem to have value in that exercise. But if this is meant to be a marketing exercise, then please carry on because I have no stake in that sort of game. |
Beta Was this translation helpful? Give feedback.
-
|
Agree with you 100% but I do have a stake in marketing because then books need titles like “Responsive Web Design with HTML5 and CSS 3, some of 4, a fair bit of 5 and even some 6” |
Beta Was this translation helpful? Give feedback.
-
|
There are only two hard things in Computer Science: cache invalidation and naming things. "Responsive Web Design with HTML and CSS: 2025 Edition" seems to solve the book title problem. Locking into major revs such as CSS3 and CSS4 seems arbitrary enough to be meaningless. I've been writing CSS since the Arena browser, and I couldn't tell you if "hyphens" appeared in CSS2, CSS3, or CSS4, because it doesn't really matter. What does matter is knowing when a new working draft comes out, and ultimately, what features are supported by which browsers and authoring tools. It feels to me like a struggle between an ISO-type "standard" and a software-type "version" -- and I lean towards the latter, rather than the former for something like CSS. Will including something such as "CSS Box Model Module Level 4" into "CSS5" be confusing? (To me, yes, but I'm easily confused.) CSS is modular and complex enough now that using major-release-like naming conventions without going all in on semantic version numbering would just be weird, and ISO-esque standard numbers would be even less helpful. |
Beta Was this translation helpful? Give feedback.
-
|
You’re making my point for me! “Responsive Web Design with HTML and CSS: 2025 Edition” automatically dates the book so in 2026 it seems old even if, content wise, it isn’t |
Beta Was this translation helpful? Give feedback.
-
|
Isn't it old content-wise? It is. I'm assuming the book is not specifically about what any given language standard/specification is, but what one can and cannot expect to use or do effectively, as a developer, with the language, at a point in time. The implementation of the language is more relevant to that book's audience than a level number, to the point that the level number can actually be misleading (since CSS is always changing, and doesn't use semantic versioning). Plus, updating your book edition every year means there's always a fresh version for this year! Textbook publishers figured this one out a long time ago. That said, I'd advise the consortium against basing its naming conventions on marketing best practices. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with @ddamato on his feedback here. Some additional thoughts on the point of "CSS has continued to evolve beyond the scope of what was traditionally considered CSS3, leading to confusion in recruitment profiles" is that I don't believe what has been proposed here will solve that issue? For example, would a recruiter say it is essential to know up to CSS4 which would be 2018 and it would be desirable to know CSS5? But what if that candidate is really strong with their CSS animation and transition skills and know part of the CSS5 spec, but are weaker with their knowledge of blend modes which is CSS4? I think it's at odds how someone may learn CSS and how this proposal is trying to categorise it. |
Beta Was this translation helpful? Give feedback.
-
|
I'm 100% in alignment with the need to "version" CSS for educational/marketing purposes. As an educator, I have routinely run into challenges conversing with people who consider themselves well-versed in CSS when…the CSS they're well-versed in really is CSS4 at best. They're largely unaware of anything in the past 2-3 years of CSS evolution. Then they have strong opinions about what is/isn't possible with CSS—particularly around overall software architecture—when the issue isn't in fact the technology but the lack of awareness. It would be a dream if I could offer courses specifically in CSS5, CSS6 down the road, etc. I'd be down with the suggestion to go with ES-style naming via year (CSS2024, CSS2025, etc.) if that makes more sense overall. But to the suggestion that we don't need any version naming? Very much disagree with that. (We also need HTML6, HTML7, etc.…but that's a conversation for another day!) |
Beta Was this translation helpful? Give feedback.
-
|
Hear me out: let’s ditch numbers and go the Pokémon route. Give me CSS Red and Blue or CSS Diamond and Pearl. In all seriousness, I think the case for using years is the best, especially since people tend to build websites with time-related requirements for CSS features — but maybe that overlaps with Baseline too much? But in any case as an author I don’t feel like versions will be particularly meaningful for me. |
Beta Was this translation helpful? Give feedback.
-
|
This made me laugh and I was going to add my own comment to this discussion I thought to myself you might be onto something... Let's drop the number and call it as it is; CSS feels like HTML — a living standard. |
Beta Was this translation helpful? Give feedback.
-
|
I feel like this can get confusing very fast. Many CSS specs have layers. For example IIRC, CSS3 started as a shorthand for new features because at the time new features were introduced in Level 3 specs. Also, new specs are introduced that start their layering anew. E.g. This effectively assigns each property/feature two arbitrary numbers. Given that one of the numbers is tied to years, maybe it'd be prudent to use years directly? As @kkalvaa suggested, adopt a scheme similar to ECMAScript. Another potential issue is classification by introduction year. Take Flex Box as an example. It was introduced way back in 2009. There even were implementations of the earlier version of the spec. Then a new incompatible version was introduced. IIRC, similar story was with gradients. For some specs it take really long time from introduction to implementation (e.g. Page Floats, introduced in 2015, which would make it CSS4 but it still has no implementations out there as far as I can tell). So maybe at least one major implementation (or even just any implementation) is a better year to take? |
Beta Was this translation helpful? Give feedback.
-
|
I really want to use the new versions, it sounds too good. Let's see if it booms once and for all |
Beta Was this translation helpful? Give feedback.
-
|
Uno! (Sorry for shitposting |
Beta Was this translation helpful? Give feedback.
-
|
The versioning/numbering, unless officially recorded somewhere and religiously adhered to, will never quite be right or useful, because dates overlap, and no job ever limits themselves to lists like that. In the end, aren't all of the use cases really just asking "how up-to-date" are you? I mean, what class is ever going to advertise "Teaching CSS 3" or job is going to say "Must be proficient in CSS3" if we are now at CSS5 or CSS6? I once applied for a job that just asked for "Proficiency with CSS" (this was pre-CSS3) and, during the interview, I was asked to explain a few CSS declarations. The questions ranged from "simple stuff that I knew inside-out" to "stuff that I knew existed, but couldn't actually explain". So maybe simple classifications like "Out-of-Date", "Current", "Bleeding-Edge", which could then progress with time? (Nicer words might be offered by the wordsmiths out there...) Or maybe Google's Baseline project could be helpful here? |
Beta Was this translation helpful? Give feedback.
-
|
From a CSS user’s perspective, I couldn’t care less about versions. I check the adoption for each feature I need and either use it or don’t. However, from the perspective of education, versions—true versions—would be very helpful. Nowadays, CSS classes may be out of date or not, and those taking them would not know until they are emerged into CSS. If I was to develop a class for CSS I’d be struggling to explain the versionless nature of CSS on a sales page—at least in a way that a person who has no idea about CSS might appreciate. I believe for those wanting to learn, versions would help immensely when trying to decide which class to take. For recruitment, I’m uncertain. It could surely help to have labels indicating if a person stopped learning in 2013 or kept up with recent developments, but I have no hiring experience. I think once you’ve learned CSS you know that you have to keep up with the changes to stay relevant, but in a corporate environment those hiring may not understand CSS, or cod ein general. Versions might help them make better choices? |
Beta Was this translation helpful? Give feedback.
-
|
I would expect people to look at the date of the course/book release to gauge how up to date it should be, and check the particulars if they wanted to check whether a certain detail was covered |
Beta Was this translation helpful? Give feedback.
-
|
Both of those things require a base level knowledge of CSS. A person that is just getting started will now know how important it is to use current material, neither will they know the particular features that might be missing. |
Beta Was this translation helpful? Give feedback.
-
|
To me the fact that we want to retroactively create two new CSS versions that are immediately versions of the past, already proves there might be little value to creating them. While hiring engineers over the years I’ve never looked at CSS or HTML versions mentioned. The contrary almost, someone mentioning HTML5 or CSS3 specifically almost made me feel they were stuck in time. I never use these numbers. It’s just HTML and CSS, both which are ever evolving and can’t be pinned to a specific version having specific features. In my opinion this would only be useful if there was one big drop yearly with these new features. Would be a fun day now I think of it! Even the yearly versions of EcmaScript are hard to keep track of. For most features I don’t know what was part of which version. On resumes I just expect to see JavaScript / TypeScript knowledge, but not specific ES versions. The only benefit of yearly versions is that you get a good idea how new a feature is. In order to understand how up to date the knowledge of someone is, we need to use different things than looking at a version number that is or isn’t mentioned. If it really becomes that important on resumes, people will just slap the latest number in there. Finally as an educator I always like to mention specific features instead of a CSS version. For a complete CSS course it would make more sense to look at the last update timestamp than a version number. But in either way it will be impossible to know if all modern css features are being taught, without looking at the full curriculum at minimum. So I think the best option forward would be to use yearly versions, simply to showcase better how new a feature is. Not the other way around to tell which features are part of which version. |
Beta Was this translation helpful? Give feedback.
-
|
I agree that yeared versions are better in the now but think they are trickier to use when looking back. If someone said ES2021 I wouldn't be able to say "Oh they know String.replaceAll()". That said - overall this is more a marketing exercise and a way to help new users understand where to start more. While learning people should focus on features. Problem arises someone wants to learn all the new CSS stuff and doesn't have an easy way to find it. |
Beta Was this translation helpful? Give feedback.
-
|
css2013, css2018, css2024 |
Beta Was this translation helpful? Give feedback.
-
|
I like the idea of using years, but where's the cutoff? When the feature was finalized in the spec? The interop year? When it's widely available? |
Beta Was this translation helpful? Give feedback.
-
|
One thing I haven't seen here is the retirement of old features. Don't features ever become obsolete and thus useless? |
Beta Was this translation helpful? Give feedback.
-
|
I love the idea! This is going to bring a fresh vibe to CSS. Like it or not, the term CSS3 doesn’t really represent modern CSS anymore. Today’s CSS is dynamic, smart, and constantly evolving, so having a new term that reflects this behavior is essential. When I see CSS3, it feels “old,” “outdated,” and “static” — the complete opposite of what CSS actually is now. |
Beta Was this translation helpful? Give feedback.
-
|
Do we need to continue to classify CSS that has been introduced and established in the past? |
Beta Was this translation helpful? Give feedback.
-
|
I am in favor of CSS versioning. |
Beta Was this translation helpful? Give feedback.
-
|
@satake-miyuki , I can understand your concern. But it doesn't have to be like for anyone to complete CSS3 and then go on to CSS4 & CSS5. The order doesn't matter. Its just how CSS has been categorized and these are by various factors as stated by @una above in the announcement. I've pasted the same below for your reference Categorization is based on a variety of factors with the primary factor being the general timeline that an API was initially specified in the CSS Working Group. Additionally, implementer interest and adoption were moderately taken into account in the categorization process.Someone new and learning web development can totally start at CSS4 and then once they have a grasp or good understanding of it. They can move back to CSS3 or the legacy version. However, some properties might need prior CSS knowledge to understand them. Most of them are quite independent and can be learned in any order. |
Beta Was this translation helpful? Give feedback.
and others
-
Intro
The CSS Next Community Group is looking for feedback on our initial exploration into CSS Levels. This is our formal request for comments.
This doc contains information about the decision-making process as well as the current list of level categories and features.
RFC
The term "CSS3" has been widely used to encompass various additions and enhancements to Cascading Style Sheets (CSS) since around 2010. However, as CSS continues to evolve with new features and specifications, the blanket term "CSS3" has become insufficient and misleading. This RFC proposes the categorization of CSS properties into distinct groups, namely CSS3, CSS4, and CSS5, to better organize and facilitate understanding of the evolving CSS landscape. This categorization aims to improve adoption and ease of teaching, while not having a direct impact towards the CSS Working Group (CSSWG) operations or the Baseline initiative.
Reason
The term "CSS3" has been used to refer to all additions and enhancements to CSS since the early 2010s. However, CSS has continued to evolve beyond the scope of what was traditionally considered CSS3, leading to confusion in recruitment profiles, teaching materials, and documentation. This lack of clear categorization makes it challenging for developers to stay updated with the latest features and for educators to effectively teach CSS advancements and define specializations in the field.
Proposal
Categorization
Categorization is based on a variety of factors with the primary factor being the general timeline that an API was initially specified in the CSS Working Group. Additionally, implementer interest and adoption were moderately taken into account in the categorization process.
Implementation:
Benefits
Clarity and Organization
"Modern CSS" does not have any specific meaning or timeframe. Clear categorization of CSS properties into CSS3, CSS4, CSS5, and any future versions will provide developers, recruiters, employers, and educators with a structured framework for understanding and discussing CSS advancements and its evolution.
Improved Adoption
By simplifying the presentation of CSS advancements, developers may be more inclined to explore and adopt new features, leading to broader utilization of modern CSS capabilities.
Enhanced Teaching
Educators will have a clearer vocabulary and roadmap for teaching the evolution of CSS and better categorize modern CSS features.
Conclusion
The categorization of CSS properties into CSS3, CSS4, CSS5, and any future versions offers a solution to the ambiguity surrounding the terms "CSS3" and "modern CSS", while providing a structured framework for understanding and discussing CSS advancements. By implementing this proposal, we can improve adoption, simplify education, and better organize the evolving landscape of CSS.
List of CSS4 and CSS5 features
This list should be handled as a work in progress.
CSS4
Align
Animation
At-rules
Blend Modes
Clipping, shapes & masking
Contain
Counter
Flex
Functions
Gradient
Grid
Image / Video
Logical Properties
Misc
Print
Pseudo-classes
Pseudo-elements
Relative units
Scroll
Typography
CSS5
Animation
At-rules
Cascade Layers
Colors & theming
Container Queries
Logical Properites
Math Functions
Pseudo-classes
Pseudo-elements
Relative Units
Scroll
Scroll-driven animations
Transition & Transforms
Typography
View transitions
Future (Uncategorized, out of scope for CSS4/5)
Align
Anchoring
Aural CSS
Color
Container Queries
Functions
Grid
Pseudo-classes
Pseudo-elements
Scroll
Text Fragmentation
Typography
Units
For more information about how these features were categorized, see categorization doc with more commentary and details
Beta Was this translation helpful? Give feedback.
All reactions