Re: [csswg-drafts] Let’s Define CSS 4 (#4770)

I've had more time to think about this idea, and my thoughts are evolving. I am still overwhelmingly in support of doing _something_ to make new CSS easier to discover, learn, and understand.

>
>In order to achieve better browser support for new CSS features,  as @huijing mentioned above, we miss Babel compared to the JS ecosystem. Therefore, from this point of view, we can't expect CSS4 to gain the same traction as ES6 and so on.
>

I don't think better browser support is really an issue right now. There are many features of CSS that are already implemented in all modern browsers (and have been for years) that would likely be included in the CSS4 proposal. Considering the rapid pace of browser development, I think it would be beneficial for any CSS4 (or 5 or 6, etc.) proposal to _only_ include features that are already implemented in at least two rendering engines.

This would differ from CSS2/3 where the browsers were left playing catch up. Since CSS4 is about marketing, we really don't need to use it to pressure the browsers at this point. We need to use it to advertise the features that are already available that many authors are not currently using.

>
> Authors would need to edit all the existing content on "CSS4 is not a thing that exists" or "There is no such thing as CSS4"
>

I don't think this is a compelling argument. The web is littered with outdated articles on any number of topics. Some authors might choose to add a disclaimer to outdated articles - and maybe we want to encourage that for articles written by members of the working group (e.g. Tabatkins article that was previously referenced) - but that's an exception more than a rule. Most websites didn't remove or update all of their articles from the CSS2 era about how to add rounded corners on boxes before border-radius. Those articles just exist forever.

>
>It's hard to properly draw a line where CSS3 "stopped" and CSS4 "began". How about CSS5 and so on? Who will draw and maintain those lines e.g. which is where?
>

This is definitely one of the topics that will need to be discussed. But my understanding (and I could be wrong) is that CSS3 began when the specification was modularized. Existing specifications were given "Level 3" at that time. I think everything that began modularization at Level 3 is a part of CSS3. Anything that came afterward (either Level 4 of those same specifications or new specifications that started at Level 1) would be under consideration for inclusion in CSS4, etc.

>
>A more pertinent question becomes which newer features to include in the CSS4 spec. At Lighthouse, we don't have any particular opinion on which features we expect in CSS4, but for marketing purposes, it seems apparent to us that the spec include, at the very least parent selectors. Again, the working group doesn't have to have finalized the nature of these features at launch to change the name.
>

I think @srsgores demonstrates a legitimate issue with the name CSS4 or creating a new designation at all, but it all boils down to communicating intent. While in favor of the idea, srsgores quickly asked that CSS4 include actual **new features that do not exist in any spec at the moment** (in this case, parent selectors/container queries). My immediate understanding of this proposal was that the actual intent is to package features under a new name and say "Everyone, this stuff is ready for primetime!". 

When discussing authors that do not keep up with the latest developments, I think this approach will be simple to understand. Everything will _feel_ like it's brand new to them, even though some of these features, like Grid and Flexbox, have been in browsers for years. 

But anyone who does keep up will likely be confused about why there is a "new" specification full of things that are actually old.

I think this is a solvable problem. It's just something to be aware of.

>
> Now we'll have "CSS Grid Level 7 is part of CSS 5"? Sounds like a great idea! Let's confuse everyone! 
>
> Just drop the numbers already. It's CSS, an evergreen language. When someone asks you what's your primary browser, you say Chrome, not Chrome79. Your library of choice is React, not React16.3. **The version number is useful for developers.** It's a technical detail. 
> 
> If I understood correctly (I obviously didn't read everything in the thread), basically the ain driving force behind this idea is "previously the name HTML5 helped push browsers". Yes, it helped push browsers from dark ages of ridiculous inconsistencies and lacks of specifications. Now we have specifications, and almost every browser is "evergreen", always updating and always growing.
> 

First, it's important to reiterate that no one is suggesting that the modules be removed. This is purely for marketing. The way CSS advances would not change.

The driving force is not to push browsers - it's to help authors understand what is ready to use. Browsers have already implemented important new features, but it's difficult to keep up with what is ready. Most authors do not read the specifications or stay up-to-date with the efforts of the working group. 

As @axelboc mentioned, the easiest way to learn about new features in a browser is to read the release notes (I do the same thing), but how many people are really doing that? And why should that be the way you figure out what is ready? 

I also think the potential confusion about Module Levels vs. CSS# is overstated. I would argue that the average author doesn't know the modules exist at all, and most people that do work with and follow the modules don't really need to care what ends up with the "next version".

> 
> Books based on specific versions of web specs are a thing of the past because the web moves too fast for them. Going back to this model would be doing publishers, schools and novice developers a disservice. Training models need to adapt to living standards, not the other way around. This is already happening in the form of living online books, training courses with regular updates, ... so why go back?
> 

I would label most or all of these things as "unfortunate side effects" or "necessary evils". I agree that we should encourage teaching the living standards and training models should (and possibly have) adapted, but what about all of the authors who are already trained?

I think that's the big concern behind this proposal. There are a lot of people already out there who have written CSS for many years, but that cannot keep up with living standards while also developing full time. How do we let everyone know that there is something new to learn? How will they determine that those new features are worth learning?

> I do agree that something's missing though.
> 
> In contrast, I learn about new EcmaScript features thanks to the TC39 Committee's yearly release process... that list **exactly what's changed in the spec**.
> 
> Selecting a number of CSS Modules at various levels, saying that this is what CSS is at this point in time and giving it some name (CSS4, CSS 2020, whatever) is utterly unhelpful when it comes to keeping up with changes.
> 
> What TC39 got right is **granularity**.
> 
> Unlike EcmaScript, CSS is a set of specs, so what I propose is to **bring this level of granularity down to CSS Modules**. Learning that CSS Fonts Level 3 has achieved _Recommendation_ status tells me nothing. Learning that a specific proposal has reached maturity and been integrated into CSS Fonts, now _that's_ useful.
> 
> Once this level of granularity is in place, the **yearly release train** comes nearly for free as a way to solve CSS' marketing troubles. _CSS Fonts 2020_ becomes the reference point for all the proposals adopted that year into the living CSS Fonts Module, and _CSS 2020_ can just be the collation of all the adopted proposals.

I generally agree with this. Another important thing to note about the CSS4/CSS2020 idea is that it's all completely up-in-the-air. There's no consensus on exactly what it is or should be, and I would argue that it should be something similar to what you have suggested.

The biggest problem is that the initial release may be monstrous in size because it's been so long since "CSS3". After that, I think annual releases would be reasonably sized (or the discussion could move back to releases every 2 or 3 years if larger releases are preferred). 

On that note, after having several days to think about it, **I greatly prefer the idea of using years instead of version numbers**.

I think @axelboc has it right by suggesting that the new version/specification include very specifically what has changed. However, **I think it should ignore the typical W3C recommendation status completely (or mostly)**. Instead, **I think it would be better to include only the features that have been implemented by two rendering engines and are no longer behind flags**. This would give authors a realistic list of features that are actually ready to use, even if the entire specification has not reached Candidate Recommendation. 










-- 
GitHub Notification of comment by JoshuaLindquist
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4770#issuecomment-593188481 using your GitHub account

Received on Monday, 2 March 2020 02:19:32 UTC