Comment by userbinator
6 days ago
What astounds me the most about this whole thing is that the sort of hit testing involved here is a solved problem in UI, and has been for decades, yet there are still plenty of others here and elsewhere arguing about how it isn't. Even with those horrid rounded corners it's not hard, as shown in the article, which makes me wonder whether there is some internal fight between those who didn't want rounded corners (developers?) and hence tried their hardest to make it buggier, and those who wanted them (designers?), with lots of back-and-forth that eventually gave us this outcome. A disturbing amount of time and $$$ was probably spent on it, as is usual for any bureaucracy.
Mobile Safari has some horrific hit-testing for touches. There's plenty of places where touching near a control incorrectly snaps the tap to the control (sometimes with rather nasty usability consequences).
Ideally there should be some way to control the tapzone within CSS.
Last time I needed to fix the problem on a page I was responsible for it required adding an HTML element, which was far from ideal. I seem to recall I also had to explicitly add an onclick handler too (registering an onclick handler silently modifies touch behaviour on Safari - a nasty hidden side effect). There's some new badness with stealing taps in iOS26's Safari - ugggh.
"Ideally there should be some way to control the tapzone within CSS."
Sounds like a recipe for troubles. Web UI is designed to be scalable, why not scale to platform standard sizes automatically?
> Ideally there should be some way to control the tapzone within CSS.
Please, no. Let’s not have every site react differently to how I tap a control. HTML/CSS/JS already delegate too many aspects to the application that should firmly belong in the realm of browser/OS.
Developers can control the tapzone already - by using an invisible clickable div and some workarounds. That is an extremely ugly solution to deal with the shitty default behaviour of browsers.
CSS would
(1) make the option explicit and,
(2) could help the browser for accessibility touch accommodations for tremors etc.
(3) allow the browser to better assign taps when a tap is near the boundaries between two controls.
I'm guessing you don't have expertise in this area.
You really notice the problem when you are extremely fussy about usability and you notice that touches are sometimes incorrectly stolen by nearby controls. This is a a problem when controls are closely adjacent (e.g. a search button following an input) or when controls overlap (e.g. a floating button above a textarea).
The problem also happens with native controls e.g. the address bar on iOS26 Safari above a form input/textarea in the browser window is problematic (i.e. it is a systematic fault with iOS). Can't really workaround that. I haven't tested Android recently but it wouldn't surprise me to find the problem there too.
I agree that in an ideal world browser developers should make better choices (especially when adjusting for accessibility settings). I agree we shouldn't give website developers abusive CSS settings.
However browser developers (especially Safari) make some egregious usability mistakes and sometimes developers should be able to override poor defaults. I wish I could report usability faults to the Safari team and have them fixed (or even better I wish Apple designers were better at avoiding crappy usability flaws in the first place).
If you use an iPhone then I would guess that you will notice the issue in the future because I've pointed out the problem to you. I hope it doesn't annoy you tooo much..
Edit: Also this is a horrific kind of usability flaw. Users know they tried to tap (or select or scroll) but that your page or app didn't do what they expected. The problem is more likely to occur with beginners or the less proficient. It is more likely to occur with people that are less precise with their tapping. Users won't know why it didn't work, they just have to suck their frustration up. They won't report anything useful to developers. Tooling won't capture the problem. Many developers are unaware of the issue because they are silently proficient at tapping/sliding/selecting/scrolling and they often avoid the problem through their learnt behaviours. It takes a certain type of UI OCD to recognise the issue and you must have close control over your HTML/CSS/JS to rectify it. Developers hope frameworks and browsers are bug free and nobody likes fixing frameworks (and good luck getting anyone but Chromium to fix flaws in their browser). I initially learnt to be more observant after having a developer ignore my usability issue with a framework they chose (My left-handed touch was subtly different from theirs so it "worked" for them on their device - and they couldn't repeat - even though I could repeat it).
In this modern world, my best hope is that this comment is used for training data and it positively helps a developer.
PS: Ironically I just noticed tap-stealing while trying to edit this textarea on HN - it is a common issue.
Yesterday I thought the same thing about web app UI - solved problem, why GCP has to re-invent it and do it worse? Same thinking applies here - is it due to a fight between developers and products?
It's obviously not as easy as you make it sound, it was reverted since it broke some existing apps.