search

w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.35k stars 640 forks source link

Let’s Define CSS 4 #4770

Open jensimmons opened 4 years ago

jensimmons commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

+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 commented 4 years ago

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 commented 4 years ago

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

The big ones:

smaller:

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

rachelandrew commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

JFTR: #4752 #4715

Crissov commented 4 years ago

TL;DR: Introduce versioned “Web …” authoring competency profiles instead.

I was a fan of modularization when it started after CSS 2.0. However, not everyone had the same idea how it would or should work. In my opinion, we should have had started with splitting the existing spec into parts without adding anything new, but in reality, almost twenty years later, some modules and some external specs still need to reference CSS2. Another effect was that it took like a decade for the WG to agree that modules that build upon Level 2 would start at Level 3, whereas completely new modules would start at Level 1, despite “CSS3” being the popular term. Some modules are at Level 5 now (or soon). That is why I believe that “CSS4” in particular would not be a good marketing term.

We originally had some Profiles of CSS (e. g. for handhelds, TVs and printers) that bundled certain modules and, unfortunately, also picked single features out of other modules, which together would need to be supported to claim conformance. It was thought okay to not support entire modules if it did not make sense on the platform or for the vendor – nowadays we are closer to a monolithic ubiquitous and open “libcss” that tries to support everything than we ever were, despite some forks and a good, mature and also open alternative.

Today, all we have are supposedly annual snapshots released by the CSSWG for implementors and external sites documenting real-world support by custom criteria. Common, reliable test suites for objectively determining conformance are still regarded of secondary importance by many.

I did consider to suggest a numbering system for “CSS” that significantly differed from classic Levels, which individual modules shall continue to use, and did not imply annual updates which – letʼs be honest – the WG will never finish in time anyway. The system I preferred was loosely based on browser version numbers: CSS n would be (roughly) what could be assumed to work sufficiently well in all of Edge/Chrome version greater than 10×(n+1) and Firefox in greater than 10×n. The current state would therefore be between CSS6 and CSS7. I came to the conclusion that this is too unintuitive and unreliable, though.

What I do suggest are entirely new terms for bundles/profiles/sets of (ideally only full) modules, versioning independently of CSS module levels:

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

huijing commented 4 years ago

I think @davatron5000 raises a salient point about how the TC39 chose to handle ECMAScript with "big" releases of each version seems to be received well with many people. But I think the key difference here is that CSS was modularised, which makes it tricky to do something similar like a CSS2020 or even CSS4 as per the original suggestion.

There is also a significant difference for the Javascript eco-system that goes beyond perception alone, which is Babel. Developers generally feel safe to use all the latest and greatest ECMAScript features because Babel is there to take care of the cross-browser/backward compatibility issues for them.

In relation to this idea, I find myself agreeing with @rachelandrew that the issues with adoption of newer CSS properties are also significantly dependent on how and when browsers implement them, especially browsers with significant market share. I'm very much for more explaining about the process.

That being said, I feel that I do have a significantly subjective emotional connection to CSS that perhaps clouds my perspective, which is one the majority of web developers probably do not share. The crude analogy I can draw here is you cannot unlearn how to ride a bicycle. And for me, understanding the process and embracing the varying levels of browser support is the bicycle I have learned to ride.

What is the best way to teach the general web developer how to ride this bicycle as well? But I suppose the heart of this topic to begin with was how to even get the general web developer to want to ride this bicycle.

The points I've seen repeatedly mentioned by people above this comment thread are:

And I agree with these observations because I see them often as well. I'm just not sure if CSS4 is the appropriate way to trigger "excitement" or push web developers to learn more.

SelenIT commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.

jonbell-lot23 commented 4 years ago

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 commented 4 years ago

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. 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 commented 4 years ago

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 commented 4 years ago

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

fantasai commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

Crissov commented 4 years ago

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

swyxio commented 4 years ago

Hello - causal observer here! excited by this discussion.

Since @AmeliaBR and @mirisuzanne already brought up the idea of yearly versions instead of major versions, I just wanted to introduce the idea of talking to TC39 to learn from their experience. No doubt many here already do so I'm not sure if my comment has any value at all, but AWB and Brian Terlson had this fascinating exchange last year where they discussed the pros and cons of the yearly release model (not tagging them bc idk if they want to be pulled in here). For example something that seems to be naturally emerging is themed "waves" of features for more coherent design.

If we do this, regardless if we call it CSS4 or CSS2020, we're gonna need a plan for CSS5 or CSS2021. Could do worse than learning from the experiences of TC39. i agree with basically everyone here that keeping to a 5 year cycle minimizes churn and maximizes impact.

jensimmons commented 4 years ago

To be clear — both in response to @ahmadalfy's comment, and to some reactions I saw on Twitter: no one is proposing that the CSSWG put all the separate specifications back into one giant (now-extra-giant) single spec. That would change how the CSSWG works, and create a significant impediment to their process.

It's true, CSS1 and CSS2 were specs that had everything. CSS3 basically consisted of all the newly-separated specs, that had all been incremented to Level 3. Since the splitting-out of the specs, brand new specs (like Flexbox) are started at Level 1. Some of those have reached Level 2, even 3. Some of the other specs went on from Level 3 to 4 or 5... (For anyone who's unclear about this, I explain it with more detail in this video.)

If we define CSS4, it will include some specs that are at Level 1 or 2 (Like Grid 1 and Grid 2). It will include some specs that do happen to be at Level 4. It may include somethings that were added to a Level 3 spec much later than "CSS3", or include work that's in a Level 5 spec.

“CSS4” will be an umbrella term, meaning a bucket of stuff that happened roughly between 2011 and 2020, without any regard for the actual Level of the individual specs included. And it will have no impact on how individual specs are created or numbered by the CSSWG.

bkardell commented 4 years ago

I'd like to clarify my position somewhat. I see the value in what people are suggesting. At the same time I also think that "CSS4" is bound to cause confusion for precisely the reasons @jensimmons just listed. My own thought here is that calling is "4" isn't necessary and it's probably less than helpful for the inevitable confusion it causes. Many other kinds of names could work for this purpose. I had said "css-2020" not because I meant an annual thing (though... there could be a world in which identifying the things we were all concentrated on trying to land is valuable maybe) but rather in order to break the naming system issue. If we identify "css-2020" now and don't have another until "css-2023" or "css-2025" -- that seems fine? The point is just no one can get confused with the existing or old versioning schemes here.

fantasai commented 4 years ago

@bkardell Calling the next collection of modules CSS4 has a few benefits over year names:

jensimmons commented 4 years ago

@bkardell just wrote:

I also think that "CSS4" is bound to cause confusion for precisely the reasons @jensimmons just listed. My own thought here is that calling is "4" isn't necessary and it's probably less than helpful for the inevitable confusion it causes.

I don’t agree that labeling things from a Level 1, 2, or 5 spec as “CSS4” will be at all confusing to Authors. Why? Because 99.9% of Authors have no idea that CSS is born in specs that have Module Level numbers. Some of the biggest fans and best teachers of CSS Grid have no idea what's in Grid 2 vs Grid 1 & Grid 3. (Rachel knows. I know. But we are both on the CSSWG.)

Web designers & developers don't care. Spec level numbers are not part of any conversation Authors have. It's the CSSWG who knows the level numbers by heart, and refers to them as a thing. It might be hard for CSSWG members to understand how little this will matter — but it won't matter. Authors will not be confused.

ExE-Boss commented 4 years ago

If we do use year numbers, then I’d prefer if we use the Holocene calendar (Gregorian + 10000):

12020 HE = 2020 CE

shaunrashid commented 4 years ago

I have been debating this in my head for the past week. Based on recent experience within the company I work for, I do think that packaging groups of CSS modules into "marketable" versions has more benefits than drawbacks especially when it comes to having the priority conversation with non-technical (or even non-frontend) stakeholders.

A recent example is that the team wanted to introduce custom properties into our code base. Using "CSS4" with stakeholders allowed us to frame the discussion as an upgrade as opposed to wanting to use a particular technology. The conversation with stakeholders is much more straight forward when we can say that we want to "upgrade to CSS 4.x" and outline the specs that make that up as opposed to we want to upgrade to use "module A, version 3", "module B, version 2", "module C, version 2".

While technically it makes no difference, I feel like having these "versioned groups" allows people who are not familiar with the specs to grok and scope what it means to adopt newer levels of the specs.

shaunrashid commented 4 years ago

On the question about who should be determining what "CSSx" is, I agree with @rachelandrew and @fantasai that it should be the authoring community that defines it. They are the ones writing the code on a day-to-day basis.

I also think it is also the responsibility of the authoring community to have a general understanding of how the specs are organized/released so that they can make informed decisions on what the "versions" should be as well as enable them to push on browser makers to prioritize/implement specific specs so that the versions can be practically adopted.

mzaini30 commented 4 years ago

I hope there's .parent() in CSS

bkardell commented 4 years ago

Calling the next collection of modules CSS4 has a few benefits over year names...

@fantasai Yeah, I debated whether or not to use `a year name again even because, as I said - many kinds of names could work, and I'm not actually trying to suggest one as much as that it might be valuable to break with the current naming a to avoid confusion. Is that valid or valuable enough..... idk, honestly.

99.9% of Authors have no idea that CSS is born in specs that have Module Level numbers.

@jensimmons We spent a really long time publishing "there is no css4" stuff... Google returns a lot of pieces on this. The actual drafts and MDN documentation and posts and presentations and talks that say 'level 4' or 'level 5' or whatever -- that's all I mean: There is lots of opportunity for confusion floating around out there already. Again... does this really matter.. idk?

Please don't read too much into any of these replies: I don't feel super strongly on any of this and i'm definitely not trying to be argumentative about it. I just wanted to make sure that my own worries/thoughts were properly expressed. I fully agree that there are many very good points in this thread and I'm very happy to accept whatever the group/community decides here.

mandymichael commented 4 years ago

There are a lot of good comments here and I am torn between the options...for what it's worth though I agree with the statements around it helps the wider community understand that there are new features/ CSS suffers a lot from people not knowing that new things have been added, and as a result people keep focusing on older techniques that are not ideal, this often reinforces negative opinions about CSS.

When you move in circles of people who are deeply embedded in the CSS community it’s easy to think that people know and understand everything that CSS has to offer (or what is coming up) but in my experience we are the minority, not the majority. I consider myself to be fairly “in the know” about different CSS additions/upcoming features, but I don’t think the decision should be made based on someone like me. I would not be the target audience for a system like this, and it wouldn’t really be of any benefit to me either.

Thinking about it from that perspective, and given that CSS is already perceived as very different from other languages, I believe the best approach would be to choose a method that is easily understood by the vast majority (e.g. a standard versioning approach)

Reading through everyone’s comments there are excellent points for and against. But I also think we should think about this from the perspective of a back end developer who typically relies on bootstrap, or a developer who doesn’t have time to read up on blog posts and follow industry experts on twitter – the people who just need to get stuff done. It is largely a marketing approach, sure, but if we want people to love CSS as much as we do, then we need to show them why in a way that is easily digestible, and I'm not sure we can say that the current approach accomplishes that.

bkardell commented 4 years ago

One last point here which I realized I have failed to articulate but is maybe important... We have in the past wanted a 'label' like this and as @zeldman notes - lots of terms have come from the developer communities "Web 2.0" "AJAX" and "Responsive Design" all being great examples of similar things from the past that seem to have a lot in common with the ask here. It would seem to me that is it very possible for the community to actually try this today and this has the advantage of being non-speculative. I mean, I could imagine labels like "CSS Epsilon" and "CSS Delta" might even work - but that is just total speculation. However, if someone tries to do this, and whatever they call it or whether that even involves numbers in any way feels unintuitive, it seems to me the community will naturally pivot, offer alternatives and redirect more naturally and arrive at something which at least has some data "enough people seem to get this". And then we can, if we want, write it down - like dictionaries do -- officially... or even just use it. CSS WG members freely use terms that aren't born in standard or written down rigidly somewhere like "responsive design".

So I guess my question is: Is this an issue for the CSSWG, necessarily? At this stage? Later? Or is it just a way to discuss whether there might potentially be something that someday could be? Or...?

marekgebka commented 4 years ago

While agreeing that promoting the current evolment of CSS as a version 4 might re-create the former buzz of “CSS3”, let’s not ignore the fact that also many professionals weren’t able to use these then new features due to project constraints such as browser support and stubborn project- or tech-leads. I used to work for a company back then that forbid the usage of vendor-prefixes and every single CSS3 feature due to a “lowest common denominator approach” of ensureing browser support, as it was seen as a way to avoid “extra work”. The last agency I worked for, to this day, is trying to avoid flexbox since it is “hard to understand” and “is behaving unpredictably”. Although we have new and more efficient ways to progressively enhance our websites etc. I can imagine that this would still be a reality for a lot of developers out there. Also, perhaps you have noticed the usage of the word “might”. The status of JS back then was also a bit different. So I have serious doubts if CSS4 would actually create the same marketing effect today that CSS3 was able to generate.

Also I am afraid that browser vendors might slow down when it comes to implement these new features since it then would make sense to wait until a new version is “complete” of “worth” supporting. Grid IMO was so successful because it solved a decade old problem CSS devs were facing but also due to the fast pace in which the browser vendors were picking it up (and great learning material by Jen & Rachel etc.).

I’d personally like to see a just as lively discussion about how we could push CSS & progressive enhancement more as a whole than CSS4 etc. since it feels like the more concrete lever to pull here.

syriaca commented 4 years ago

TL;TR thread, but it is a very interesting subject.

The main question coming to my mind is: where end CSS3 and where begin / end CSS4 ? Who must define that ?

laras126 commented 4 years ago

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

Speaking from a developer and CSS teacher/advocate perspective, YES!!

And per the other conversation here, I love the prospect of continuously versioning CSS. Versioning is a familiar practice among other programming languages, and one that I believe would encourage developers outside of "the inner-CSS circle" to take CSS more seriously, and to approach it as a true language. (similar to points from @mandymichael)

On my team (and many others), there is a lot of reliance "the CSS person" to be in the know regarding new CSS features, and to decide what to incorporate into a code-base and when. I believe consistent, ongoing versioning would help make CSS more accessible to more developers, and provide a much clearer update path for applications like design systems and UI frameworks. "What new CSS should we use?" is a current conversation in the WordPress core community, and an explicit version and changelog would be extremely helpful.

What goes into those two buckets?

I am not intimately familiar with different levels and status of new parts of the spec, so this is very high level, but perhaps useful from developer's perspective and for thinking in buckets:

CSS4 (features most developers are aware of / starting to use regularly):

CSS5 (things uncommon outside the "inner-CSS circle", or things that are still in draft stage):

In terms of how the versioning works, there are many options for versioning out there in addition to JavaScript's – WordPress, PHP, and Python are a few that come to mind for me, or – potentially better idea – reference languages that share characteristics with CSS (declarative, domain-specific), like SQL.

If a decision is made to consistently version CSS (I hope! 🤞), perhaps a next step could be outlining some different options for versioning and requesting community feedback via a formalized questionnaire?

rickgregory commented 4 years ago

Some thoughts from a humble developer...

I try to keep up but frankly, I learn about the new things that solve problems for me and often discover new CSS features while searching for a way to do something. That's got advantages - I spend less time learning things that aren't useful to me now - but of course I sometimes learn of something new and think "I could have used that in [list of projects]...". But as a day to day author, I simply can't spend the time to learn of new things, play with them and then not use them, especially if, when I hear of them, they're only supported in Chrome Canary.

So, yes, if a CSS4 gets browser vendors on board to full support a list of features, that would be great. However, I do think that we'd need to see new versions at least every 3-5 years. Decade long pauses aren't really going to solve anything.

In some ways, this is a solved problem. Back in the boxed software days (yeah, I'm older... ), a major revision (3 to 4) meant that the release had big new things in it. A dot revision (.0 to .1) meant there were noticeable new features but they were smaller. A really minor revision (.00 to .01) was often a bug fix release to the corresponding dot revision.

So, what's wrong with porting that logic to CSS? CSS4 would have Grid, Flexbox, etc. 4.1 would have smaller enhancements (I like @chriscoyier's list above). I don't think we need annual version revs, though. @davatron5000 said upthread that "...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...." and, honestly, I'm not sure that's a positive thing. Think about it from a front line perspective... do you need to keep on top of (counts....) NINE different versions that have all happened in the last 4-5 years? Is there engouh significant difference from one to the next to really deserve a version rev?

mateusfg7 commented 4 years ago

how works CSS4 in react? :thinking:

andreluizmartinsramos commented 4 years ago

Hey Guys!

I'd love to have :parent selector. :shipit:

eric-dos-reis commented 4 years ago

Great idea, it will be amazing if we have a new version of CSS every year, like EcmaScript:

CSS2018, CSS2019, CSS2020 ...

Please, think about it.

davidfitzgibbon commented 4 years ago

The effort of maintaining this sounds crazy for all you lovely people who actually do this work ( so far I havent contributed ).

What if we just made a list of when each functionality was released? I've made an extremely crude and poorly researched example of what that could look like here: https://cssiv.net/

I've called it CSS IV to mean CSS Inferred Versions. We can infer a versioning, without putting lots of people volunteering time to "waste".

That's if it is to be purely for people to use CSS4 / CSS2020 as a marketing tool. I see @jensimmons has set out a proposal for a group for CSS4. I hope the efforts of those who volunteer for that group come to something truly educational ( like Jen's own videos for the Mozilla Dev channel on YouTube ).

luiscobot commented 4 years ago

I'm not a senior dev, but I want to say that it would be good to also design generic logos for css and html (without versions)

The current "semi" official logos: image

troxler commented 4 years ago

Having "releases" probably would make the discoverability of new features easier, at least for people who are not that deep into CSS. Having said that, I personally mostly agree with rachelandrew's comment. I think that better explaining material would help more.

With the existing CSS Snapshots (e.g. CSS Snapshot 2020), there is already some "versioning". But most people probably do not read those specifications and are more interested in what actually changed in between those snapshots. To make those more visible, I envision a document similar to release notes. But it might go more into the direction of "CSS Recommendations", i.e. it includes only features whose (as zeldman suggested) "spec was stabilized when at least two major implementations supported it". For example, "CSS Recommendations 2020" might include all new specs since the previous "Recommendation" that have at least two major implementations. In addition to that, some things have to be explained in very simple terms:

So essentially such a document goes into the direction of CSS IV as mentioned by davidfitzgibbon but with more emphasis on the spec's stability and adoption.

I put "Recommendation" in quotes as I'm not sure this would a good name. And I know that this is exactly what rachelandrews argued against. Maybe such a document could be published outside of the official CSSWG channels (maybe on MDN?). But then it might also lose some of its marketing goal.

Off topic:

@davatron5000 @rickgregory

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.

That is not true (or at least very misleading). As of ES6, new ECMAScript specs were released in a yearly schedule (i.e. there is one new version each year). Since 2015 they released ES6 (=ES2015), ES2016 (=ES7), ES2017 (=ES8), ES2018 (=ES9), and ES2019 (=ES10). ES.Next is not a standard but a working draft.

Crissov commented 4 years ago

One kind of versioning has not been mentioned yet: arbitrary and opaque code names like the large cats and now Californian landscapes Apple is using infamously for their desktop OS or the sweets that designate major Android (API) releases. I think Ubuntu has a similar system as Google, wherein the initial letter is increased alphabetically, so it is not completely arbitrary in fact.

Example

  1. CSS Level 1: CSS Aquamarine
  2. CSS Level 2: CSS Blue
    1. CSS Level 2 Revision 1: CSS Azure Blue
    2. CSS Level 2 Revision 2: CSS Baby Blue
  3. CSS Level 3, e.g. Defined as all modules that started at Level 3, because their features were already in Level 2, and that reached CR before 2015: CSS Cyan
  4. The current stable state: CSS Dew

PS: Texʼs version numbers are increased by adding another significant figure of an irrational constant like e or π, but that is hardly a good model for CSS.