This content originally appeared on Go Make Things and was authored by Go Make Things
A few months ago, I wrote about how Safari is holding back the web.
Today, I wanted to share another example of a Safari bug that’s apparently done on purpose that I caught when testing a new web component I’m building for Kelp UI.
Let’s dig in!
The behavior
I’m building a <kelp-disclosure> component.
A disclosure component is one where clicking or pressing a button displays some hidden content, and clicking or pressing it again hides that content.
For Kelp, I’ve decided to let the component perform double duty, also acting as a dropdown button component.
<kelp-disclosure is-dropdown>
<button>Options</button>
<ul>
<!-- ... -->
</ul>
</kelp-disclosure>For both patterns, you need an [aria-pressed] attribute, an optional [aria-controls], and the same event listeners. The UI just looks a little different.
So it made sense to combine them.
For dropdown menus, though, users often expect that when focus leaves the menu, the dropdown menu will automatically close.
And here’s where Safari gets weird…
In Safari, buttons don’t get focused when clicked
In every other browser, if you click a button, it also receives focus.
That means you can listen for blur events, check if focus is still inside the dropdown menu, and if not, close it.
But in Safari, because the button never receives focus, it never loses focus, so the blur event never fires.
I caught the issue because I use Playwright for testing, and it uses real browsers instead of a simulated JSDOM like Vitest and Jest and many others do.
The fix is annoying (I have to listen for click events on the entire document instead of blur events within my component). But it works, at least.
Safari says this isn’t a bug
More annoying than the fix is that according to the Safari team, this is working as intended!
This is the benefit:
Mac users expect the focus to remain in the text field if you click on a button. That’s what happens everywhere else on their computer in all the Mac applications. It’s a benefit that buttons work as expected, consistent with other buttons on the Mac, and don’t pull the focus away from the text field you are already typing in.
I understand that if you’ve never used a Mac you might not be aware that this is a benefit, but I assure you that it is.
This is some nonsense, frankly.
As a Mac user, I expect websites to behave consistently. I don’t expect them to behave like my OS.
WTF is the point of Web Standards, even, if this is the attitude?
Last week, HalleAndert ran a poll on Mastodon asking…
Which browser causes you the most display problems when you write standard and compatible CSS?
The overwhelming majority said Safari.
While my issue was HTML/JS related, clearly there’s a pattern here!
Options are good
I appreciate that Safari continues to offer an alternative to Chromium’s web dominance and Firefox/Mozilla chasing its own ass and seemingly having no clue what their users actually want in a browser.
But if they operate in opposition to the web rather than in service of it, Safari is actually more harmful (in my opinion) than if it didn’t exist at all.
I really want them to do better. And with the talent they have on the Safari team and pockets as deep as Apple’s, there’s no reason they shouldn’t be able to other than Apple leadership deliberately holding them back.
Like this? A Lean Web Club membership is the best way to support my work and help me create more free content.
This content originally appeared on Go Make Things and was authored by Go Make Things
Go Make Things | Sciencx (2025-11-20T14:30:00+00:00) Safari strikes again. Retrieved from https://www.scien.cx/2025/11/20/safari-strikes-again/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.