Features with partial support appear as "Not supported"

[jdatapple]

The Web Features Explorer displays a feature with partial support as a feature with no support. Is there a way to improve the status representation that can signal partial support?

On the ::marker entry, for instance (https://web-platform-dx.github.io/web-features-explorer/features/marker/) Safari shows an ❌. The binary status is misleading.

[nt1m]

The same applies to preview support. Perhaps a way to include preview support would be nice to have on the dashboard.

[captainbrosset]

I moved this issue to the web-features repo, even if the X is shown on the explorer, the explorer is just a front-end to the web-features data, which treats partially implemented features as not supported, for now.

See also #915 and #1988.

[captainbrosset]

In one of the most recent discussion about handling partially supported features, we concluded the following:

Most common cases of features being partially implemented/behind flags can likely be handed by leaving the baseline status unchanged, but surfacing the partial note information that BCD has at the feature level, so that consumers (such as the explorer website) can then use this extra information to show, for example, a little beaker icon, instead of a red X.

Over time adding more fine grain statuses to baseline seems desirable, but for now, the 3 simple/summarized statuses (not baseline, baseline newly available, baseline widely available) are likely enough while getting developers used to the concept.

Also, note that we can always handle this on a case by case basis. It really depends on how developers think about features.
Taking a concrete example: if the way that ::marker is implemented in Safari (support limited to color and font-size) is how most web developers think about that feature (i.e. they don't expect any other properties to be available anyway), then it makes sense to make the feature be Baseline.
Later, we can author a second feature which encapsulates supports for other properties in ::marker, and that feature would appear as not supported in Safari.
This would be considered a later addition to an existing feature, and is something we do commonly on the repo.

That being said, after Googling around for a bit, I didn't get the feeling that limiting ::marker to color and font-size was how developers talked about the feature only.

[jdatapple]

The Web Features Explorer isn't a front end for only the web-features repo. It also includes data from sources like browser vendor standards position repos to add more color to why a feature has not achieved Baseline status in a given browser.

If the status shown is intended to be reflective of browser support, not its support according to meeting the Baseline definition, then more color could be added by including support notes from the browser-compat-data repo as well and maybe a different representation to indicate some progress for that feature.

If instead this is intended to show feature availability according to the Web Platform DX agreed definition for Baseline, then you might consider a change to the section label "Browser support" to be clearer about the status being represented. Maybe adding a sentence describing the Baseline definition of support is useful? There are a number of ways this could be improved.

Either way I think there's an opportunity here to add clarity to the status being shown depending on what you're going for here.

[ddbeck]

I'll give this a closer read later but briefly I think the discussion here is partly duplicating these two existing issues:

• Partial support and notes #915
• Make it obvious when something is in beta/preview/nightly #955