Reconsider removal of import map polyfill

[joedolson]

The import map polyfill was removed in r58952, on the basis that the browser support Matrix for WordPress doesn't include any browsers that don't support import map.

However, the interactivity API uses import maps, and is rendered on the front-end. This means that removing the import map polyfill breaks anything that uses the interactivity API on the front end: navigation menus, the new accordion block, etc.

Historically, our policies on front-end support have been different from those for admin support. I think it's entirely reasonable to remove the polyfill in the admin, but it is a potentially significant problem for site owners, impacting their users.

There are multiple cases of user reports of being unable to use features due to their having older devices.

See: #63968, ​https://github.com/WordPress/gutenberg/issues/71431, #62641, #62533, ​https://github.com/WordPress/gutenberg/issues/68641

There may be more; this is what I found.

In my opinion, keeping import map polyfilled so that usage of the Interactivity API isn't discouraged on sites that need better support is important. This covers a wide variety of economically disadvantaged populations, including people with disabilities.

Pinging @swissspidy @desrosj @luisherranz @gziolo as people involved in #60970.

At the moment I'm putting this in the Bundled Theme component, as that's where the problem is exhibited, although it's not explicitly a problem with a theme. Not sure what would be most appropriate there.

[sabernhardt]

The component probably could be Interactivity API or Themes too, but I'll set it to "Script Loader" to match #60970.

[swissspidy]

For this particular case, these few reports all seem to be related to iOS. Import maps are supported since Safari 16.4+ / iOS 16.4+ (released in 2023), which is available for iPhone 8 or newer (released in 2017). So by removing the polyfill we still support 8-year old devices. I think that's very reasonable.

Also noting that the usage of Safari < 16.4 on iOS is 1.3%, down from 3.6% when the polyfill was removed ~1 year ago.

Historically, our policies on front-end support have been different from those for admin support.

Any documentation on that? In that case I would encourage a more general discussion about frontend vs backend browser suppport and documenting any decisions at ​https://make.wordpress.org/core/handbook/best-practices/browser-support/ and enforcing the policy accordingly through separate browserslist configs etc.

[joedolson]

I'm adding this issue to 7.0 to be resolved. In my opinion, the number of issues opened that are a direct consequence of removing the importmap polyfill is a clear indication that it may have been premature, but I also appreciate that maintaining eternal support for clearly obsolete devices is a challenge.

I'm not sure we have actual documentation about specific policies; but we have a history of choosing to remove things in the admin before removing them in themes. E.g. in #54421 we delayed the removal of the skip link polyfills for a couple years for extended support.

I think what we really need is to become more explicit about how we differentiate between front-end and back-end support. There is a difference, because support for the front end has a vastly broader footprint than the back end.

[pmmueller]

I am not a developer and don't know much about the mentioned browser support statistics, but I personally know 3 people on old phones with iOS 15.8.5 who cannot open a mobile menu on a block theme.

I know them because I rebuilt their websites with a block theme and they are not very happy that they cannot use the mobile navigation on their own website...

---
So should you decide not to fix it please give us a simple way to add support for for the navigation block on old devices. Maybe an *official plugin* or something like that.

Thanx in advance for considering this.

[joedolson]

I've been unable to get any movement on restoring this. I'm resigned to having to close it as a wontfix; ultimately, it's something that was most valuable immediately, and the longer it sits, the harder it is to get anybody to commit to it - since it will *eventually* be irrelevant.

I'll look into publishing a plugin to restore it, however. It should be pretty simple. Making it official may be outside of what I can do, though.

[pmmueller]

@joedolson Any chance of you releasing that fix as a plugin? It would be most appreciated 🙏🏻

---

Unbelievable. I came back to this issue after having updated the sites mentioned in comment no 7 to WP 7.0 and finding that the mobile menu still doesn't work.

Those people I mentioned will not update their old iPhones soon, so to them it is not an issue that will go away. It will of course *eventually*, but the priorities behind this are a mystery to me:

• On the one hand we're spending incredible resources to implement a feature like Real Time Collaboration, which imho could just as well be a canonical plugin.

• On the other hand mobile navigation in a block theme does not work on an old iPhone and the fix would cost next to nothing to implement.

So I had to tell those people that their WordPress menu will not work as promised. Ironically it was Global Accessibility Awareness Day...

[cbuntingde]

I dont have an old ios phone so I can only test with the device toolbar, but you can try this plugin.

​https://github.com/cbuntingde/ios-block-nav-fix