Features with 100% browser support are capped at 97.98%

[dfabulich]

inline-block has been supported in all browsers since IE8 in 2009. It was supported in Safari 3.1 and Firefox 3 in 2008. Every version of Chrome has supported it. Every browser since then has supported it.

But, when I go to https://caniuse.com/inline-block

Expected: 100% global usage
Actual: 97.98% global usage

If we look at data.json, it's easy to see why. If you take the marketshare of all agents in the agents array and sum them all up, they sum to exactly 97.98%. The remaining 2.02% is tracked in StatCounter's data as "other" traffic; there's no way to know for sure what those browsers are, and what they do or don't support.

… except, obviously, they all support inline-block. Every browser supports inline-block! caniuse is currently making an extremely pessimistic assumption that all 2.02% of unknown browsers support absolutely no features whatsoever, which doesn't really make sense.

Instead of taking "other" traffic as a cap on marketshare, when we know that X% of tracked global usage supports a feature, we should assume that X% of the unknown browser share supports that feature, too.

Mathematically, I think that caniuse should take the tracked usage_perc_y number and divide it by the sum of all tracked browser traffic, 0.9798. Thus, inline-block should be listed as 100% global usage. https://caniuse.com/es6-module with 94.92% usage_perc_y should actually have 94.92 / 0.9798 = 96.88%.

That way, we'd assume that the 2.02% of unknown browser traffic behaves no better and no worse than tracked browser traffic.

[Sora2455]

You can see this already if you change the dropdown on the top-right from "all users" to "all tracked".

(Though I personally would appreciate the ability to change the default option for this dropdown in the site settings).

[jensimmons]

Oh, this is very interesting. It means it's likely features that have 97% support could be reported as only having 94% — which feels like a big difference. That could be the different between whether or not a team feels comfortable using something.

[SebastianZ]

I'd even go that far and say that "all tracked" should be made the default because of this issue. The percentages provided should be reliable and "all users" is not. See #4058.

(Though I personally would appreciate the ability to change the default option for this dropdown in the site settings).

I've now created #6934 to discuss that separately.

Sebastian

[SebastianZ]

From #6933 (comment):

The reason I prefer "all users" to be the default is because it seems more prudent to acknowledge that there's a few % of users out there using less common browsers which deserve consideration as well. There may also be certain regions where such browsers are more common so I'd rather not ignore them entirely.

Though for users with browsers not included in the stats there's no benefit in generally assuming their browser does not support a feature. So I like @dfabulich's suggestion to take the untracked browsers into account when calculating the percentage.

Sebastian

[mk7087]

https://caniuse.com/mdn-html_elements_html
https://caniuse.com/mdn-http_methods_get

Why is there information on tracked devices that don't even support "html"?
What's even more confusing is that there are 38.33% of devices that don't support the GET method that "must exist" in the browser. It seems less compatible than html.
I think we need to reconsider the method of collecting information itself.

[Sora2455]

@mk7087 The trouble with your examples is that they're pulled from MDN, not from caniuse itself. For the GET page, it just says "Yes" under browser support, which isn't a version - so caniuse just assumes the most recent version and nothing else, even though as you say browsers have been supporting this since version one. The error is in MDN's data.

With the HTML page, the problem is that MDN doesn't track all of the browsers that caniuse does, so caniuse assumes no support in the browsers that MDN doesn't mention.

[SebastianZ]

That's obviously a twofold issue. First, the browser compat data on MDN is inaccurate. And second, unknown support, even for tracked browsers, is interpreted as no support when calculating the percentage.

So, to iterate on @dfabulich's suggestion, the calculation should extrapolate the calculated percentage of support to include untracked browsers and those, for which support is unknown.

One way to display that could be to show the percentage of tracked support plus the percentage of unknown/untracked but assumed support in gray, similar to how it's done for partial support.

In the GET method case this would then look like

And the hint would then explain how the percentage for browsers with actually unknown support is calculated.

Sebastian

PS: The data on MDN for those integral features also needs to be updated and corrected. Though that's obviously out of scope here.

[firefoxic]

caniuse assumes no support in the browsers that MDN doesn't mention.

That's the crux of the matter. CanIUse can collect data from StatsCounter, MDN or anywhere else. But it's a bug, at least for me as a CanIUse user, to add anything to "not supported" that it doesn't recognize in the data.

If you don't want to add unrecognized data to "supported", then it's better to remove it from the results altogether.

Now for me this value in the results is just broken, I stopped looking at it and just explore the colored table with the latest versions of browsers (known to me).

[mirisuzanne]

It doesn't seem like a solution would have to be either-or here? CanIUse clearly shows 'partial support' and 'prefixed support' in the primary layout - and then shows the 'global' total as a combination of two numbers. Why is 'unknown' handled differently, and behind a setting? There's already two lines there: 'global' and 'un-prefixed'. Why not add 'tracked' in that same space? Why not show 'global' as an equation that includes 'untracked'?

I don't want either 100% or 97%, I want to see both by default. And then a tooltip explainer can provide more detail.

The current design isn't somehow providing us info that would be hidden by addressing this concern, it's only hiding information that would be useful to explain.

[jensimmons]

This issue continues to be a problem. I heard someone on a podcast recently express surprise that a feature is not 100% supported yet. They were asked — wait, what? And they say, well, Can I Use reports only 97% support! Then they both agreed it's too early to use the feature.

We need to either create a visible 3% "data not available" portion of the visualization, so developers realize, oh, 97 is as high as it goes.

OR we need to redo the math so the unknown goes away, and 100% is 100%.

I prefer the latter. We can mark it with a note "*2.02% of browsers have unknown support", and let developers decide whether or not to worry about those.

Otherwise, we are leaving developers clueless about what to do, and under the impression things that are very well supported are in fact, not.

[mirisuzanne]

Similar - Sass project has a requirement for 98% support before relying on a feature. 😱

I agree it makes the most sense to show known support, and then the caveat about unknowns. My point is just that it would be simple to show both by default without any special settings. Why do users have to go looking to find this out?

[jensimmons]

Plus, web developers are not using this support data with precision to make exact decisions. If they want precision, they should be plugging in their own data. (Perhaps how to do so can be made more visible.)

They are using this handwavy data to get a general sense, to give them an impression overall. And having something that has 98% support say 95%, and something with 100% support say 97% definitely gives off the wrong impression.

[Fyrd]

Yeah, I'm still having trouble coming up with the best solution here. Happy to continue brainstorming solutions.

As mentioned in another ticket my hope had been that the presence of the dropdown and "?" button would be enough to make people notice that the single number doesn't tell the entire story. Indeed the global (or even regional) support % isn't all that reliable so I wish developers didn't depend on it as much as it sometimes appears they do.

To address some earlier points:

OR we need to redo the math so the unknown goes away, and 100% is 100%.

Except we don't know that's true at all. It might seem obviously true for some features but not others. I want to give users of untracked browsers the benefit of the doubt and not ignore them.

Why not show 'global' as an equation that includes 'untracked'?

If I understand the suggestion here correctly I believe the problem with this is that that would result in features with no support looking like "0% + 2% = 2%" which would be weird knowing it's very unlikely that the untracked browsers might have support when the major browsers don't.

My point is just that it would be simple to show both by default without any special settings

Unfortunately support tables are visually very busy already. There's already variations of the usage section (e.g. including prefixed support, partial support and multiple usage sources: regions and user-added data)

I am leaning towards including the missing % somehow, just trying to figure out the best way that's least confusing and doesn't feel like it adds too much visual clutter.

I also wouldn't mind finding some way to de-emphasize the importance of these numbers due to the inaccuracies involved in computing it and how everyone's audience differs anyway.

Thanks for continuing the discussion!

[SebastianZ]

Why not show 'global' as an equation that includes 'untracked'?

If I understand the suggestion here correctly I believe the problem with this is that that would result in features with no support looking like "0% + 2% = 2%" which would be weird knowing it's very unlikely that the untracked browsers might have support when the major browsers don't.

If the initially suggested solution is applied, you'd still end up with 0%. @dfabulich's idea was to apply the percentage of support of the tracked and known data to the unknown data.

So with 0% of tracked browsers supporting a feature, you'd end up with "0% * 98.08% + 0% * 1.92% = 0%". And the displayed data would be "0%" like now.

And if 50% of the tracked browsers support a feature, we'd have "50% * 98.08% + 50% * 1.92% = 50%", displayed as "49.04% + 0.96% = 50%" with a hint for the 0.96% that that number is a guess.

And again, note that https://caniuse.com/mdn-http_methods_get only has 55.94% among the tracked browsers. Though it's clear that every browser has support for the HTTP GET method. So the calculation also needs to account for tracked but unknown browser data.
Therefore, in that example it would be "100% * 55.94% + 100% * 44.06% = 100%" displayed as "55.94% + 44.06% = 100%".

Sebastian

[dfabulich]

I think the best thing to do is to change the default from "all users" to "all tracked." It's likely a one-line change in the UI (which is not open source, so I can't file a PR for this) and I think it's just a better number in every way.

[SebastianZ]

I think the best thing to do is to change the default from "all users" to "all tracked."

That's covered by #4058. And I agree, "all tracked" is the better default to cover user expectations.

Though I want to emphasize again that this doesn't cover the cases of tracked browsers with unknown support. And a change as described in my previous comments shouldn't be too hard, presumably.

Sebastian