Consider `accent-color` (Not Baseline) vs. CSS Nesting (Baseline 2023).
Browser compatibility is only a small piece: it’s more important to consider the role it plays and how progressive-enhancement friendly it is.
CSS Nesting requires cross-browser ubiquity: `accent-color` is much safer!
Zach Leatherman 3636 replies 2626 likes33 reposts Original on Bluesky36 replies
-
where are you following 2025 status?
-
ah no need to apologize! just trying to understand the context — thank you!
Interop isn't Baseline; things that are in Interop are by definition not ready for Baseline, but having them as priorities in Interop means they might be in Baseline in a year or so; I wrote a couple of articles about this a while back
-
Apple is a big part of why Interop happens (for both bad and good); it's at least moved things along from where they were before the annual Interop priority alignments - and no worries, I've been trying to explain how these fit together for a while and I'm about to have another go
Hi, I'd love to hear more (maybe not on this thread) about why you think interop 2025 is bad? Happy to use DMs or have a video chat or whatever you prefer
equally curious, so if it does stay on the thread... 👀👀👀
-
-
-
If you haven't heard it, @meyerweb.com and I talk about how it works a bit and why it's a bit opaque. If it helps at all.
-
I can tell you, as someone on the committee, that it seems a so difficult to manage what people read into all of this. A lot of people think we should focus exclusively on the more mature, rough edges, and not new stuff - and lot of other people think it should include none of that.
-
That's very interesting to hear and I'd love to understand a comparison better if you'd like to chat sometime
-
-
-
-
I might suggest modifications to the “Limited availability” and “Newly available” tags to include language about whether a feature is progressive enhancement friendly or not!
renaming this side project to "Can I Baseline?"
I’M INTERESTED
We're definitely interested in talking more about this on the WebDX CG. Progressive enhancements, polyfills, and accessibility have come up multiple times in the past. So far, we've not been able to incorporate these aspects into Baseline calculation though. But I do believe we should.
One of the things I've tried to steer the group towards in the first years of the project is to avoid "hiding" things that are not yet supported. Anything we can do to make features easier to discover/use, not harder, is valuable.
interesting! “hiding” in what view?
As in, Baseline comes with the risk of hiding too many features from the web: those that aren't supported across browsers even though they're perfectly fine to use.
Showing a "Limited" Baseline banner on a doc website about a given feature comes with the risk of steering people away from it.Ah, I see — yeah. That dovetails back to Baseline missing some pieces if you want to encourage or discourage usage on a feature, imo! “Limited but safe!”
Filed github.com/web-platform... to put it on our radar. We'll likely discuss at our next CG meeting (which you're more than welcome to join, details here: www.w3.org/community/we...), but please feel free to comment on the issue too.
Pinging @miriam.codes who had made a similar point too.appreciate you Patrick! 🙌
Some additional discussion is happening on this GitHub Issue: github.com/web-platform...
Thanks @patrickbrosset.com for filing!
"Baseline Newly Available" is useless. It means "someone somewhere thought of this. It's not everywhere. Don't use it." It is extremely annoying that it was invented, and afaict it was invented because people were sad that their new feature was not yet "baseline" and so people wouldn't use it.
this is harsher than I normally am about stuff. But I was super annoyed at "newly available". It was Really Useful to explain to teams I work with that "if a thing says 'baseline' it's probably OK for us, otherwise don't" and now there's a special new baseline which utterly invalidates that.
I think that’s fair feedback. I’m not sure the arbitrary 30 month goalpost is a good finish line for “Widely available” either — hmm
I think that's OK, myself (which is why I liked "baseline"). It's essentially a more formal definition for the oft-used and not-well-defined "this requires a modern browser", I think
ah, that phrase sets off red flags for me but I see your point 😅
While working on the ESLint CSS plugin’s require-baseline rule, we discovered that cursor is not baseline due to incomplete mobile implementation. 🤷♂️
This was something I fed back as well at the time. I still think it would make a huge difference. Same with more complex features like View Transitions.