improve the system of aliases/abbreviations

[ianstormtaylor]

The unnecessary abbreviations makes this API extremely difficult to use. I've never successfully used browserslist without looking up the docs to see what the exact naming system I have to type is.

• Why ios_saf instead of ios_safari? It saves 3 characters in exchange for abbreviating "safari" to "saf" which no one does.
• Why and_chr? It saves just a few characters with no real benefit either.
• Why bb? It makes it even more likely that people won't know what it is, and then remove it from their list.

I realize you have "aliases", which is good in theory. But the way aliases are implemented is poorly designed too:

• Why is explorer allowed, but internet_explorer is not?
• Why should op_mini expand to operamini and ignore snake case all of a sudden?
• Why should and_chr expand to chromeandroid and reverse the order?

The docs go to the trouble of talking about how important it is not to ignore less popular browsers. But the naming and aliasing system used by the tool itself are designed such that people are going to ignore browsers whose names they can't even read.

[ai]

Names was taken from Can I Use database.

We added custom names in camel case (so, it is OperaMini). We can add more aliases if you will suggest simple but powerful policy.

[ianstormtaylor]

@ai thanks for the quick response.

I like the concept of taking them from the Can I Use database, but if they're poorly named in the database then it seems like Browserslist should choose a different naming policy if it wants to provide a useful experience for the end developers. (If Can I Use had come up with a good naming system that would have been great to have it better upstream.)

The aliasing concept is also good. But I think the issue is that tools like npx browserslist will always return the poorly named non-aliases, so as a user I either have to use those non-aliases or constantly be translating between the two which is much more work. For example:

$ npx browserslist
and_chr 61
and_ff 56
and_qq 1.2
and_uc 11.4
android 56
baidu 7.12
bb 10
chrome 62
edge 16
firefox 56
ios_saf 11
opera 48
safari 11
samsung 5

This is pretty hard to understand. It might be a good idea for those "helper" tools to return the more readable names instead (or even both names).

It seems like the browserl.ist website is down, but this would be the perfect place to be able to provide many naming schemes at once to very clearly create the link in people's mental models. For example each entry could look something like:

Internet Explorer [market share] [wikipedia link]
InternetExplorer ie

iOS Safari / WebView [market share] [wikipedia link]
iOS ios_saf

And then I think a really common one that trips me up is to add InternetExplorer and InternetExplorerMobile aliases, because no one calls it "Explorer" alone.

[ai]

I think the issue is that tools like npx browserslist will always return the poorly named non-aliases

Browserslist internal API must return Can I Use names, since Autoprefixer and other tools expect it.

But in next major release we can use human-readable names in default output and keep Can I Use names for --json and JS API.

Should we add some fancy table view? Like:

$ npx browserslist

+---------+----------+--------+--------+
| Browser | Versions | Market | Code   |
+---------+----------+--------+--------+
| Chrome  | 60-62    |    56% | chrome |
+---------+----------+--------+--------+
…

$ npx browserslist --code
chrome 60
chrome 61
chrome 62
…

We can even add a link to less known browsers in this output.

[CyberAP]

Loving that table layout!
I'd also prefer to see a browser share in my browserslist-stats.json:

$ npx browserslist

+---------+----------+-------+--------+--------+
| Browser | Versions | Stats | Market |  Code  |
+---------+----------+-------+--------+--------+
| Chrome  | 60-62    | 75%   | 56%    | chrome |
+---------+----------+-------+--------+--------+