Let’s Define CSS 4 #4770
Comments
|
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.
|
|
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. |
|
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? |
|
+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. |
|
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. |
|
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? |
|
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. |
|
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. |
|
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? |
|
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:
|
|
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. |
|
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. |
|
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":
Doesn't this make sense? |
|
COMPLEX issue. So grateful to you for raising this issue here, Jen! I totally get where you're coming from and agree with the big idea here. Ajax™ succeeded in part because they called it Ajax. Web Standards succeeded because we called them Web Standards. Names matter. One year, four brilliant people at An Event Apart presented a concept whereby media queries could make one design serve all devices. One of those brilliant people called it “Responsive Web Design.” It’s no accident that the Bible starts with The Word as God’s tool for creating reality, and the first thing that happens after creation is God tells Adam to name everything. For that matter, even with all the hard work you and Rachel Andrew and a few others put in, “Grid” and “Flexbox” might not have succeeded if they hadn’t had such catchy names. Additionally, a point many folks here have brought up is also true: that version numbers suggest “newest thing to learn” and “progress is happening,” whereas sticking with HTML5 and CSS3 contributes to a feeling that there’s nothing new in the world of HTML and CSS … so folks motivated by learning new things (or folks who just constantly seek the excitement of shiny and new) tend to discount HTML and CSS as “done deals,” even though they clearly have continued to evolve. That’s not the only reason respect for standards-based, progressively enhanced, accessible web development is in decline. We can find additional causes aplenty in startup culture with its constant shipping (sometimes for its own sake), and in the way startups evaluate worker performance (quantity of output), and in the corporatization of web development (along with the corporatization of politics, law, “justice,” basic human rights, etc.). Bootcamp culture and bootcamp training (versus slow self-training over years of experience) also tend to favor mastering the newest tools and prize developer convenience over user experience—because, after all, the corporation needs all those churning iterations, and developers who can’t ship fast lose out to those who can. Hence the obsession with shiny new tools. It’s not just a childlike fascination with new toys. It’s a cry for help in a ruthless and ill-considered employment market. So I get why this proposal could be a very good thing. But I also hear where Rachel Andrew is coming from. I won’t repeat it here since she makes her case with perfect eloquence. Although I have a thought about that, too: namely… Perhaps, instead of setting version numbers based on a spec being fully supported in all major browsers, we go back to what happened in the old days: a spec was stabilized when at least two major implementations supported it, and other browser makers strove to catch up with that whole specification (i.e. to catch up with CSS 2.1, for example). One unintended side-effect of breaking CSS into millions of small, evolving sub-species like CSS Grid is that it inadvertently encourages browser makers to pick and choose what they’ll support. That picking-and-choosing fosters innovation and testing, which are good things. But they also foster a buffet mentality that has led to a lot of fragmentation in browser support … which inclines many folks to throw up their hands and say, “It isn’t supported in Browser X, so forget it.” Grouping together a series of accepted improvements into a single CSS 4, and telling browser makers to support THAT, would cut down on the impossibility of supporting everything correctly that frustrates browser engineers, and the lack of respect for HTML and CSS that pervades our current culture. And there would still be room for any browser maker who wishes to to support additional, experimental specs if they choose. But there would be enough specs that work across the board for people to get on board the Web Standards train again. At the very least, it would take away one big rationale some (not all) folks who design JavaScript-first wield as a cudgel when the subject of web standards arises. |
|
As an observer, I've seen the everyday categorization of certain specifications and levels as "CSS3", "CSS4", "CSS5" and so on, to be extremely arbitrary and even inconsistent between individual authors. There is no pattern to it — not even a year-/period-based pattern as far as I can tell. And as mentioned, different modules (and levels thereof) are written, tested, and implemented, at such wildly different paces across competing implementations that there is just no sane way to keep track of them all. Anything that looks "newer" or "unlike traditional CSS3" is binned "CSS4", such as variables for example. Yet, some specifications like Selectors have somehow managed to survive most of this arbitrary categorization unscathed — level 3 selectors are considered CSS3, and level 4 selectors are considered CSS4.
I can answer at least the first question, to some extent. I don't have the energy to comment on any specifics but I wanted to say something general right now at least while this is fresh in my mind.
It would, provided vendors are willing to focus their efforts on each version or level of CSS-as-a-whole. selectors-4's FPWD was over eight years ago, and we still barely have any implementations other than Safari since 2015, and Firefox a little more recently, despite at least half of it being relatively stable and unlikely to change. If everyone's ready for CSS5, selectors-4 might as well be renamed wholesale to selectors-5, skipping L4 altogether (which I guess partly answers the second question). If the CSSWG does decide to adopt some semblance of a snapshot system, I'd much prefer year numbers over version numbers, like with ECMAScript as mentioned. The only feasible (if that) alternative would be going back to monolithic CSS, only with any number of subsections, each representing a module. |
|
I'm in favor of the proposal, even if I agree it needs to take into account the criticism that has been noted above, and find ways to compensate it. I think the main advantage is from a cognitive perspective even before the marketing angle. It's easier to wrap the mind around, which is why it's easier to market, which is why it gets marketed. While I totally see the downside of a misrepresentation, there are major upsides in creating every few years a form of "major snapshot" that is has a bit more weight than existing snapshots. The downsides should be compensated however. Rachel Andrew has a point, and I feel that while doing CSS4 (and following) it's also important to use the chance to clarify these points too — whichever form it could take. Maybe it's a matter of defining stages of features inside these major snapshots, or else. In the end, we have the "Candidate", "Candidate recommendation" and "Recommendation" already, we could do something like that. I'd add one note: these "major snapshots" should not happen too frequently. Let's think in terms of cycle of adoption and education, which I feel have a 2-5 years cycle ("feel", so research is needed), and plan these cycles in a sensible way (i.e. I feel "1 year" would be too short). |
|
Lots of great points here. As many pointed out, it seems like moving to a naming convention similar to what ECMAScript adopted makes a lot of sense. And, there could be ways to delineate experimental features and account for @rachelandrew‘s concerns. Whatever is “ready” (e.g. @zeldman‘s suggestion of at least two major engine implementations) is in the CSS4/2020 spec. Everything else is experimental and could be adopted by browsers and implemented through config flags or browser prefixing. As for how often this spec gets updated, I’m in @folletto’s camp that yearly might be too much. That’s just going to fuel the fire that we’re never going to catch up with the building blocks that are the foundation of our livelihoods. 3 years seems like a nice number because that will also allow for accumulation of features that make a new spec worth learning while (hopefully) minimizing that FUD of never catching up. |
|
Wow, there is a lot of interest for this idea. Great to see. I can't go over all contributions that have been made so far, but would like to make a few points from my perspective. When I started thinking about CSS4 I didn't see it as something that should be rigidly defined. In fact, I'm arguing for a fairly vague and hand-wavy approach, where we mostly leave it to individual developers to figure out what they would like "CSS4" to mean. That makes it much easier to raise excitement, I think, than going through a list of modules, some of which you don't need. I'm not sold on the CSS2020, CSS20201 etc. idea, mostly because it conveys a sort of nervousness that I'd like to avoid. A new version every three years or so sounds about right to me. But maybe that's just me getting old. Also, I hadn't considered the CSS WG taking the lead on this (though in hindsight I should have). The problem has already been described: if the WG takes the lead, that pretty much requires some sort of definition, which leads to a lot of work on the part of the WG. My original idea was to take a few modules and make them the spearhead for CSS4 (see below for suggestions). After that, we might elevate any new specification to CSS4, and if enough developers are enthusiastic about a certain module or feature, we could retroactively elevate them to CSS4 level as well. Yes, this is a vague process, but I'm not sold on the need to have a better-defined process. I would fully understand if the CSS WG wants to keep CSS4 at a distance for that reason and leave it to developers to decide what CSS4 actually is, though the WG should be sold on the basic concept and agree that CSS4 is a Thing. To me the purpose of CSS4 is to reach out to people that are currently outside the hard-core CSS world; JavaScript developers in particular. That's why I feel that the first modules or features that get the CSS4 stamp of approval should be picked carefully to appeal to them. In my latest piece I argue for custom properties to take on that role, both because they are already somewhat known (hey! CSS4 isn't hard! You already know some of it!) and because they will appeal to JS devs. Also, I think grid should be part of CSS4, mostly because it's the most important step forward in CSS in many years, and also because it's already somewhat known. We should also have a few features that are on the horizon but not quite here yet, and I'm especially thinking of container queries. I'm not up to speed with the current discussion around container queries, so I'm going to leave it at saying that for a marketing/outreach effort aimed at JavaScripters they make a lot of sense. That's where I stand right now. |
|
A co-worker just pointed out that 5G is an interesting comparison. 5G means a lot of technical things, but picking one name helps to drive adoption in the real world. I've often thought of it like a suitcase with a handle. So many odds and ends go into these discussions, and they're all valid and important. We can't just ignore them. But it's good to have a way of saying "everything in this problem space can be encompassed (or at least referred to) by a single name." It's like a handle on a big, complex suitcase of ideas. |
|
Thanks @jensimmons for creating this official discussion! I vote for a new CSS version, because as a French CSS developer:
I vote for a yearly snapshot because it's predictable, regular, and it makes a breaking change with the old version number. |
|
I appreciate the enthusiasm here, and I think if the CSSWG can figure out a way to make this work, then I'll support it. But, as I stated in my response post, this is kind of bizarre to me because I feel like we're already doing this but on a different level. For example, Nicole says above:
We already say things like "I've ticked the checkbox and learned Flexbox and Grid Layout." I mean, can anyone here say that the marketing push for Flexbox and Grid Layout haven't been huge over the past 5 years? It's been equal to, if not better than, the marketing push of "CSS3". There have been no shortage of books and conferences talks and tutorials covering these subjects. I almost feel like meaningless phrases like "CSS4" actually are harmful to marketing, because they're not as immediately clear as to their practicality as something like "Flexbox 2" or "Grid Layout 3", etc. I also don't think CSS's annual versions are going to bring the same excitement as, for example, ES6+ annual releases/snapshots have. And besides, there isn't a lot of excitement around the latest ES releases. Certainly not nearly as much as ES6 and the one or two releases after that. So what are we trying to replicate exactly? Anyhow, I'm on board with doing anything that pushes the web forward, and I'll gladly help promote CSS4 if it becomes a thing. And I'll happily eat my words if this works. I just don't think the industry is lacking anything and I never really got the impression that CSS needed any more marketing. I think CSS is doing great! |
|
Puts on designer/marketing hat as I read this thread, so I'm jotting down some HMW's:
|
I agree, and I think if we do this, the list has to be generated by the authoring community, CSSWG just makes it official by publishing it.
Agree 100% with @folletto's comment: 1-year cycles are too short to have the sort of marketing impact that this would be meant to serve. (And also I just don't think we have the capacity, we're struggling already to do the snapshots yearly even though they're less subjective. :) |
|
Agree. CSS3 came out when we were still doing float based layouts and vendor prefixes were everywhere. Grid, flexbox, variables, calc, and more along with how they were rolled out have dramatically changed the landscape of CSS and I totally agree it’s time to version up. In terms of this is what developers should know, I’m curious if this can be an opportunity to do some housekeeping around some drafts that are widely implemented and used yet are still somewhat unstable. For example, the pure CSS parallax technique that relies on |
|
I am in favor of the proposal but I keep thinking about how are we going to transition everything that was modularized before? |
|
@ahmadalfy Nothing about the modular structure of CSS specifications needs to change nor will it change. |
|
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:
|
|
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. |
|
I think @una is planning to start things back up with the WG group. |
|
@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) |
|
Super happy that this gets up and running again 🥳 |
|
Great! So, let's define CSS4! 🙌🏻 |
|
Please avoid comments that don't provide new information. If you only want to show support, you can use the 👍 reaction. |
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. |
|
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. |
|
@una to give everyone a bit of time to prepare, shall we take this on in the October 11 meeting? |
|
@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) |
|
So anything happened at the 25th? |
|
@MrHBS we had to postpone. We are planning on taking this up on Nov 8th. |
|
The CSS Working Group just discussed
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 |
|
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. |
|
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?
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 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. |
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 |
|
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") |
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
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 |
|
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! 😄 |
This comment was marked as off-topic.
This comment was marked as off-topic.
and others
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:
Nicole Sullivan wrote:
PPK wrote:
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.
The text was updated successfully, but these errors were encountered: