Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Formal browser support definition updates #15900

Open
3 tasks
janbrasna opened this issue Jan 21, 2025 · 0 comments
Open
3 tasks

Formal browser support definition updates #15900

janbrasna opened this issue Jan 21, 2025 · 0 comments

Comments

@janbrasna
Copy link
Contributor

Description

With the current refresh relying heavily on CSS vars, maintaining support for certain legacy browsers from the lowest fidelity tiers has proven to be increasingly challenging. This is particularly evident with efforts to enhance the experience on key product download funnel pages that make the effective layout actually less usable than its more basic version.

I'm opening this issue to propose several updates to the documented browser support profile (https://bedrock.readthedocs.io/en/latest/browser-support.html), ensuring it aligns more closely with the capabilities of current bedrock codebase and what it can realistically support in 2025.

1. No more full fledged styling bundles besides simple legacy IE8–9 for fx/desktop ("Exceptions", enhanced experience)

When making the new components compatible in #15867 (comment), the effort to try to adapt them to 15–20yo rendering engines to output something meaningful with usable behavior instead of just plain documents like the other pages seemed like no longer realistically manageable, without introducing a lot of extra code to provide layers of degradation served to all audiences, not just the 0.00N% for the legacy bundles.

Using the same "Basic support" bundle without exceptions seems to actually provide more compatibility, legibility and usability today. (Details in the linked issue/comment.)

2. No need to keep IE10 for OS compatibility ("Degraded support" for Win 7/8)

Once the above is simplified through conditional comments, there however is the same effect rendered in IE10 too, which nonetheless is not in Basic tier, but above it in Degraded browsers. Ideally the site should be usable and the interactive components enhanced progressively in such fashion that it would render a simpler fidelity instead of breaking its layout, however the effort would mean adding more complex code served to every single visitor for that degradation to happen basically just in outdated EOLed software.

Other options would be trying to move IE10 from Degraded to Basic, however that would mean still adding extra code delivered to everyone, as IE9- support conditional comments, IE11+ fits within .is-modern-browser, so the gap for IE10 would have to be addressed through wrapping all the progressive components incompatible with such browsers in the body class, and providing an alternative styling if not the class.

None of the OS versions concerned would be stuck with this IE version. Both W7 and W8 can upgrade IE10 to IE11 (W8.1 ships with IE11 by default), and after Edge switched to blink engine they actually made it available to backport all the way to W7 too, so none of the OS versions listed would be stuck on IE10 without any upgrade path, unless intentionally managed to be this explicit legacy. Which is the case of W10 too, that had Edge as default and only included trident engine in a user-triggered compatibility mode within Edge. That's why I'd move IE11 out of W10 to W8.1-, and drop IE10 completely:

Degraded support:
Windows 10
Internet Explorer 11
Windows 8.1 and below
Internet Explorer 1011

3. Version updates for oldest support

Supporting macOS 10.15+ means effectively having to support Safari 15.6+, older macOS can run Chromium 116 instead of 114 and legacy Windows and macOS have moved to Fx 115 ESR, so these are just tiny version updates to match the reality/EOL for those platforms.

(Also noting that IE8 no longer collects GA/GTM even with the simplified bundle, it is not compatible with the current DNT/consent utils.)

4. Android and iOS support matrix

There is no mention of any mobile OSes with regards to the browser support expected, one can only infer it would follow the same pattern, e.g. matching oldest Gecko ESR versions, oldest or evergreen Chromium versions, and analogous WebKit versions (e.g. iOS 15+ in Enhanced and iOS 12+ as Degraded?)


Success Criteria

  • No longer serving base protocol styling to IE9- for fx/download for a simplified document rendering like all the other pages
  • IE10 is left out as there was an upgrade path all the time; instead of addressing its layout
  • Version updates are confirmed to be OK and documented
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant