Add Baseline status to hovercards

[rviscomi]

Progress on #427

• sync custom-data dependency with the output of Add computed Baseline status vscode-custom-data#111
• add Baseline info in hovercards
• update tests

Hovercard changes:

• adds baseline icon and status
  • replaces the browser version list
  • icon supports light/dark mode and corresponds to the feature status
• omits the experimental warning (covered by limited availability status)

Demo:

baseline-vscode.mov

Screenshots...

Widely available

Before:

After (dark mode):

After (light mode):

Newly available

Before:

After (dark mode):

After (light mode):

Limited availability

Before:

After (dark mode):

After (light mode):

Experimental

Before:

After (dark mode):

After (light mode):

(experimental warning removed, as it's redundant with the limited availability message)

Obsolete

Before:

After (dark mode):

After (light mode):

(obsolete warning kept)

[rviscomi]

FYI I was getting a TypeScript error related to my use of the Intl.ListFormat function:

$ npm run test

> vscode-css-languageservice@6.3.2 test
> npm run compile && npm run mocha


> vscode-css-languageservice@6.3.2 compile
> tsc -p ./src && npm run copy-jsbeautify && npm run lint

src/languageFacts/entry.ts:193:50 - error TS2339: Property 'ListFormat' does not exist on type 'typeof Intl'.

193 const missingBaselineBrowserFormatter = new Intl.ListFormat("en", {
                                                     ~~~~~~~~~~


Found 1 error in src/languageFacts/entry.ts:193

I can fix it by upgrading the tsconfig to es2021, but figured that would need to be part of a separate discussion. For now I worked around it by changing it to (Intl as any) and left a TODO.

[aeschli]

      "browsers": [
        "E12",
        "S10",
        "C50",
        "IE10",
        "O37"
      ],
      "baseline": {
        "status": "high",
        "support": {
          "chrome": "50",
          "chrome_android": "50",
          "edge": "12",
          "firefox": "28",
          "firefox_android": "28",
          "safari": "10",
          "safari_ios": "10"
        },
        "baseline_low_date": "2015-09-30",
        "baseline_high_date": "2018-03-30"
      },
 ```


Now the browser information is duplicated, or have conflicting information? Can't we use the browsers we already have? 
It's ok to add new browsers (just need to spec it)
If it's incomplete or has old data, we can set the data based on the baseline call.

[rviscomi]

@aeschli sure I've removed the baseline.support object and added the mobile versions of the Baseline core browser set to the existing browsers array

[rviscomi]

Found an issue with the accent-color property, which is not Baseline due to an implementation issue in Safari. In BCD, this is indicated by the partial_implementation flag. compute-baseline takes this into consideration and omits Safari from the list of supported browsers. But Safari still technically has a supported version in BCD and ends up in the list.

Actual:

Expected:

I fixed this by removing support strings from the browsers array for any core browsers missing from Baseline's support list.

[aeschli]

Thanks for the PR. I think we need to improve the look of the hover.

• I don't find the baseline icon intuitive. I would would go with the ⚠️ and a ✔️
• I would not put the name first

My suggestion:

• description
• compatibility warning (Property is experimental. Property is obsolete, Property is nonstandard)
• baseline
• syntax

[rviscomi]

Would you be open to moving the Baseline icon next to the status text? It's really the combined power of the icon and availability text (limited, newly, or widely available) that help to clearly convey the feature status.

This would also make the hovercard UI more consistent with other reference docs that talk about compatibility, eg MDN and caniuse:

Mockups

Here's how it could look for the various statuses, taking your other feedback into consideration.

Widely available

Newly available

Limited availability

[aeschli]

The mockups are good. I still don't like the extra wide baseline icons. It's a bit too large for the text size, also I find the form not very intuitive. Is the shape important to you? Can we not just add a checkmark? Or make it a bit smaller?

[aeschli]

BTW I adopted the custom data, but didn't make any changes to the hover. Leaving this to you.
https://github.com/microsoft/vscode-css-languageservice/pull/431/files

[rviscomi]

Here's an updated mockup of a 10px tall icon instead of the 14px version in light mode:

If that looks good to you, I'll push a commit updating the rest of the icons.

[captainbrosset]

Regarding the use of icons, thank you @aeschli for your feedback on the fact that they're not intuitive. @atopal, let's add this to other feedback we might have received and reflect on whether improvements are needed on the long run.

For now, though (i.e., for this PR), I strongly suggest keeping the Baseline icons as they are defined now, and not deviate from them.
Baseline is a concept that was introduced a couple of years ago and is getting adopted by more and more sites, dashboards, and tools. We pay a lot of attention to how Baseline is being adopted, and sometimes even work hand in hand with consumers to make sure that Baseline is communicated correctly (like now).

The reason is that Baseline is an attempt at summarizing the many details of a very fragmented and nuanced web platform, into something that's as simple as 3 statuses only. This is essentially impossible to do, but we believe that doing it in the way we're doing it now still has more benefits than drawbacks if, and only if, Baseline is communicated correctly.

Changing the icons to a checkmark and a warning icon would simplify what Baseline is even more, to the point that it becomes dangerous.
Indeed, Baseline says "if this is widely available, then you don't really need to worry about it, or test much". That's basically all it says.
Baseline does not say "if this is not widely available, then don't use it". If a feature is not widely available, then it's basically up to the developer to make a conscious decision as to whether they want to use that feature. They may very well use it, even if the feature has limited availability, if they've tested it for their specific use case. Maybe they're using a polyfill in other browsers. Maybe it's part of a progressively enhanced feature set. Who knows.

So, Baseline messages/icons should never appear to developers as something that may steer them away from using a feature.

[aeschli]

The smaller baseline icon looks better. Lets go with that!

[rviscomi]

Great!

Here are the changes from the latest commit:

• remove the feature name heading
• shrink all baseline icons to 10px
• move the baseline info between the feature description and syntax reference
• omit the baseline info when there's a non-standard or obsolete feature warning
• update tests

[rviscomi]

@aeschli this is ready for another look

[aeschli]

@rviscomi Thanks Rick, nice work, it looks great!

[rviscomi]

Thanks for all your help and can't wait to see it live! 🥳