138816 2014-11-17 17:31:30 -0800 :active behavior for touch depends on the presence of touch event handlers 2026-01-20 19:49:17 -0800 1 1 1 Unclassified WebKit UI Events 528+ (Nightly build) Unspecified iOS 8.1 NEW P2 Normal --- 1 rbyers a_protyasha karlcow linma vasko.dinkov oldest_to_newest 1049367 0 rbyers 2014-11-17 17:31:30 -0800 Mobile Safari applies :active on touchstart and clears it on touchend. This has some surprising consequences including: - A page with no touch event handlers doesn't get :active effects at all - A button with an :active effect will be triggered while scrolling over top of it (even though native platform convention is not to trigger active effects in such cases) I changed this for chromium back in 2012 (see bug 96060 and http://crbug.com/133928). Basically we set :active after a short delay when tap starts (what we call "GestureShowPress"), and clear it when a tap completes or is aborted (but we may also delay this to ensure :active is shown long enough to be visible when the user taps quickly). What do you think, is it perhaps worth changing Safari to do something more rational here? I'm open to changing chromium again if we can come up with a model we agree is better. One thing I don't like about our current model is that it's difficult to implement the same behavior from JS (unlike IE and Safari, there are no DOM events associated directly with the application and removal of :active for touch). 1049368 1 benjamin 2014-11-17 17:34:55 -0800 Thanks for filing this. 1155408 2 vasko.dinkov 2016-01-14 02:30:46 -0800 In the docs we have this: https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariWebContent/AdjustingtheTextSize/AdjustingtheTextSize.html ------- You can also use the -webkit-tap-highlight-color CSS property >>>in combination with setting a touch event<<< to configure buttons to behave similar to the desktop. On iOS, mouse events are sent so quickly that the down or active state is never received. Therefore, the :active pseudo state is triggered only when there is a touch event set on the HTML element—for example, when ontouchstart is set on the element as follows: <button class="action" ontouchstart="" style="-webkit-tap-highlight-color: rgba(0,0,0,0);">Testing Touch on iOS</button> Now when the button is tapped and held on iOS, the button changes to the specified color without the surrounding transparent gray color appearing. ------- Currently in iOS (just confirmed in 8.1 but I believe it's the same in 9), when any touch* event is set to the document (or any parent container) all child elements are also affected and start showing the :hover/:active styles immediately if we touch them even if we just want to scroll the page. This can be quite annoying on specific pages where :hover/:active styles are applied on big elements and even more when transitions, etc. are used (example: scroll to the footer of http://phonegap.com/ and then try scrolling the page up by touching any of the big white links). This issue affects large amount of websites and popular frameworks like jQuery mobile, etc. I don't see any logic why setting any touch* event handler to an element would trigger this behavior change. This looks more like an actual documented hack. It would have been much better if, for example, a vendor prefixed -webkit-* CSS property was introduced for the purpose instead. IMHO it should be fixed like in Chrome/Android with the timeout logic Rick Byers describes above. According to my testing it works really well the way they've implemented it. 1921319 3 linma 2022-12-22 01:07:21 -0800 Here is a simple html that shows the problem. <html> <style> button { -webkit-tap-highlight-color: transparent; } button:active { background-color: red; } </style> <body> <button>Button</button> </body> </html> On iOS, the button doesn't become red when pressed. All other platforms handles :active properly, Safari on iOS is alone in this behaviour. Out of curiosity, is this bug still being considered? 2058713 4 rbyers 2024-09-09 13:37:09 -0700 Verified this still reproduces in iOS 17.6.1. Simple repro: https://output.jsbin.com/danijir It's a decade later and one of the most basic features of the web on mobile (UI states responding to touch) still isn't standards compliant in WebKit. https://html.spec.whatwg.org/multipage/semantics-other.html#selector-active Unassigning from Benjamin since AFAIK he doesn't work on WebKit anymore. Perhaps someone else wants to pick up this longstanding strange quirk in WebKit?