Why doesn't the categorization align with the baseline initiative?

[romainmenke]

The RFC states that the introduction of a feature into a specification is one of the most important aspects and that the categorization doesn't align with the baseline initiative.

But it doesn't say why this was decided.

Aligning with baseline/web-features seems to have so many positive traits that I do wonder why this isn't used?

• shared context and mental model of when a feature is real and ready
• shared naming and definition of features
• shared documentation effort
• not having to explain all the nuances of specification vs implementation vs interop all over again

Maybe @ddbeck or @foolip also have some thoughts on this?

[ddbeck]

I haven't been following this work closely, but when @una last presented an update to the WebDX CG, I saw web-features and Baseline as complementary to, not in conflict with, new CSS[n] levels.

For example, I have a to-do list item to create a CSS4 group in web-features. Though last I heard, the list of CSS4 features wasn't settled enough for it to contain anything.

[argyleink]

i'll try and answer 🙂

The goal is to improve adoption and ease of teaching, not establishing a feature's browser implementation status or interop availability matrix. The Baseline lens is focused on dates and browser versions, aiding in the quest to understand how available a feature is across a set of target browser versions. The CSS4 and 5 lens is focused on CSS and it's own evolution, with only minor consideration of browser adoption. This allows each group, the CSS4+ group and the Baseline group, to move at their own speed, without any duplicated effort. While there may be shared concepts, the focus and goals aren't shared, and thus each can move more nimbly.

We felt, CSS's growth, levels and phases arent validated or invalidated by browsers, these specs can move independently of implementors. There are specs written 10 years ago with no implementations, and that's ok! Baseline is entirely concerned with browsers and what's implemented. We're interested in helping authors and educators teach and compartmentalize CSS, not deploy CSS with confidence regarding support and interop.

Hope this is helpful!

[romainmenke]

Thank you both for these insights!

---

Part of the motivation behind creating CSS4 and CSS5 groups was to facilitate CSS courses, hiring developers, ... All things that require a feature to be present in at least one browsers imho.

A good example is @custom-media. This is an old feature, it was first added in a specification at least 7 years ago : w3c/csswg-drafts@5f2781a

But it doesn't have any implementations. Should it be part of CSS4 regardless? Or should it be saved for a future group?

---

We're interested in helping authors and educators teach and compartmentalize CSS, not deploy CSS with confidence regarding support and interop.

Baseline High/Low is very focussed on support and interop, this is true.
But web features tracks features even before they reach the Baseline Low threshold.

I am not advocating for a minimum requirement of Baseline High or Low before a feature should be part of something like CSS4 or CSS5.

But I am concerned with using the moment of specification as an important metric.
I might be wrong about this, but I don't think anyone really cares when a feature was first described in a specification. However we know that developers deeply care about when something shipped. This is when a feature becomes real to them.

If a feature was specified a long time ago but only shipped recently then I would expect it to be part of a more recent grouping, like CSS5. In other words the date of first implementation is a much more important metric imho.

[argyleink]

In other words the date of first implementation is a much more important metric imho.

this was definitely taken into account! sorry if it sounded like we didnt take any browser implementation details into account, we certainly did. it just wasnt a dominating attribute, where in baseline it is a dominating attribute. and just because a CSS feature like custom media isnt in any browser yet, it doesnt change the history of when CSS added it into a specification. CSS4 or CSS5 arent strong signals of "caniuse", they're phases of the language and it's advancements.

it would be wasted effort for us to duplicate what baseline has already done so well, but also ignorant of us to not consider them when making the buckets agreed. we balanced things the best we the group could, feature by feature, and using all the data we had available to aid us in categorization.

if you find there are items that don't match the categories you feel, definitely point them out! @custom-media is in CSS5 for example, perhaps you think it shouldn't be in 5 but in "next/future" since it has no implementation? let us know!

[romainmenke]

Yes I think there should at least be some signal other than it being in a specification.
Maybe an intent to prototype is sufficient?

I think many will be confused to see features like @custom-media being part of CSS5 when implementers have shown little interest in it. (Unless Chrome intents to ship and I missed it? 🤞)

Focussing a bit too much on @custom-media, but there will be other examples and this will happen again and again in the future because the aspect that is used for categorization (specification date) doesn't align with the experience of most developers.

---

I am less concerned with features that have actually shipped and could land in either CSS4 or CSS5 depending on specification date vs first implementation dates.

[Que-tin]

In addition to what @argyleink already mentioned:

We had plenty of discussion on to what degree browser compatibility should be taken into account when we started grouping the individual features without completely duplicating the work Baseline has already done.
We also took signals from browser vendors into account when determining where and if stuff should be grouped because we also stumbled across a couple of deprecated things who got replaced since they first got speced.

The overall idea was to stay close to how CSS3 was released back in the days. Back then not all browsers had been 100% feature complete upon release but eventually caught up.

[Que-tin]

@romainmenke Seems like we typed at the same time.

As @argyleink mentioned:

feature by feature, and using all the data we had available to aid us in categorization.

We actually took a couple of things into account, including the browser vendor signals. But going through a list of 800+ features and discussing and researching them individually over a matter of months will most likely in some cases bring up individual features where we missed some date points or maybe interpreted them wrong.

@custom-media might be a good example for this and to be honest this is exactly the feedback we are looking for! If we get the feedback that we've missed some key data points for the grouping on a number of properties we will dig into our list once again and come up with a new RFC and reworked list.

[foolip]

The work to define CSS4 predates Baseline by several years, but I think the goal is also quite different. If you look a Baseline 2023 it doesn't really have a clear theme that's easily explained.

CSS 4/5 can group things that span a few years, and also to be aspirational. Baseline will always be "done" because it's defined by what's already shipped across 3 browser engines.

That being said, I think there's the potential for collaboration here. web-features has a "snapshot" field which we currently use for JavaScript features, but it could make sense to treat CSS4 and CSS5 as snapshots as well.

A challenge is that CSS4 picks out granular pieces of APIs that are part of larger features in web-features. For example, :defined is part of autonomous custom elements, but that also includes the HTML parts.

[romainmenke]

I think my original question is being slightly misunderstood :)

I am not saying that Baseline and defining CSS4, CSS5, .. are the same thing, or should be the same or even similar things.

I am however advocating for using the same underlying principles, concepts, metrics, ... to drive the categorization.

Baseline currently uses the dates of implementation as the most important metric. There is limited availability (implemented in at least 1 browser), baseline low (interop) and baseline high (interop for X months). I am really sure that Baseline got this part right. It is communicating readiness of features in the way that is most important to web developers.

I think it would be a good thing if web developers can transfer some knowledge of Baseline to the groupings of CSS4, CSS5, ...

I also do not think it is interesting for web developers to be exposed to "when a features was first specified".

This transfer of knowledge between Baseline and the categorization here can be as small as:
a feature must have at least "limited availability" before we assign it to a CSS group.

Or it can go a bit farther and use the date of the first implementation instead of the date of specification.

I want this to be a web developer focused categorization and not spec editor focused.

---

The same sentiment is present in the comments here : #92

Several other people are voicing the same concern.

---

A challenge is that CSS4 picks out granular pieces of APIs that are part of larger features in web-features. For example, :defined is part of autonomous custom elements, but that also includes the HTML parts.

Yup, that is also part of my concerns here.

If we create another set of features we make things harder for web developers and content creators, not easier.

We should try to avoid that.

[fantasai]

I am however advocating for using the same underlying principles, concepts, metrics, ... to drive the categorization.

That would make them the same thing, which isn't useful.

Baseline is all about implementation deployment. What is available across all implementations and exactly when.

This is about organizing CSS into teachable sets informed by their timeline of development. There's more judgement calls involved, and it considers a combination of when the feature was drafted, when it was adopted, and how it fits together with other features in developer usage. It should be something that, looking back, makes sense maybe even a little bit more than reality, and looking forward, helps us understand where we're going.

[romainmenke]

I think I am still being misunderstood here :D
Not sure how else to explain myself.

I am fully aware of what Baseline Low/High mean and I am not advocating for using either.

---

Let's put it more directly :)

I am absolutely sure that no CSS author wants features that haven't shipped at all in a named CSS version.

CSS4, CSS5 should not include any features that haven't shipped at all, regardless of when they were drafted.

It just isn't informative or helpful for CSS authors to include feature that can't be used.

Using the broadest possible definition of "can be used"

Let's say we include @custom-media in CSS5 (as is currently the case).
A feature that hasn't shipped and is unlikely to ship soon given that implementers aren't really interested.

Then authors of guides and books will ignore this feature because it just doesn't exist in reality.

But then, when it does maybe ship in the future, it will be out of place.
Where do you include it? Do you update (possibly printed) books?

Or do you add it in a future book, about a future categorization (e.g. CSS6), even when it doesn't belong there?

Or even worse, what if they do include it and CSS authors again and again discover that a written about feature just doesn't exist in reality.

---

The minimum really should be to have at least one implementation.
I am really not sure what the downsides are of having such a requirement.

Can anyone give an example of a downside?

Once that requirement does exist there also is significant overlap with the Limited Availability label from the Baseline initiative, right?

I am not saying that this categorization should list features sorted by implementation milestone. They can be grouped in different ways. Some features in CSS4 could have been implemented after some features in CSS5. But no feature should be purely theoretical.

---

I am also not sure what the downsides are of using the same CSS author facing names for CSS features. If one CG is already doing this work, why not align with it?

I do agree that there should be some editorial freedom here.

Maybe a larger feature was implemented in various smaller steps and is thus split up in web-features. I can understand that the larger feature should be listed and explained together in something like CSS4.

[romainmenke]

Maybe I am mistaken in linking this categorization with the work being done in web-features :) I assumed that it would reduce work for everyone if more people were working on the same list. And that within that list features could have a Baseline status and also a flag for CSS4, CSS5, ...

I assumed that working on the same list and having easy access to the same data and tools would create better results for both initiatives.

I still feel strongly that including features that are purely theoretical in something like CSS5 is a mistake. But there are other ways to avoid that than using similar underlying metrics as Baseline.

[argyleink]

I am absolutely sure that no CSS author wants features that haven't shipped at all in a named CSS version. It just isn't informative or helpful for CSS authors to include feature that can't be used. Then authors of guides and books will ignore this feature because it just doesn't exist in reality.

which reality? the one we share is the one where CSS did spec the feature and it's cemented into its history and potential. if someone doesnt want to write about them, that's fine. still going to be there in CSS history for interested folks.

to me, doesn't sound like these scenarios presented are unique to CSS4 or CSS5?

Do you update (possibly printed) books?

can't expect books to stay up to date, it's kinda their nature to be dated at the time of printing. and updating books happens alot right? and can be great for the authors, selling updated editions with higher precision or newer information.

Or even worse, what if they do include it and CSS authors again and again discover that a written about feature just doesn't exist in reality

if it's in a spec, it does exist, it exists for CSS and it's timeline and lifespan. CSS's existence doesnt revolve around implementors, kinda more the other way around.

The minimum really should be to have at least one implementation. I am really not sure what the downsides are of having such a requirement. Can anyone give an example of a downside?

the focus of the levels isn't feature availability, viability, author interest, implementor interest, browser support, etc. the focus is a way to take a large corpus of features and create meaningful bundles that are easier to digest, offer as education layers, or indicate an estimated timeline of when CSS defined something. the downside is that it would shift the meaning of a level or era into what baseline, caniuse, and many other efforts have already done. we don't need another perspective slice into "can i use", we need a new perspective into "whats happening with CSS as a language, regardless of which browser has what aspects of it." this effort is like 90% CSS, where many other efforts are 90% "does this fit into my browser matrix." there's multiple flavors to pick from about feature availability in your dev environment, CSS4+ is much less interested in your browser and focuses on CSS the language.

[romainmenke]

if it's in a spec, it does exist, it exists for CSS and it's timeline and lifespan. CSS's existence doesnt revolve around implementors, kinda more the other way around.

Although we often say that any resolution can be easily changed/undone as long as features haven't been widely implemented yet. In that way, implementations and interop do make features real. They solidify the feature.

Especially for CSS authors a feature is only real if they can build things with it.

---

Maybe I am interpreting some of the listed benefits in a too specific way?

"Modern CSS" does not have any specific meaning or timeframe. Clear categorization of CSS properties into CSS3, CSS4, CSS5, and any future versions will provide developers, recruiters, employers, and educators with a structured framework for understanding and discussing CSS advancements and its evolution.

I associate those things strongly with features that are at least somewhat usable.

---

I do get the history aspect of this categorization and agree that for recording the history of CSS the moment of specification is very relevant.

---

I think it is clear that this group feels strongly that (any) implementation status should not be given more weight for this categorization.

Maybe good to get wider feedback on this, given that others also raised similar concerns in the threads here: #92

But otherwise you can consider this answered and it's ok to close this :)

[argyleink]

🙂 we appreciate you sharing your thoughts! do feel free to continue sharing perspectives, it's helpful

Although we often say that any resolution can be easily changed/undone as long as features haven't been widely implemented yet. In that way, implementations and interop do make features real.

you're totally right that it does add to the solidity, but that's also just part of a feature's journey. i think a divergence point in perspectives here is that, to us, it's ok for a feature to be in CSS2 but not get implementations until 2025. when it became available and when CSS conjured it, are different points in the journey, and this groups focus is on CSS and not when it hit a browser near you.

I think it is clear that this group feels strongly that (any) implementation status should not be given more weight for this categorization.

implementation status is a factor, it's just a minor one. same with draft status and health (like how recently was it edited / groomed). there were a couple features that tipped into a different category because either there was no implementations or because the spec just hasnt seen much attention for a while. aural box model (deprecated), line-clamp (has a real specced feature for a long time but no implementors) and @Custom-Media come to mind.

this is a good time to review the feature list and point out ones you feel should have had a stronger inclusion of factors and share what they were. we could have missed them in our group review, and now is a good time to help us nudge any 🙂

Maybe good to get wider feedback on this, given that others also raised similar concerns in the threads here: #92

definitely, we're planning to go on some podcasts and continue the outreach to gather more feedback! it seems it's hardest for folks who follow the specs super closely, since they learned and were savvy with the levels or a year indicator for a feature. but, for a lot of others, it's confusing and some simpler categories can help them make sense of the language and its offerings.

But otherwise you can consider this answered and it's ok to close this :)

i think we'll leave it open, so others can follow along and continue to ask the question! you rock Romain, super appreciate all your CSS work ❤️