A lot of the sneering in these comments focuses on a strawman web developer, making bloated sites with looming frameworks that expect every browser to behave li

A lot of the sneering in these comments focuses on a strawman web developer, making bloated sites with looming frameworks that expect every browser to behave like Chrome and are too lazy to write native code for every platform under the sun. I've had enough of these junk takes. Let's talk about a real world scenario. I've been writing a simple web app in vanilla JS, that relies on some well established browser standards to accomplish the following goals that I think we can all get behind: 1. How do I make the UI look nice? 2. How do I make it usable and accessible, especially to people who rely on browser focus to use a website? 3. How do I make it behave consistently across Safari/Firefox/Chrome? 4. How do I make it run as fast as possible? I've worked hard to reach these goals in tandem, and for the most part, things are working (you can see for yourself at https://rezmason.github.io/wireworld-player/ https://rezmason.github.io/wireworld-player/ ). The UI is built from standard form elements, there's no buttons made of <div/>s; screenshots taken in the different browsers very closely match; it runs very fast, though that's a WIP; and most importantly, every browser properly handled element focus. Or so I thought. Last week I realized non-Safari browsers set the focus on whatever element is clicked. Combined with Safari's lack of support for focus-visible, this causes the same user interactions in and out of Safari to result in completely different browser focus states, while still having identical display states. In my opinion this is a worst case scenario for accessibility and usability. I hope we can all agree that any GUI ambiguity that can hide a bug for two weeks can equally derail the experience of a site visitor. But this ambiguity is the default, and I don't think it can be resolved without a workaround written in JavaScript. As the article above points out, these Safari quirks are long-standing open issues. But my main point is this: by developing and testing my app in Safari first, I wound up making a worse user experience for my visitors. My choice of browser was an obstacle to half of my goals. I'm not shooting for the moon, here— my project is pretty barebones. It's just DOM and 2D canvas drawing in a single thread, for Pete's sake. (For now, anyway.) But it would be better executed if I'd primarily tested it in Firefox and Chrome, or if Safari was better stewarded.