We've received some feedback that it's unclear if the icons indicate support or lack of support. Let's explain this in the tooltips as a first step to making this more clear. We can add this text before the browser names:

Unsupported:
Firefox 68 (current)

Also, a few small tweaks to the tooltip wording:

• There should be a space between the version number and the parens, so instead of Chrome 81(current), 83(beta), 84(nightly), it should say Chrome 81 (current), 83 (beta), 84 (nightly)
• esr should be ESR

FYI, Martin mentioned that sometimes a property would be more accurately described as "supported but only with vendor prefixes." Do we have a way of knowing (from the dataset) when this is the case?

I looked at compat data, it seems that there are two cases.

Property that defined as normal property but every browser needs vendor prefix.

• e.g. user-modify
  https://github.com/mdn/browser-compat-data/blob/master/css/properties/user-modify.json

Property that defined with prefix.

• e.g. -webkit-text-fill-color
  https://github.com/mdn/browser-compat-data/blob/master/css/properties/-webkit-text-fill-color.json

And, it seems that detecting both types is not so hard.

Thanks for looking into this!

So, it seems that in the cases like user-modify, we could say this in the tooltip instead of "Unsupported":

Implemented with vendor prefix

For something like user-select which isn't deprecated/experimental, but requires prefixes, we could be more explicit by also showing that in the UI like (needs prefix)

As for -webkit-text-fill-color, this particular property doesn't show up in the compat panel for me.

Martin - wanted to get your thoughts on this.

I think we need to start an overview of possible combinations and rethink the approach.

user-modify is a great example of complexity. I try to list them in order of severity:

• it's deprecated and should not be used, even if supported (MDN contains a note on what to do instead). Should deprecated properties be reported regardless of their browser support? I'd say yes. Even though they might not cause webcompat problems now, they may do so in the future.
• it requires vendor prefixes, which should be handled similar to the discussion in bug 1643294
• it's non-standard. Should we warn on non-standard properties? I think we should treat them like other properties and mark them as (non-standard), similar to experimental features.

And depending of the developers CSS, some or all of them might apply.

Anyways, I'd like us to take a step back and look through possible combinations and how to handle them. That will give us a chance to avoid false positives and give clear indications of browser support and severity of issues.

This sounds good to me.

If a property has multiple issues, should we try to show all the issues or just the most severe one?

If we showed everything for user-modify, it would look like:

[>] user-modify (deprecated, prefix needed, non-standard) 🌐 🤖
    elementname

I think showing all of them makes sense. This would reduce the complexity on our end, and also seems friendly for the users. Imagine you see an issue (e.g. prefix needed), fix it, and instead of the issue disappearing you will just get a new report.

So I like the proposal :)

Hi Martin!

I have one question.
How should we define the prefix needed property?
For user-modify, since all browsers need a prefix, prefix needed should be added absolutely.
On the other hand, for user-select, some browsers need a prefix, but not all.
https://github.com/mdn/browser-compat-data/blob/master/css/properties/user-select.json
So, should we define as prefix needed property if If there is at least one browser that needs a prefix?
Or, if all browsers need a prefix, should be prefix needed? Or more than 50%?

I'd like to hear your thinking!
Thanks!

That's a good question.

The assumption is that users configure the panel to show warnings for browsers they want to support. That means that as soon as one browser needs a prefix, but it's not present in CSS, the panel should show the prefix needed warning.

Thank you very much!
Yep, that makes sense!