RFC: Initial CSS Level Categorization #92
Replies: 10 comments 12 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.
-
|
The approach isn’t about abandoning CSS3, but rather organizing CSS features into versions like CSS3, CSS4, and CSS5 based on specific timelines. This categorization helps users identify features from old to new. It also benefits recruiters and tutors by making it easier to segregate features for more effective teaching and candidate filtering for projects. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not arguing for the removal of CSS3, but to use EcmaScript style versions doing forth and perhaps do the same from 2013 instead of CSS4/5. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, Gotcha! But are you saying every year we should have a new CSS version like CSS2023, CSS2024? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, one new version every year. |
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.
-
|
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.
-
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