3

The browserslist section in my package.json says:

"browserslist": {
  "production": [
    ">0.2%",
    "not dead",
    "not op_mini all"
  ],
  "development": [
    ">0.2%",
    "not dead",
    "not op_mini all"
  ]
}

I have a question here. I know , reads as or but how to read >0.2%? What does it mean? Also, if I want to know the IE versions and the browser it supports, how could I know this?

Amanda
  • 2,013
  • 3
  • 24
  • 57
  • 1
    Does this answer your question? [What is the significance of browserslist in package.json created by create-react-app](https://stackoverflow.com/questions/55510405/what-is-the-significance-of-browserslist-in-package-json-created-by-create-react) – keikai Apr 02 '20 at 10:59
  • @keikai No. I also want to know the IE versions covered in >0.2 % – Amanda Apr 02 '20 at 11:01
  • @keikai Could you please tell me the meaning of `>0.2%`? – Amanda Apr 02 '20 at 11:09

1 Answers1

2

You can use https://browserl.ist/ to check which browsers are supported by a certain query.

E.g. input >0.2% and it will give you exactly which browsers are included

LE:

For your query

    ">0.2%",
    "not dead",
    "not op_mini all"

You can use https://browserl.ist/?q=%22%3E0.2%25%22%2C%22not+dead%22%2C%22not+op_mini+all%22

tudor.gergely
  • 4,800
  • 1
  • 16
  • 22
  • Greater than 0.2 percent of what? Sorry, but I still do not get this. – Amanda Apr 02 '20 at 11:15
  • @Amanda greater than 0.2% of browser in use over the world. It's an estimation based on collecting browser usage on a lot of sites. Very simply put - of the data available, 14% comes from the desktop version of Chrome 78, and 1.43% is for IE11. I'm sure it's a bit more complex than that but that's essentially the information this tries to convey. – VLAZ Apr 02 '20 at 11:19
  • I see that if I do `0.1%`, it shows IE versions until `IE 5.5`. Any idea why does the default configuration does not cover these? I assume the more the better? – Amanda Apr 02 '20 at 11:32
  • 1
    because it's harder to support older browsers and it's not worth it for most people – tudor.gergely Apr 02 '20 at 11:48
  • 1
    @Amanda we, as web developers, *don't* want to support really old browsers. I must admit, partly it's because we want new and shiny toys to play with and that's what newer browsers provide. But there is a *really good* reason to avoid older browsers and that's IE. The older versions of IE were *terrible* and since Microsoft held a market share, that meant that everybody had to abide by the old broken IE browsers. This single handedly impeded the whole of the Web and web development because you need (on a good day) two versions of your site - one for IE and one for *good browsers*. It wasn't – VLAZ Apr 02 '20 at 12:51
  • 1
    @Amanda even that simple, either, as IE didn't merely double the work - you needed to invest *way* more time to support it. First, you have to *find* the weird and not-so-edge cases where IE simply refused to work with standards. Then find the weird roundabout way to fix it. Sometimes you'd need to just drop a feature or start hacking at third party code. And then you find that the terrible hack for IE6 *doesn't work for IE7*. Not because it's been "fixed" - no, it's just broken in a different way. And then you need even more convoluted hack for IE8 because, guess what, it behaves – VLAZ Apr 02 '20 at 12:51
  • 1
    @Amanda differently to both previous browsers. I remember when IE9 came out and it was *more* standards compliant than before. At that point a library we used just completely stopped working. Turned out that *they* had used horrible kludges to make sure everything works correctly. And the code was littered with `if (isIE()) { /* use bad code } else { /* use standards-compliant code */ }`. Who could blame the developers? They didn't really have much choice, either. But when IE9 dropped in it was detected as IE but it *rejected* the bad code. Well, some of it. The solution was to modify the – VLAZ Apr 02 '20 at 12:51
  • 1
    @Amanda library. See where it fails and do `if (isIE() && !isIE9())`, then find the next place it fails and so on, and on, and on, and on. Of course, not *all* of these needed to be changed, either because that would just be silly - why would IE9 actually *work correctly*? So, you have to spend *days* on these things only because users aren't moving from IE. And I don't blame users, here - not entirely, that was very much driven by Microsoft, who *wanted* users to keep using IE. At any rate, at some point the situation started becoming untenable. It might take you a day to implement – VLAZ Apr 02 '20 at 12:52
  • 1
    @Amanda something and then another *two weeks* to ensure it works in IE6, IE7, IE8, IE9, IE10. Each of which has its own quirks. And later browsers even had an explicit *quirks mode* that emulated how previous browsers worked. So you could be on IE10 and render the page as if on IE8. And *of course* that wasn't really the same as IE8. You'd have different bugs in IE10 quirks mode for IE8. To make matters worse, the browser would automatically enter quirks mode in some cases based on patterns it identifies. Or misidentifies as was often the case. At some point webdevs just decided to stop – VLAZ Apr 02 '20 at 12:52
  • 1
    @Amanda supporting old browsers. It wasn't worth the time. IE6 *still* had users but we, collectively as web developers, *didn't want them*. By ditching support we made *our* lives easier and also tried to prod users into switching over. That sort of worked. "Sort of" since I don't want to make the claim that webdevs single handedly moved the market but this *helped*. So, nowadays we do not want to be in the same situation. There *might be*, what, 20 people using very old browsers who *might* visit your site, or might not. – VLAZ Apr 02 '20 at 12:52
  • @VLAZ Would you help answer my other question https://stackoverflow.com/questions/60991601/getting-object-doesnt-support-property-or-method-entries-error-even-when-i-am ? – Amanda Apr 02 '20 at 12:58