Add Baseline status to hovercards #428

rviscomi · 2025-03-18T02:09:04Z

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 · 2025-03-20T00:47:56Z

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.

src/languageFacts/entry.ts

aeschli · 2025-03-21T08:07:10Z

      "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 · 2025-03-21T15:27:31Z

@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 · 2025-03-21T18:38:05Z

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 · 2025-03-24T16:11:03Z

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 · 2025-03-24T16:29:10Z

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 · 2025-03-24T16:54:41Z

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 · 2025-03-24T16:57:52Z

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 · 2025-03-24T17:14:45Z

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.

…e into baseline-status

captainbrosset · 2025-03-25T08:06:53Z

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 · 2025-03-25T14:08:25Z

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

rviscomi · 2025-03-25T14:28:04Z

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 · 2025-03-31T14:57:09Z

@aeschli this is ready for another look

aeschli · 2025-04-03T14:28:53Z

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

rviscomi · 2025-04-03T14:42:37Z

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

FluorescentHallucinogen · 2025-05-22T06:56:40Z

src/languageFacts/entry.ts

+		return status;
+	}
+
+	const baselineYear = baseline.baseline_low_date?.split('-')[0];


@rviscomi If the status is low, then baseline_low_date is used, but if the status is high, then again baseline_low_date is used, not baseline_high_date. It turns out that baseline_high_date is not used at all. Is this not a bug? Is this by design?

Hi, yes this is by design and is consistent with other Baseline resources. For example, the dialog element is widely available since 2024, and Baseline since 2022:

status: baseline: high baseline_low_date: 2022-03-14 baseline_high_date: 2024-09-14

Resources like MDN and the Web Platform Dashboard show the newly available date:

FluorescentHallucinogen · 2025-05-24T16:05:46Z

src/languageFacts/entry.ts

+// TODO: Remove "as any" when tsconfig supports es2021+
+const missingBaselineBrowserFormatter = new (Intl as any).ListFormat("en", {
+	style: "long",
+	type: "disjunction",


@rviscomi Why did you use disjunction instead of conjunction here? 🤔

This makes the text look like Limited availability across major browsers (Not fully implemented in Chrome, Edge, or Safari) instead of Limited availability across major browsers (Not fully implemented in Chrome, Edge, and Safari).

"or" is more correct. Here's Gemini to help articulate exactly why that is 😄

When listing items that share a common negative characteristic, using "or" is generally more grammatically precise and less ambiguous.

So, the more correct phrasing is:
"Not fully implemented in Chrome, Edge, or Safari"

Here's why:

Meaning with "or": This sentence structure implies that the negation ("Not fully implemented") applies to each browser individually:

It is not fully implemented in Chrome,

AND it is not fully implemented in Edge,

AND it is not fully implemented in Safari. This accurately conveys that none of the listed browsers have full implementation. In logic, this corresponds to ¬A ∧ ¬B ∧ ¬C.

Potential ambiguity with "and": The sentence "Not fully implemented in Chrome, Edge, and Safari" could be interpreted to mean: "It is not the case that the feature is fully implemented in all three (Chrome, Edge, and Safari) simultaneously."

This statement would be true even if the feature was implemented in Chrome and Edge but not in Safari (i.e., at least one of them doesn't have it). In logic, this corresponds to ¬(A ∧ B ∧ C), which is equivalent to ¬A ∨ ¬B ∨ ¬C (at least one is not implemented).

While readers might often infer the intended meaning (that none of them have it), the "and" phrasing is technically ambiguous and not as precise for indicating that each listed item lacks the feature.
For clear technical documentation, where precision is important, "or" is the preferred conjunction in this negative context to ensure the meaning is that each of the browsers listed does not support the feature.

FluorescentHallucinogen · 2025-05-27T15:23:34Z

src/languageFacts/entry.ts

+	}
 };

+const shortCompatPattern = /(E|FFA|FF|SM|S|CA|C|IE|O)([\d|\.]+)?/;


@rviscomi Why are we looking for the | character in the [\d|\.] part? 🤔

I've analyzed the browsers.css-data.json file from the @vscode/web-custom-data package and haven't found a single property that has this character in the browsers or values.browsers field.

But I've found 5 properties that have values in the browsers field, that don't match current pattern:

overflow-anchor: 'Spreview'
-moz-background-clip: 'FF1-3.6'
-ms-filter: 'IE8-9'
-ms-transform: 'IE9-9'
-ms-transform-origin: 'IE9-9'

Actually, we are not interested in the version value (the second part of the regexp), only the browser name (the first part of the regexp).

Maybe we can do with a simpler regexp or without using a regexp at all?

I included the regex here in its original form for compatibility with customData.schema.json. It seems the | character was intended to be used as an "or" operator, so it could probably be safely removed.

@aeschli PTAL.

You can remove the |...

@aeschli I've opened microsoft/vscode-custom-data#117.

rviscomi added 8 commits March 17, 2025 22:07

update custom-data

92f624d

show baseline info

d204d21

sync custom data

a793782

updated design

904b8ac

respect documentation setting

5021f5f

tests

baf8773

show missing baseline browsers

8625658

light/dark inline SVGs

fd64487

rviscomi marked this pull request as ready for review March 19, 2025 20:30

fix tests

8372298

captainbrosset reviewed Mar 20, 2025

View reviewed changes

src/languageFacts/entry.ts Outdated Show resolved Hide resolved

rviscomi added 2 commits March 20, 2025 09:20

re-add browsers, adjust baseline schema

b505746

add baseline to schema docs

86eb48e

merge browser support

1d5d2d1

also remove baseline.support from doc

2f507b6

rviscomi added 2 commits March 21, 2025 14:39

reconcile baseline support

9ef47b4

update mobile shortnames

46a990d

rviscomi mentioned this pull request Mar 22, 2025

Add computed Baseline status microsoft/vscode-custom-data#111

Merged

rviscomi added 2 commits March 24, 2025 13:30

Merge branch 'main' of github.com:microsoft/vscode-css-languageservic…

85e84e9

…e into baseline-status

remove duplicate types

cf7f84b

address UI feedback

09aea35

aeschli added this to the April 2025 milestone Apr 3, 2025

aeschli enabled auto-merge (squash) April 3, 2025 14:27

aeschli approved these changes Apr 3, 2025

View reviewed changes

alexr00 approved these changes Apr 3, 2025

View reviewed changes

aeschli merged commit 0a8ca4c into microsoft:main Apr 3, 2025
3 checks passed

rviscomi deleted the baseline-status branch April 3, 2025 14:40

rviscomi mentioned this pull request Apr 8, 2025

Adds baseline status to html elements and attributes microsoft/vscode-html-languageservice#202

Merged

FluorescentHallucinogen reviewed May 22, 2025

View reviewed changes

FluorescentHallucinogen reviewed May 24, 2025

View reviewed changes

FluorescentHallucinogen reviewed May 27, 2025

View reviewed changes

Add Baseline status to hovercards #428

Add Baseline status to hovercards #428

Uh oh!

Conversation

rviscomi commented Mar 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Widely available

Newly available

Limited availability

Experimental

Obsolete

Uh oh!

rviscomi commented Mar 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

aeschli commented Mar 21, 2025

Uh oh!

rviscomi commented Mar 21, 2025

Uh oh!

rviscomi commented Mar 21, 2025

Uh oh!

aeschli commented Mar 24, 2025

Uh oh!

rviscomi commented Mar 24, 2025

Mockups

Widely available

Newly available

Limited availability

Uh oh!

aeschli commented Mar 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aeschli commented Mar 24, 2025

Uh oh!

rviscomi commented Mar 24, 2025

Uh oh!

captainbrosset commented Mar 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aeschli commented Mar 25, 2025

Uh oh!

rviscomi commented Mar 25, 2025

Uh oh!

rviscomi commented Mar 31, 2025

Uh oh!

aeschli commented Apr 3, 2025

Uh oh!

Uh oh!

rviscomi commented Apr 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

FluorescentHallucinogen May 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

rviscomi commented Mar 18, 2025 •

edited

Loading

rviscomi commented Mar 20, 2025 •

edited

Loading

aeschli commented Mar 24, 2025 •

edited

Loading

captainbrosset commented Mar 25, 2025 •

edited

Loading

FluorescentHallucinogen May 24, 2025 •

edited

Loading