Amphtml: Minimum support for browsers like IE11

Created on 30 Apr 2020  路  5Comments  路  Source: ampproject/amphtml

From AMP supported browsers:

In general we support the latest two versions of major browsers like Chrome, Firefox, Edge, Safari, Opera and UC Browser. We support desktop, phone, tablet and the web view version of these respective browsers.

Beyond that, the core AMP library and built-in elements should aim for very wide browser support and we accept fixes for all browsers with market share greater than 1 percent.

In particular, we try to maintain "it might not be perfect but isn't broken"-support for IE 11, iOS 8, the Android 4.0 system browser and Chrome 41.

Let's get consensus on what "it might not be perfect but isn't broken" actually means.

Also, we can update our special-case version support e.g. iOS 8 only has 0.23% market share today.

Some data:

Note that regional market share may differ dramatically e.g. South Korea has IE11 at 7.6% vs. 1.21% globally.

Proposal

Define "isn't broken" as "user can read an AMP news article, with working primary use cases for the most popular components".

Most popular components:

amp-img
amp-pixel
amp-ad
amp-youtube
amp-carousel
amp-analytics
amp-social-share
amp-sidebar
amp-accordion

Maintaining minimum support for browsers then requires drafting an "news article" test fixture containing the above components and writing integration tests for (1) basic runtime functionality like loading resources on scroll and (2) each component use case.

Until we have coverage stats for integration tests, skipped/flaky tests must be fixed with high priority (P1) to avoid loss of coverage over time.

Re: version support, let's bump minimum iOS support to 9.3 (1.53%) and remove Chrome 41 (Googlebot now uses evergreen Chrome). We can consider dropping Android system browser too (0.62%).

/cc @ampproject/wg-ui-and-a11y @ampproject/wg-analytics @ampproject/wg-ads @ampproject/wg-infra @ampproject/wg-runtime

High Priority DiscussioQuestion infra runtime

All 5 comments

This makes sense to me. I would like to see an addendum for completeness related to support inside embedded third party services, e.g. we can't guarantee that amp-youtube will work if its embedded document doesn't support the same minimum surface.

Ideally, I would like to see a second tier for the next most popular components, with a lower bar. Goes towards "user can read an AMP news article". Something like:

  • doesn't break the rest of the page
  • if its children elements commonly contain "main content" [1], then they're still displayed
  • interactive/dynamic stuff may break

Then after that would be tier 3 components for which no guarantees are made.

Just a straw proposal that I'm making without any personal cost. Those who are actually building stuff should override based on feasibility.

[1] by "main content" I mean like the main column of an article, not header/footer/sidebar

e.g. iOS 9.3 is the last supported version for iPhone 5 to iPhone SE.

Nit:

  • iOS 9 is the last supported version for 4S, iPad 2, iPad 3, and iPad Mini 1.
  • iOS 10 is the last for iPhone 5/C and iPad 4.
  • iOS 12 is the last for iPhone 5S, iPhone 6, iPad Mini 2, iPad Mini 3, and iPad Air 1.

This is currently blocked on IE support in GH Actions.

This is currently blocked on IE support in GH Actions.

IE11 tests are now blocking

Was this page helpful?
0 / 5 - 0 ratings