4 ms·

> The Web Platform Baseline consists of features natively supported in the core browser set for at least two major versions. I don’t even know what “two major

> The Web Platform Baseline consists of features natively supported in the core browser set for at least two major versions. I don’t even know what “two major versions” means. Or why it would be reasonable to consider as a baseline. For Safari: we’re currently at 16.4 (March 2023); does “two major versions” mean from Safari 15 (September 2021), or from Safari 16.3 (January 2023)? I’m going to guess 16.3. For Firefox: so this just ignores Firefox ESR? It’s at 102.11.0, while regular is at 113.0. (That is, it’s at nine versions/nine months ago.) For everyone else: you know that’s permanently as little as about five weeks ago, right? Put bluntly: that’s stupid, nothing like what a baseline should be. By the sound of it, this may be genuinely ignoring 25–35% of users, and declaring features “baseline” not supported by the browsers used by fully 15–25% of users. (Numbers taken from quick estimation based on https://caniuse.com/usage-table https://caniuse.com/usage-table which mostly uses StatCounter’s woefully misleading and wrong numbers because I’m lazy, but I think my error bars are large enough that they’d hold up to more rigorous calculation using other data sets too.) My only hope here is that “two major versions” means Safari 15. Then all up it’d mean roughly “since September 1–2 years ago” rather than “mostly 5–10 weeks ago”, and that 15–25% would drop to under 5% for most features in the delta, half by simple coincidence. (Aside: I really wish browser makers would switch to some form of calendar versioning, e.g. YY.MM. There was a great opportunity about now when Firefox caught up to Chromium due to a slightly faster cadence.)

waboremo 3y ago
Major versions are always the first number before the first decimal point. So Safari 15 and Safari 16. You can check the linked feature set repo linked in the article and see that for the features, they're only checking that first group of digits. "15" "16" (sticking to the safari example).
- chrismorgan 3y ago
  Safari has a radically different approach to numbering to all the rest (even though it’s them that changed, not it). It’s bumping its “major” number once per year, whereas Chromium and Firefox are bumping theirs 10–12 times per year. Unless they have radically different deployment strategies, “major versions” is clearly useless as a consistent concept across browsers. But despite Safari being tied to the OS version, when you take everything together (hardware support for their OSes, OS upgrade frequency) it’s only a little different, nowhere near the 10× difference in importance of a “major version”. All up, I say “two major versions” is obviously a completely unsuitable definition to use. It needs to treat Safari differently, e.g. “two major versions of Safari and twelve major versions of all other browsers” (which would catch Firefox ESR) or “thirteen months of browser support” (which would be less for Safari most of the time, but really, consider the deployment cadence and it’s probably not so different, though maybe you’d bump it to fourteen or fifteen months, I dunno).
  - waboremo 3y ago
    Major versions isn't a useless consistent concept because it's the strategy all browser developers use to determine when major features are added (vs bug/security fixes). Which is what Baseline is for, feature adoption. So if Safari is adding a slew of major features once per year, and Firefox 6x per year, it doesn't matter. We have a baseline of what features as developers we can now implement without worrying about which browser version supports this or that. We see the baseline, we add the feature. Last two major versions has been utilized (unofficially) by most people through Browserlist. It's been both suitable and productive.
    - chrismorgan 3y ago
      This is nonsense. Safari adds major features in point releases: just look through some of https://developer.apple.com/documentation/safari-release-notes https://developer.apple.com/documentation/safari-release-not... and see. Some of the biggest features get held for the next “major” number bump, certainly, but most point releases include at least as much as most major number bumps in Firefox or Chromium. In my experience, people haven’t tended to use just “last two versions” with Browserlist: IE has normally been special-cased historically, and Safari has regularly been special-cased in some way, and Safari has actually been the salvation of the “last two versions” strategy because it dragged the baseline down to a more acceptable place, where “last two versions” of only Firefox and Chromium would regularly be disastrous. It has long been a really poorly-thought-out mechanism. The other point you’re missing is user adoption. “At least one year” for Safari is one thing, but “five weeks” for everyone else is pretty crazy when you look at actual update statistics.
      - atopal 3y ago
        The issue with Safari is that it's tied to the operating system on iOS. That's an issue with minor releases, but even more so with major releases, where you can't get Safari 16 for iOS 15. That naturally means slower uptake compared to Chrome or Firefox which will update the browser in the background seamlessly. I'm hoping that we'll be able to identify better usage data and a better understanding of developer expectations to refine this definition.
2h 3y ago
100% agree. This is such an idiotic standard, they might as well stop lying and just say the truth: "if you're not on auto update, fuck you". What's worse is people copycat this "baseline", and if you try to argue sanity, they just say "sure it's what Chrome/Firefox recommend" without knowing or caring that they are only supporting months old browsers now. It's madness.
- simonw 3y ago
  Given how security critical a web browser is, why wouldn't you be running auto update for it?
  - 2h 3y ago
    Yes, well said. We should just force updates upon users. Block all websites unless user is on latest version, and close the source code to prevent compiling older versions. Can't be too careful.
  - tambourine_man 3y ago
    Because your OS doesn’t support a newer version. Chrome 109 is the last version to support Windows 8. There are a lot of people on systems even older than that.
    - dialogbox 3y ago
      IMO, this kind of pressure is needed and helpful to let people upgrade the vulnerable OS versions. Without it, people may stay forever with Windows XP.
      - userbinator 3y ago
        Fuck that and the rest of the e-waste-generating degenerate corporate-authoritarian brainless drones.
        bruce511 3y ago
atopal 3y ago
Looking at browser usage for the last two major versions is misleading. That would only be true in a parallel release of a web platform feature in every browser, but that's basically never the case, and it's not the same for every feature. A feature like subgrid was launched years ago in Firefox, last year in Safari and will be launched later this year in Chromium. So, by the time it's in Baseline, it will be in two versions back for Chromium browsers, but 20+ versions back for Firefox and over a year old in Safari.

waboremo 3y ago

Major versions are always the first number before the first decimal point. So Safari 15 and Safari 16. You can check the linked feature set repo linked in the article and see that for the features, they're only checking that first group of digits. "15" "16" (sticking to the safari example).

chrismorgan 3y ago
Safari has a radically different approach to numbering to all the rest (even though it’s them that changed, not it). It’s bumping its “major” number once per year, whereas Chromium and Firefox are bumping theirs 10–12 times per year. Unless they have radically different deployment strategies, “major versions” is clearly useless as a consistent concept across browsers. But despite Safari being tied to the OS version, when you take everything together (hardware support for their OSes, OS upgrade frequency) it’s only a little different, nowhere near the 10× difference in importance of a “major version”. All up, I say “two major versions” is obviously a completely unsuitable definition to use. It needs to treat Safari differently, e.g. “two major versions of Safari and twelve major versions of all other browsers” (which would catch Firefox ESR) or “thirteen months of browser support” (which would be less for Safari most of the time, but really, consider the deployment cadence and it’s probably not so different, though maybe you’d bump it to fourteen or fifteen months, I dunno).
- waboremo 3y ago
  Major versions isn't a useless consistent concept because it's the strategy all browser developers use to determine when major features are added (vs bug/security fixes). Which is what Baseline is for, feature adoption. So if Safari is adding a slew of major features once per year, and Firefox 6x per year, it doesn't matter. We have a baseline of what features as developers we can now implement without worrying about which browser version supports this or that. We see the baseline, we add the feature. Last two major versions has been utilized (unofficially) by most people through Browserlist. It's been both suitable and productive.
  - chrismorgan 3y ago
    This is nonsense. Safari adds major features in point releases: just look through some of https://developer.apple.com/documentation/safari-release-notes https://developer.apple.com/documentation/safari-release-not... and see. Some of the biggest features get held for the next “major” number bump, certainly, but most point releases include at least as much as most major number bumps in Firefox or Chromium. In my experience, people haven’t tended to use just “last two versions” with Browserlist: IE has normally been special-cased historically, and Safari has regularly been special-cased in some way, and Safari has actually been the salvation of the “last two versions” strategy because it dragged the baseline down to a more acceptable place, where “last two versions” of only Firefox and Chromium would regularly be disastrous. It has long been a really poorly-thought-out mechanism. The other point you’re missing is user adoption. “At least one year” for Safari is one thing, but “five weeks” for everyone else is pretty crazy when you look at actual update statistics.
    - atopal 3y ago
      The issue with Safari is that it's tied to the operating system on iOS. That's an issue with minor releases, but even more so with major releases, where you can't get Safari 16 for iOS 15. That naturally means slower uptake compared to Chrome or Firefox which will update the browser in the background seamlessly. I'm hoping that we'll be able to identify better usage data and a better understanding of developer expectations to refine this definition.

2h 3y ago

100% agree. This is such an idiotic standard, they might as well stop lying and just say the truth: "if you're not on auto update, fuck you". What's worse is people copycat this "baseline", and if you try to argue sanity, they just say "sure it's what Chrome/Firefox recommend" without knowing or caring that they are only supporting months old browsers now. It's madness.

simonw 3y ago
Given how security critical a web browser is, why wouldn't you be running auto update for it?
- 2h 3y ago
  Yes, well said. We should just force updates upon users. Block all websites unless user is on latest version, and close the source code to prevent compiling older versions. Can't be too careful.
- tambourine_man 3y ago
  Because your OS doesn’t support a newer version. Chrome 109 is the last version to support Windows 8. There are a lot of people on systems even older than that.
  - dialogbox 3y ago
    IMO, this kind of pressure is needed and helpful to let people upgrade the vulnerable OS versions. Without it, people may stay forever with Windows XP.
    - userbinator 3y ago
      Fuck that and the rest of the e-waste-generating degenerate corporate-authoritarian brainless drones.
      - bruce511 3y ago

atopal 3y ago

Looking at browser usage for the last two major versions is misleading. That would only be true in a parallel release of a web platform feature in every browser, but that's basically never the case, and it's not the same for every feature. A feature like subgrid was launched years ago in Firefox, last year in Safari and will be launched later this year in Chromium. So, by the time it's in Baseline, it will be in two versions back for Chromium browsers, but 20+ versions back for Firefox and over a year old in Safari.