Here’s the (live updating) Baseline widget for view transisions:
One of my historical criticisms is that a view of browser support this simplistic might push people away from using a feature when they need not be.
As I write, Safari only just released both forms of support and Firefox remains without support for the View Transition API.
But who cares? Using these features has little negative impact on non-supporting browsers (assuming you do the very little it takes to not have JavaScript throw on an un-supported function call). The View Transition API is quite progressive enhancement friendly.
I also understand that one widget can’t be the entire answer for educating the world on web platform features and when it is appropriate to use them. Entire blog posts can struggle with that.
So I appreciate Rachel Andrews chiming in on this specifically:
The problem with progressive enhancement is that the appetite different people and teams have for it varies. I’ve been telling people for well over twenty years that websites do not need to look the same in all browsers. There are many developers (or their bosses or clients) who very much disagree, even as we approach 2025. This means that any decision around what makes or does not make for good progressive enhancement is entirely subjective.
I disagree with their disagreement! lolz. Progressive enhancement doesn’t hurt anyone, it lets you use features when ready to do so, so being against that as a concept doesn’t work for me.
I think I would like to see something like “🌟 Progressive Enhancement friendly!” in the widget somehow.
The story is similar with polyfills. The Baseline widget doesn’t ever say “it’s not supported, but there is a polyfill you could use!”, which is something that might be very important information to have when deciding to use a feature. Again Rachel has insight:
Initially, we considered a path that included polyfills. We thought it might be possible to have a less conservative version of Baseline that also included things with a solid polyfill. What became quickly apparent, however, was that very few features can be completely polyfilled so that you can just drop in the polyfill and use the feature as specified.
In this case, I think I agree with the decision not to include any information about polyfills. In my experience there are precious few truly good polyfills, they do have a potential negative user impact, and they are a moving target.
I super appreciate the inside look into how decisions like these are come to!
What we need now is some UI somewhere that helps us figure out what the heck value to use as the featureId="" in the <baseline-status> component.
