Open romainmenke opened 2 months ago
ddbeck
commented
2 months ago 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
commented
2 months ago 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
commented
2 months ago 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 : https://github.com/w3c/csswg-drafts/commit/5f2781af1f1a2d883a62964fe501c2bd8e393828
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
commented
2 months ago 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
commented
2 months ago 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
commented
2 months ago 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
commented
2 months ago @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
commented
2 months ago 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
commented
2 months ago 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 : https://github.com/CSS-Next/css-next/discussions/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.
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?
Maybe @ddbeck or @foolip also have some thoughts on this?