Mapping the CSSNext features in web-features

[captainbrosset]

At the August 22nd, 2024 WebDX meeting, we discussed the potential overlaps between the work done by CSS Next CG on categorizing CSS features and the web-features repo. Meeting notes link.

Inline notes

Quentin: [shares context on CSS Next group work on naming new CSS “features” and aligning them with web-features]

Kadir: Anything that could be done for aligning identifiers would be super useful. Since we’ve spoken, things have changed in web-features. A feature may now be part of a group, or a snapshot. Snapshots are things like “ECMAScript 2023”, and could perhaps be used for CSS as well.

Quentin: That sounds interesting indeed. We’re about to publish an update. Once that is done, it would be good to review this.

Kadir: It was still unclear whether CSS4, CSS5, would be aligned with what ships in browsers, or rather with spec maturity.

Quentin: There will be a meeting with the CSS WG in upcoming weeks to discuss that aspect. One example is line-height property without prefix. Something in CSS4 on our side, but cannot be used so far. Also things that are candidates for deprecation but that have never been implemented in practice. It does not make sense to put all the information that we have on our side to your side. Some things where it’s unclear. Some features that don’t have a related MDN page and that are just one-liners in a spec.

Kadir: So CSS4 contains features that haven’t shipped across browsers. Which means that we could track when CSS4 becomes Baseline low and then high. That seems useful.

Quentin: We have that problem indeed where users ask why they would use CSS4 if it’s not Baseline. They are quite old features that don’t have traction in browsers. We think that they should be part of the initial features. Sub-grid is a great example there, it makes sense to put it as part of grids. I see that a bunch of pull requests are opened. I think that we could submit hundreds of them. Who will review them on your end? That’s what I’m wondering about 🙂

Patrick: We’ll figure out a way ;) We’re in the process of growing our list of reviewers.

Daniel: One big difference between what we’re doing in web-features and specification work is that it’s very much oriented towards how developers see things. Developers currently see grids and sub-grids as separate for example. That may change in the future, and we know we may need to merge the features in the end. If you can at least reference feature IDs in web-features, that would be great, and when you find things that don’t have feature IDs in web-features, that should signal we need to do something about it. Help with reviews on naming, descriptions would be helpful. I’m doing a lot of reviews, but I’m not an expert on any single feature. You’re certainly welcome to open PRs, but reviews are also super welcome.

Daniel: We try to have web-features describe everything. To cover a lot of ground initially, we know that we’re skipping a few things such as composition. Grid and sub-grid are a good example. We are right now focused on a slightly lower level. Once we’ve done that work, we may be able to iterate and improve.

Quentin: A good example for a few problems: logical properties. The “inset” attribute came way later than other logical properties. Would you separate them because they shipped at different dates? Would you group them?

Daniel: That’s a good example. I would probably do some research about how developers view this. In the future, I would expect groups to cover this use case. What is baseline within logical properties? What is a complete set of features within logical properties?

Kadir: When you go to Can I Use, you expect to see certain things. Same thing here.

Quentin: Do you want to break things up in the future?

Kadir: In Can I Use, things can be confusing. Granular features usually come from BCD, while actual Can I Use features are more coarse-grained. We aim at the Can I Use level.

Patrick: If you can share the data that you’re working on, that would be useful. You may do so on the Matrix channel, or through the mailing-list.

Quentin: We have this edge case where all properties get a new value, like text-line. Not a new property.

Daniel: This is the hardest one. Sometimes, it’s “later addition” to an existing feature. Sometimes, it’s a new feature. Whether or not to fold in a feature is a judgment call. Mostly based on searching for that thing on the web and seeing if that is a distinct thing that people talk about. We’re looking for evidence that developers see these as different things. It’s kind of Wikipedia knowlability problem. Having more consumers of the data is going to be useful for us to get feedback on how to proceed.

Quentin: There wouldn’t be a downside for having individual entries?

Daniel: If I was Can I Use from scratch, sometimes you want to get an overall sense of things. For very fine-grained data, BCD is your friend. We want to be able to capture some of the high level element but there is a tension there. There is a bit of a downside: reviews, maintenance.

Quentin: We did something similar when we grouped properties to avoid browsing the whole list.

Patrick: Thank you so much for the context!

Eric: You mentioned a Google Doc. Wondering about the list of features in it. I cannot access it.

Quentin: It’s probably the old one that is linked from the markdown page. We created a new one that should be public. I’ll look into it.

Summary:

• Aligning CSS Next feature identifiers with web-features would be very useful.
• Having the ability to track when CSS4 overall (or CSS5, etc.) become baseline seems useful too.
• Not all of the features discussed by the CSS Next group are useful for the web-features repo (e.g. candidates for deprecation, features never implemented, unclear features that are just 1-liner specs etc.)
• The groupings of features between CSS Next and web-features might be different. Web-features is fairly granual when it comes to recent features, because it matches how developers think about them (e.g. subgrid and grid are separate). Over time, fine grain features that have been baseline high for a while will start getting merged, but we don't yet have a mechanism for it.
• Quentin (I think this is @Que-tin) said he would share the list of features with the WebDX group.

[Que-tin]

Yep that's me. Sorry for being inactive lately.

I sent the link out inside of the web platform chat. I've also fixed the link on the RFC (Categorization).

I also figured there is a bit of chaos inside of the Feature Parent Column, I'll align it and adjust it accordingly in the upcoming days to match you the DXs Feature parents.

[Que-tin]

In the mean time I've seen you've added a whole bunch of missing CSS Features and Groups. While quickly scroll through them I came up with the following things still to add (don't quite know yet were to get the stuff to put into compat_features otherwise I'd add them myself).

Units should probably me renamed Units and values to match the CSS spec, that way much more stuff can be added.

• ex — Units and values — The ic unit is already documented so I figured this one should be added as well
• lh — Units and values — Line-Height unit
• Trigonometric Functions — Units and values
• Exponential Functions— Units and values
• Variable Web Fonts — fonts — IMONeeds it's own feature due to the amount if functions and properties available
• Dynamic Viewport Units — Units and values
• Filters — maybe own new group
• Transitions — maybe own new group
• Path Animations - animation - Ability to animate along a path, multiple properties (offset, offset-position...)
• text-box-trim — ??
• :top-layer

Would it in general maybe make sense, especially for the CSS stuff if groups would be determined by the spec? That's something both of our groups should consider.