Annotate features which can be used safely without support

[antross]

In webhint we've recently started integrating BCD to automatically warn users about potential cross-browser support issues.

Lately we've been focusing on reducing noise from features developers can/should use even if not all their target browsers support them. In the short term we've started building our own "ignore" list, but adding an annotation to BCD itself would better help other tools utilize this same logic.

I'm not tied to a specific name (maybe safe or progressive), but something to indicate that a feature degrades gracefully and doesn't require cross-browser support or a polyfill to use today (on a related note it may also be interesting to annotate when a feature has a viable polyfill available).

I realize in some cases this could prove to be fairly subjective, but I think asking "would a reasonable developer use this in production without providing any explicit fallback or alternate handling?" could help, especially if it's supported by real-world examples.

Some examples we've run into so far include cursor in CSS (not supported by some old Android versions still in use) and integrity in HTML (as using subresource integrity is a good idea even if not all your target browsers support it). CSS in particular likely has many more candidates we'll identify as we keep testing more web content.

Thoughts?

[ddbeck]

This sounds promising, but I'm not quite clear on how I'd distinguish between a feature that needs a fallback versus one that doesn't (or, say, what's graceful versus ungraceful degradation). Suppose a new feature comes along that hasn't been used in production sites at all yet. You're reviewing a PR that claims the feature is safe/progressive. How would decide if it's correct or not?

[jpmedley]

I agree. What's the heuristic for deciding safe vs. not safe?

[antross]

I did say this would be a bit subjective. 😁

I'd include features that add minor visual adornments, provide additional security, or improve performance - all without altering existing functionality. I'd exclude features used as part of layout, application logic, or to make content accessible.

One existing example I'd put in the grey area would be text-shadow as it can be a minor visual adornment, but is often used to make text easier to read on noisy backgrounds. Another example that probably wouldn't make the cut is appearance: none, but we're still considering including this in our ignore list due to its frequent use for styling form controls where possible. We'll probably need additional special handling around form styling anyway.

As far as new features are concerned: if it's not clear after some discussion, then I'd say err on the side of caution and postpone adding the flag until more real-world usage can be observed.

[foolip]

Repeating some info from https://github.com/mdn/browser-compat-data/issues/6986.

A while back I filed Compatibility panel warns about CSS cursor property, which is fairly harmless and not actionable which was closed as WONTFIX because of resource constraints, and:

Right now, the Compatibility panel uses data as is from the MDN Compatibility repository. Perhaps it's more actionable to open this issue on that project. Its results feed into the Compatibility panel in Firefox DevTools.

I'm not especially surprised to learn in this issue that webhint manually maintains ignorelists, and from https://github.com/webhintio/hint/issues/3036 it seems like there's also a severity level, where I guess some issues from BCD get demoted to the lowest severity or turned off.

@antross have things changed on the webhint side since you filed this issue, or are you still maintaining a list which you keep in sync with BCD over time?

[antross]

@foolip apparently I missed your question and just happened to see it as I was looking to see if this issue had progressed.

The answer is yes, webhint is still maintaining a separate list of safe features to ignore. We're largely only adding to it as we get feedback from users about a feature being unnecessary to flag so the list is still much shorter than a "complete" list likely would be.

[foolip]

Thanks @antross, that makes sense!