Baseline Data Choices
Baseline Data Choices êŽë š
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:
Rachel Andrews (12daysofweb.dev)
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> (web-platform-dx/baseline-status) component.
