The PR does not combines toggler links into a single button as was suggested in
#37739 (comment) because it would require rewriting a good amount of profiler CSS code which is out of scope of that ticket. Overall I think it makes sense though as the toggler would not loose focus when controlled via keyboard.

For the record, I believe the front-end part of the profiler needs deep refactoring. Using floats with clearfix hack in 2020 seems odd and fallbacks for classList and EventListener are not really needed nowadays. Dropping support for old IE versions would make CSS/JS part of the profiler a lot simpler and cleaner.

Thank you @Chi-teck.

@Chi-teck the toolbar itself is intentionally keeping compat with old browsers, because it gets injected into the page. If it were broken in older browsers, it would forbid using Symfony to build apps supporting these older browsers (as you would not be able to test your page in those browsers locally due to the Symfony debug tools). The JS for the profiler pages is using newer features

@stof addEventListener works even in IE9 which I think was already "old browser" ~5 years ago. Nowadays I would consider it is an ancient browser. Another point here is that Web profiler intended for local development, it should never go to production. And developers tend to use bleeding edge technologies. I cannot image someone developing Symfony 5 application on IE8.

Anyway, it would be useful to establish browser support policy. That would help contributers to understand what browser APIs are allowed in CSS and JS code. That would require defining some heuristics like this.
https://www.drupal.org/project/drupal/issues/3080068

@Chi-teck someone needed to support older browsers will generally need to use the old browser locally at some point when debugging issues specific to it. If the injected symfony toolbar breaks the page, it makes this debugging impossible.

The fact that we expect developers to use a modern browser is the reason why the code for profiler pages (which are separate pages that you don't need to open in your IE8 where you debug IE compatibility) can be written using ES6 classes for instance.

The hard thing with the toolbar is that it gets injected into the page itself, and so it must respect the intended browser support of that page... which we have no control over.