[wp-trac] [WordPress Trac] #52331: Consider using more precise browser versions for `browserslist`

WordPress Trac noreply at wordpress.org
Wed Jan 20 18:52:13 UTC 2021


#52331: Consider using more precise browser versions for `browserslist`
------------------------------+-----------------------------
 Reporter:  desrosj           |      Owner:  (none)
     Type:  defect (bug)      |     Status:  new
 Priority:  normal            |  Milestone:  Awaiting Review
Component:  Build/Test Tools  |    Version:  4.9
 Severity:  normal            |   Keywords:  2nd-opinion
  Focuses:                    |
------------------------------+-----------------------------
 The `browserslist` array within the `package.json` file is used to inform
 the `autoprefixer` package which CSS vendor prefixes should be present in
 Core CSS files. This process happens when `npm run grunt precommit:css` is
 run.

 **Within `trunk`**

 Currently, browser support is defined relatively as such:
 - Browsers with > 1% global usage.
 - IE >= 11.
 - The last 1 version of Android and ChromeAndroid.
 - The last 2 versions of Chrome, Firefox, Safari, iOS (which generally is
 the same version as Safari since the versions coincide), Edge, and Opera.

 Since Chrome version 25, the Android and desktop versions of Chrome are
 aligned with stable releases available at the sime time between the two.
 **Because of this, the ChromeAndroid item can probably be removed, or
 should be updated to `last 2 ChromeAndroid` to be accurate.**

 **Older Branches**

 These relative values work within `trunk`, but they could potentially
 cause issues in older branches over time. Values are relative to the day
 the command is run and not to when each major version was released.
 Running `npm run grunt precommit` while working within older branches will
 eventually result unwanted CSS changes as more new browser versions are
 released.

 I'm proposing that when a major version is branched, the `browserslist`
 array gets updated with precise versioning to ensure that the browsers
 supported on release day will continue to be supported into the future,
 and prevents unnecessary/undesired CSS changes within minor releases. The
 `> 1%` should also be removed after branching because usage changes over
 time, and this could also result in some vendor prefixes being
 unintentionally removed.

 For the 5.6 branch, the below values would be used.

 ||= Browser =|| Version ||
 || `ie` ||  `>= 11`  ||
 || `Android` ||  `>= 11`  ||
 || `ChromeAndroid` ||  `>= 87`  ||
 || `Chrome` ||  `>= 87`  ||
 || `Firefox` ||  `>= 81`  ||
 || `Safari` ||  `>= 13`  ||
 || `iOS` ||  `>= 13`  ||
 || `Edge` ||  `>= 41`  ||
 || `Opera` ||  `>= 66`  ||

 WordPress 4.9 was the first major version to use relative versioning (see
 [41062]).

 I've gone and done some research, and below is the list of browser
 versions on each major version's release day that would have met the
 relative requirements.

 || WP Version || IE || Android || ChromeAndroid || Chrome || Firefox ||
 Safari || iOS || Edge || Opera ||
 || 5.6 (12/8/2020) || 11 || 11 || 87 || 87 || 81 || 13 || 13 || 41 || 66
 ||
 || 5.5 (8/11/2020) || 11 || 10 || 83 || 83 || 79 || 12 || 12 || 44 || 42
 (no version 43) ||
 || 5.4 (3/31/2020) || 11 || 10 || 79 || 79 || 73 || 12 || 12 || 42 || 65
 ||
 || 5.3 (11/12/2019)|| 11 || 10 || 77 || 77 || 69 || 12 || 12 || 40 || 63
 ||
 || 5.2 (5/7/2019)  || 11 || 9 || 73 || 73 || 65 || 11 || 11 || 40 || 58 ||
 || 5.1 (2/21/2019) || 11 || 9 || 71 || 71 || 63 || 11 || 11 || 40 || 57 ||
 || 5.0 (12/6/2018) || 11 || 9 || 70 || 70 || 62 || 11 || 11 || 40 || 56 ||
 || 4.9 (11/16/2017) || 11 || 8 || 61 || 61 || 56 || 10 || 10 || 40 || 48
 ||

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/52331>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list