Expose version numbers in the widget when expanded

[bramus]

The widget does not expose the version numbers, even though the data is right there in the JSON file. Right now I have to jump through hoops in order to get the actual list of browser versions that have support for a certain feature:

[atopal]

Hmm, good point. On MDN and caniuse.com that is done intentionally, because a) version numbers have mostly lost their meaning for most developers and b) that information is still available on the page itself on those sites.

I can see how that might still be useful on other sites. Bramus, can you talk a bit about your use case for version numbers? Would like to understand in particular whether having that information in the expanded state is fine or would be needed in the widget in the collapsed state.

[bramus]

Hmm, good point. On MDN and caniuse.com that is done intentionally, because a) version numbers have mostly lost their meaning for most developers and b) that information is still available on the page itself on those sites.

On MDN specifically they include a link to the version list further down on the page.

Bramus, can you talk a bit about your use case for version numbers?

We are working on the CSS Wrapped 2024 overview. For each feature we want to include the Baseline widget, but that doesn’t tell authors the whole story as most of those features are not in Baseline yet. Looking at just the widget they cannot know if something has been in Chrome (or another browser) for a few years or only for a week. Having the version numbers in there would allow authors to get an idea of that.

Would like to understand in particular whether having that information in the expanded state is fine or would be needed in the widget in the collapsed state.

I think it would be fine to only have it in the expanded state.

[atopal]

Ah, makes sense, but do you need version numbers or rather the date for when something became available in a browser? I'm guessing we'd probably need both?

[rachelandrew]

I don't think version numbers are all that helpful to regular developers (seriously, most people don't actually know which version of Chrome they are using, much less when something shipped). If we were to show anything, dates would likely be most useful.

For our docs I'm suggesting we use the MDN widget when things are still limited availability (so for most content on developer.chrome.com) and use the Baseline widget for content on web.dev which typically is in Baseline. At that point I think it's far less interesting to people what version a thing is, maybe when we expect it to be widely available might be though.

[bramus]

I don't think version numbers are all that helpful to regular developers

Agreed, but I don't see that being a reason to exclude the non-regular developers who do want the version number details.

As mentioned I'm fine with showing the version numbers only in the expanded state of the widget so that interested devs can dig deeper. MDN also does it that way, by providing an in-page link to the browser support table they already have on their pages.

When talking about bigger features such as View Transitions that are not Baseline yet, devs want to know which specific versions some sub-feature will work in or not. It really makes a difference by giving them the info then and there, instead of requiring them to look up the entry in the baseline data to see which caniuse feature / bcd entry it maps to, and then have them to go to that specific site to find the actual numbers. That's a lot of jumping through hoops.

For our docs I'm suggesting we use the MDN widget when things are still limited availability

That would require us to constantly go back to already published articles to change the widget it needs to show. By incorporating the version numbers in the baseline widget this is not necessary.

[rachelandrew]

That would require us to constantly go back to already published articles to change the widget it needs to show. By incorporating the version numbers in the baseline widget this is not necessary.

That's not the case, I wouldn't expect to move away from the MDN widget on developer.chrome.com and on web.dev we don't have content about limited availability features (check the internal docs for clarification).

[bramus]

But this widget is meant to be used on more than just DCC/WDD, right? Those writers, like me, might have a need to provide version information along with that. As the info is already present in the data, why not expose it (when expanded)?

Also: there are (~ will be) demos up on chrome.dev that evolve from being pre-Baseline only to Baseline over time. Those would require updating when the info is not included.

[argyleink]

what if next to "Learn more" was a link to Caniuse?

i'm not finding the current Learn More link very helpful, but a caniuse link would

[bramus]

Great suggestion. That way the responsibility to show up-to-date version info can remain offloaded to places authors most likely already visit.

[atopal]

Yes, we discussed that option earlier this week (independently of also providing the data inline). One issue is that not every Web Feature has a caniuse entry yet, but Alexis is working on an integration already, and we could also link to an MDN entry in the meantime or additionally.

[mirisuzanne]

I agree that something would be useful here, and that (even as a version-aware user) I'm generally more interested in the date than the version. Expanding on that, 'widely available' is entirely time-based, and a somewhat arbitrary point along a timeline of things becoming more and more available. I think that's reasonable, but I've often wished this component would show a progress bar for newly available items, so we can see how new.

(Maybe that's tangential enough that I should open a new issue, or create my own component, but I thought it might be relevant to this discussion)

[captainbrosset]

I've often wished this component would show a progress bar for newly available items, so we can see how new.

Somewhat related, for Limited support features, knowing how long has a feature been blocked for, seems useful.
For example, accent-color has, at this point, been blocked by Safari (the last browser that hasn't yet implemented it) for 3 years.

[mirisuzanne]

(I believe they do now support accent-color, but provide a static AccentColor not based on user/OS settings, so that data might be out of date – but) Yes that does also sound useful.

[bramus]

https://pawelgrzybek.com/baseline-status-of-a-web-platform-feature-on-a-hugo-website/#make-it-yours is an example of what I personally find a more useful representation of the data: