Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let’s Define CSS 4 #4770

Open
jensimmons opened this issue Feb 12, 2020 · 118 comments
Open

Let’s Define CSS 4 #4770

jensimmons opened this issue Feb 12, 2020 · 118 comments
Labels

Comments

@jensimmons
Copy link

@jensimmons jensimmons commented Feb 12, 2020

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.

@chriscoyier
Copy link

@chriscoyier chriscoyier commented 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.

I like that [snapshots] isn’t some brand new concept that you somehow have to get the whole community behind, it’s something that’s already being done. Just needs a little marketing crack behind it. If it were me, I’d hire a content strategist and a designer, and get them going on a microsite or landing page that delivers with crystal clarity what “CSS2019” is. I could get behind that. The snapshot landing page as-is is too dry.

@stubbornella
Copy link

@stubbornella stubbornella commented 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
Copy link
Author

@jensimmons jensimmons commented 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
Copy link

@davatron5000 davatron5000 commented 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
Copy link

@tallys tallys commented 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
Copy link

@chriscoyier chriscoyier commented Feb 12, 2020

It's been so long since CSS3, the list is pretty deep.

The big ones:

  • Flexbox
  • Grid
  • Custom Properties
  • Variable Fonts
  • Logical properties

smaller:

  • Filter / Blendmode / Backdrop?
  • Independent transforms?
  • Color function adjustments?
  • Columns changes?
  • clipping / masking?
  • focus-visible / focus-within?
  • ::marker and list-style stuff?
  • object-fit?
  • scrolling stuff like scroll-margin, overflow-anchor, etc?

And what is the criteria for inclusion? Supported in 2 of 3 major engines or however we refer to it these days?

@rachelandrew
Copy link
Contributor

@rachelandrew rachelandrew commented 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
Copy link

@mbarker84 mbarker84 commented Feb 12, 2020

I agree with @tallys:

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.

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
Copy link
Contributor

@bkardell bkardell commented 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
Copy link
Contributor

@mirisuzanne mirisuzanne commented 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:

  1. Establish some criteria that work well for a first release (CSS4, or CSS 2020, or …?), and flesh out the list of features included.
  2. Determine the format of a public "release" of this kind, and flesh out the first version. Unlike CSS3, it's not a spec – so what is it? A list of module-versions? A sort of snapshot based on support rather than on date? A summary or microsite of some kind? As in the discussion @AmeliaBR linked, what is the proper balance for a useful entry-point without requiring heavy ongoing maintenance?
  3. Develop a plan for future releases (velocity, naming, etc) based on what we learn from compiling the first.
@Crissov
Copy link
Contributor

@Crissov Crissov commented Feb 13, 2020

JFTR: #4752 #4715

@Crissov
Copy link
Contributor

@Crissov Crissov commented 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:

  • Web Typography
  • Web Layout
  • Web Media
    • Web Graphics
    • Web Coloration
    • Web Animation
  • Web Interaction, Web UI
  • Web UX

These would also include (parts of) other specs like HTML, SVG, JS and HTTP if necessary.

@huijing
Copy link
Contributor

@huijing huijing commented 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:

  • [CSS is] generally perceived as stale (@davatron5000)
  • new features in CSS might not really be production ready (@tallys),
  • not aware of newer CSS specifications, don’t realise how well-supported they are, or don’t have the time to prioritise learning them (@mbarker84)

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
Copy link
Collaborator

@SelenIT SelenIT commented 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":

Year "Revision" Features added
1996 CSS1 Basic concepts of CSS: cascade, type, class and ID selectors, link pseudo-classes, :first-line/:first-letter, box model, block and inline formatting, floats, font properties, #hex and rgb() colors, absolute lengths, em and ex units, "reference pixel"
1998 CSS2 Attribute selectors, :first-child, :before/:after, > and + combinators, @media, @page, table model, cursor, outline
2007 CSS-2007, or "CSS3" display:inline-block, new attribute selectors, :: for pseudo-elements, :last-child, :nth-child() etc., :empty, :target and :not(), ~ combinator, hsl(), currentColor and opacity, CSS Namespaces, style attribute standard
2010 CSS-2010, or "CSS4" Media Queries 3 (width, orientation etc.)
2015 CSS-2015, or "CSS5" CSS Syntax 3, nested @media and @supports, CSS Cascade 3, new units from Values and Units 3 (incl. px as absolute), calc(), multiple backgrounds, border-image, border-radius, linear and radial gradients, web fonts, Multi-columns, mix-blend-mode and isolation, updated cursor and outline, Transforms, Animations, Transitions, Flexbox
2017 CSS-2017, or "CSS6" Writing modes 3, CSS variables, CSS Text 3, :dir() and :lang() pseudo-classes, min-content and max-content
2018 CSS-2018, or "CSS7" CSS Grid, will-change, filter, easing functions, logical properties, conical gradients, :focus-within pseudo-class
2020 CSS-2020, or "CSS8" contain, ... (to be continued)

Doesn't this make sense?

@zeldman
Copy link

@zeldman zeldman commented Feb 13, 2020

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.



@NOVALISTIC
Copy link

@NOVALISTIC NOVALISTIC commented Feb 13, 2020

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 believe this work should start with a conversation with Authors

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.

Would it help to officially define CSS4, and what’s in progress for CSS5?

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.

@folletto
Copy link

@folletto folletto commented Feb 13, 2020

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

@jeremyfuksa
Copy link

@jeremyfuksa jeremyfuksa commented Feb 13, 2020

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.

@pp-koch
Copy link

@pp-koch pp-koch commented Feb 13, 2020

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.

@ienjoy
Copy link

@ienjoy ienjoy commented Feb 13, 2020

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.

@tzi
Copy link

@tzi tzi commented Feb 13, 2020

Thanks @jensimmons for creating this official discussion!

I vote for a new CSS version, because as a French CSS developer:

  • I witnessed very few books in France since CSS3 (except Flexbox & Grid)
  • I witnessed very few training request since CSS3 (except Flexbox)
  • I witnessed very few interest from JS developers since CSS3 (except Flexbox)

I vote for a yearly snapshot because it's predictable, regular, and it makes a breaking change with the old version number.
For the question of how the author will know which CSS they can use, I think the browsers will be very happy to announce their full support of CSS2018 or CSS2020, since it's very good for marketing. So I'm not afraid of this.

@impressivewebs
Copy link

@impressivewebs impressivewebs commented Feb 13, 2020

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:

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

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!

@amazingrando
Copy link

@amazingrando amazingrando commented Feb 13, 2020

Puts on designer/marketing hat as I read this thread, so I'm jotting down some HMW's:

  • How might we get people excited about new CSS features, so that we spark new investments into CSS, education, and implementation?
  • How might we do this in a way that respects the true status of CSS specs?
  • How might we accomplish this with the resources and people we already have?
@fantasai
Copy link
Collaborator

@fantasai fantasai commented Feb 14, 2020

I don't think that it's the place of the CSSWG to tell authors what is ready to use on their websites

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.

Let's think in terms of cycle of adoption and education, which I feel have a 2-5 years cycle

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. :)

@scottkellum
Copy link

@scottkellum scottkellum commented Feb 14, 2020

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 transform-style from the still in draft transforms level 2 recently broke in Safari. Finalizing and adopting drafts like these would be nice.

@ahmadalfy
Copy link

@ahmadalfy ahmadalfy commented Feb 14, 2020

I am in favor of the proposal but I keep thinking about how are we going to transition everything that was modularized before?

@Crissov
Copy link
Contributor

@Crissov Crissov commented Feb 14, 2020

@ahmadalfy Nothing about the modular structure of CSS specifications needs to change nor will it change.

@Crissov
Copy link
Contributor

@Crissov Crissov commented Mar 9, 2020

A book about “HTML and CSS from the 00s” would probably use XHTML. ;)

“HTML5” means anything after Hixie/WHATWG took over, and likewise “CSS3” means anything that came after modularization of the specification (also mostly post Hakon Wium Lie and Bert Bos).

@awford
Copy link

@awford awford commented Mar 10, 2020

For developers building internal web applications, we are frequently locked into much older browsers, meaning no need to frequently check for new standards. I stopped looking after CSS3 came out. With no version number to tell me something has changed I have no compelling reasons to look for a new standard. Too much to stay on top of. If a CSS4 book showed up somewhere I would simply know it was ready for study. I've seen many discount this as "marketing". What product isn't concerned with marketing? What is the point of putting all this work into new standards and features if there is no clear way of announcing their availability? For that matter, what is wrong with sub-versions? If 3.1 supports flexgrid and 3.2 adds in "gaslight marquees", that's definable.

Obviously, I'm not heads down in the WG, but to stumble onto this discussion is both surprising and concerning. From the outside looking in it sure seems like beaucracy is winning what should be revision management 101. Maybe a new W3 standard for version control is what's called for instead, because this is the kind of mess a standards body was meant to avoid.

@awford
Copy link

@awford awford commented Mar 10, 2020

Side note: "CSS 3+ Just Keeping Up" doesn't work well on a resume skillsets list. It doesn't say anything. CSS4 is a definable threshold when looking to hire specific skills. Version numbers affect so much more that the technical standards. Until I stumbled onto an article about this discussion I was unaware there had been progress since CSS3 or that versioning had been dropped. That's a failure both on my part and on the CSSWG's part. I'm unaware of anything in development more useful than clear revision and release communications. You could add a ton of features and fixes but without adoption it seems like a great deal of wasted effort.

@awford
Copy link

@awford awford commented Mar 10, 2020

I wrote this up with a bit more background context for Smashing Magazine, thinking we might have a slightly broader audience for comments.

Thanks, your article is what brought this to my attention

@rickgregory
Copy link

@rickgregory rickgregory commented Mar 10, 2020

With all due respect to @benfrain and other authors, the issue of book titles is entirely secondary. If you choose to add a version into the title, that's your (or your publisher's) problem and thinking that CSS should or should not use versions because of the effect on such things is "tail wags dog" land.

The heart of the matter to me is this - CSS adds things continually. Some of these are very minor edge cases. Some are major additions. Some are in between there. Right now, working developers have no organized way to track these additions and their support status. We might run across something by accident, think it sounds cool and find it's widely supported. Or find that it's Chrome only. Or... well you get it. Because of this, I think there's a lot of good CSS features that aren't getting the use they could get because most working devs simply do not have the time to haunt the WG's communications and there's nothing like a clear, organized feed summarizing new features and how widely supported they are.

Versioning is about two things. One, letting practitioners know what features both exist and are broadly supported in current browsers. Two, communicating to the edge players (designers, product folks, managers) that there's a new bag of features that it's safe to use. IF the WG and others want their work to be used widely, some kind of versioning will, I think, help that. Otherwise you have people working very hard to push CSS forward and seeing that hard work reach only a fraction of its potential audience.

@bkardell
Copy link
Contributor

@bkardell bkardell commented Mar 10, 2020

Not trying to discourage discussion on this issue but just to mention again, as it is obscured by comment collapsing now, that a wc3 cg was formed to discuss this topic exclusively

https://www.w3.org/community/css4/

Looking at the group and the associated mailing list I don't see any of these comments being brought over there so I'd like to make sure people are aware that it exists, has a mailing list, anyone can join, etc...

@fchristant
Copy link

@fchristant fchristant commented Mar 10, 2020

@rickgregory

"I think there's a lot of good CSS features that aren't getting the use they could get because most working devs simply do not have the time to haunt the WG's communications and there's nothing like a clear, organized feed summarizing new features and how widely supported they are."

I don't entirely agree with this premise. I do agree that there's CSS parts that are not known well enough and therefore are underused, which indeed is a waste.

Yet I don't agree that this is due to a lack of tools to get to this information. Subscribe to any of the top 5 front-end newsletters or main web development blogs and it's impossible to miss what is going on with CSS. Spend the bare minimum of 30 mins per week and one will know what's going on. You won't master each topic, yet you will at least be aware that they exist.

When developers don't bother to use these channels, it may be due to other reasons. A general lack of interest/passion, being unaware of them (which means they didn't even try), or taking the very popular JIT approach to web development.

What I'm saying is that a well written, well organized CSS4 resource certainly won't hurt, yet the idea "build it and they will come" seems naive to me. There are already a ton of excellent educational sources out there. If these currently fail to reach a particular audience, I don't see how another new one would change that. Based on a version change only.

@benfrain
Copy link

@benfrain benfrain commented Mar 10, 2020

I don't necessarily disagree with @rickgregory sentiments. I do however, think it is perhaps idealistic.

That approach was largely the way CSS3 went down. And it was not without problems.
The state of things being 'ready' or not was no different when we were all saying 'come and try CSS3'. You still had to check support, weep, and create workarounds for any semblance of cross-browser compatibility — and deal with vendor prefixes for extra fun ;)

Perhaps I am being overly cynical but saying it is CSS4, CSS5, CSS2020 etc is unlikely to change the reality of how these things are implemented. Stick what you want on a roadmap and give it a name. Even get all browsers to agree to it, but I don't think it is going to change the way 'the sausage gets made'. If a feature suits the business needs of one browser but not another, you aren't going to see it implemented. And that leads to 'CSS4' failing in the eyes of devs because 'you can't use it yet'.

I'm not saying that's good but I do think it is the reality we live in.

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

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

If you want more noise making about it then we all need to start making books with 'CSS4' in the title ;)

@benfrain
Copy link

@benfrain benfrain commented Mar 10, 2020

@bkardell Hi Brian, sorry for the naive (genuine) question but what does joining that offer that we don't get here?

@bkardell
Copy link
Contributor

@bkardell bkardell commented Mar 10, 2020

@bkardell Hi Brian, sorry for the naive (genuine) question but what does joining that offer that we don't get here?

As I understand it, this is where such decisions and definition would happen. Since it references this issue as the start, and many of the people on this thread have joined.. maybe all of this is findable and it's fine? But a cg let's this group organize, collaborate, create documents, and have a bunch of infrastructure, like a blog and a mailing list and so on. There are other benefits for other problems (like IP related stuff) but I don't think they apply much here given the scope.

@peppergraphics
Copy link

@peppergraphics peppergraphics commented Mar 11, 2020

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

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

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

@rickgregory
Copy link

@rickgregory rickgregory commented Mar 11, 2020

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

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

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

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

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

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

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

Emphasis added... :)

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

@fchristant
Copy link

@fchristant fchristant commented Mar 11, 2020

@rickgregory

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

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

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

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

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

@rickgregory
Copy link

@rickgregory rickgregory commented Mar 11, 2020

@rickgregory

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

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

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

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

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

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

@JoshuaLindquist
Copy link

@JoshuaLindquist JoshuaLindquist commented Mar 11, 2020

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

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

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

@fchristant
Copy link

@fchristant fchristant commented Mar 11, 2020

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

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

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

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

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

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

@TimVevida
Copy link

@TimVevida TimVevida commented Mar 12, 2020

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

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

@JoshuaLindquist
Copy link

@JoshuaLindquist JoshuaLindquist commented Mar 12, 2020

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

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

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

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

@XorAndre
Copy link

@XorAndre XorAndre commented Apr 24, 2020

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

@Kaffesumpen
Copy link

@Kaffesumpen Kaffesumpen commented Apr 24, 2020

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

@laukstein
Copy link

@laukstein laukstein commented Apr 25, 2020

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

@XorAndre
Copy link

@XorAndre XorAndre commented Apr 28, 2020

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

@Nixinova
Copy link

@Nixinova Nixinova commented May 30, 2020

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

@lazarljubenovic
Copy link

@lazarljubenovic lazarljubenovic commented May 30, 2020

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

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

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

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

@Nixinova
Copy link

@Nixinova Nixinova commented May 30, 2020

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

@lazarljubenovic
Copy link

@lazarljubenovic lazarljubenovic commented May 30, 2020

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

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

@XorAndre
Copy link

@XorAndre XorAndre commented Jun 3, 2020

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

@JakubKubista
Copy link

@JakubKubista JakubKubista commented Jul 5, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.