Add Baseline status to CSS hovercards

[rviscomi]

Baseline is an initiative by the W3C WebDX Community Group that aims to improve how we communicate the level of browser compatibility of web platform features.

In VS Code today, CSS properties have a hovercard that shows supported browser versions:

Just by looking at this information, it's not immediately clear if this feature is ready to use in production. This could be improved by adopting a similar treatment as the one used by MDN:

Here, the Baseline "widely available" logo and text are used to more clearly communicate that the feature has been available across the core browser set for a substantial amount of time (2.5 years).

To see how this might look, I prototyped a VS Code extension that displays a hovercard with a similar treatment.

After a quick chat with @aeschli, it sounds like this could be a useful addition. Filing this issue to continue the discussion.

Some open questions to consider:

• A feature's Baseline status can change over time as browsers add support. Is there already a process to keep BCD info reasonably up to date?
• Computing a feature's Baseline status may not be as straightforward as looking at the browser versions alone. We'd also need to consider mobile support and the amount of time that a feature has been available across the core browser set. Does this justify adding compute-baseline as a dependency to help with the status assessment?
• Right now it appears that hovercards are only supported for CSS properties. Should we also look to expand support to other CSS features like property values, functions, etc?
• As far as I can tell, HTML hovercards don't currently include any browser version data. Should we also look to expand support to HTML features?

[aeschli]

Maybe we can usecompute-basline in vscode-custom-data and add a new property to the generated data.

I try to update vscode-custom-data regularly

Lets start with CSS properties

[rviscomi]

@aeschli would you like me to start looking into adding support to HTML hovercards too?

[aeschli]

Is there a need for compatibility information with HTML? Sorry my ignorance, but are there elements/properties that are not supported/deprecated...?

[rviscomi]

Yeah good question. There are some newer HTML elements that aren't widely available yet, like <fencedframe>. Even for well established elements like <script> and <img>, new attributes and attribute values can get added over time. For example <img fetchpriority> and <script type="speculationrules"> aren't widely available either.

[rviscomi]

Here's another example from a prototype I got working 😀

A developer might be unsure about using <dialog> in production, feeling like maybe it's still too new and cutting edge. But having this info in the hovercard reassures them that it's actually safe to use.

[rviscomi]

Figured I'd open draft PRs so you can see how the prototype works, hope it helps:

microsoft/vscode-custom-data#113
microsoft/vscode-html-languageservice#202

Feel free to close them if you decide against it, otherwise they're ready for review :)

[romainmenke]

Thank you for working on this @rviscomi!

Not every team uses Baseline as their target and the previous implementation was agnostic of the specific targets in use for a given project.

While some developers might not immediately know from browser versions if something is sufficiently adopted for their case, others do know and do use it like that.

By only showing the baseline status a lot of information is hidden at first and only those teams using Baseline actually benefit from the recent change.

Can we maybe keep the current list of browser versions while also adding some Baseline related information?

[aeschli]

@romainmenke Thanks for the feedback. I'm ok in bringing the browser section back, maybe below the baseline information.
I think its interesting for newly added properties.
Do you want to create a new issue so users can add votes?