Open romainmenke opened 6 months ago
ddbeck
commented
6 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
6 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
6 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
6 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
6 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
6 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
6 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
6 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
6 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.
fantasai
commented
3 months ago 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
commented
3 months ago 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
commented
3 months ago 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
commented
3 months ago 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
commented
3 months ago 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: https://github.com/CSS-Next/css-next/discussions/92
But otherwise you can consider this answered and it's ok to close this :)
argyleink
commented
3 months ago 🙂 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: https://github.com/CSS-Next/css-next/discussions/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 ❤️
fantasai
commented
3 months ago Heh, so I think my position is in between you two. :)
@romainmenke
CSS4, CSS5 should not include any features that haven't shipped at all, regardless of when they were drafted.
I would mostly agree wrt CSS4--that is, I might consider some targetted exceptions (align-content on blocks comes to mind), but in general I think we should keep CSS4 to things that have shipped in at least one browser (and preferably more than one). But CSS5 is currently under development, so it's reasonable that a number of features in it aren't shipping yet at all--and it's OK that some of those might get pushed out to L6 or dropped entirely.
@argyleink
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. implementation status is a factor, it's just a minor one. same with draft status and health
Implementation status should be a significant factor, not a minor one. Unlike Baseline, it's not the only factor, so we might bend history a little to make the levels make more sense, and we don't need to be absolute about availability everywhere the way Baseline is, but I don't want us to write fiction here. If a feature was never implemented, it doesn't really belong in an earlier CSS level.
We trimmed CSS2.0 down to the features that actually were implemented (and added a couple extra that were) to create CSS2.1 (CSS Level 2 Revision 1). And there was tons of interesting stuff specced for CSS3 that wasn't implemented, or wasn't implemented until much later; these can't be part of authors' conception of CSS3, so it wouldn't make sense to include them in our definition either.
jensgro
commented
2 months ago First I thought, it would be a better idea to give the CSS versions a name by the baseline initiative. But then again as I saw how the grouping effort was made (in 5 year batches) I thought this a better idea. Beacause of multiple reasons.
I think the idea is great. It would be a marketing tool to communicate different states of the evolvement of the language. And it would communicate now how complex the language is now, compared with good ol' CSS3.
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?