From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of
> The problem you describe above was addressed by Apple in iOS 9.3 and also > in Safari 9.1 on Mac. That release changed the style of JavaScript alerts so > that they are less likely to appear to come from Safari, the operating system, > or Apple. They look more like part of a webpage, and no longer interfere > with closing a tab or webpage, using the back button to leave the webpage, > or using the smart search field to enter a new search or website address. Yes, this is pretty great! +Avi, who sits next to me on the Chrome team, has started a similar project for Chrome, inspired very much by Safari's example: https://docs.google.com/document/d/1wtV5rmLhbf1OZkbg7crtCt6h1mMtig_ctTQt3BLLEIU/edit?pref=2&pli=1 I'm not sure whether this has much of a spec impact. The spec already allows great leniency in these areas; e.g. https://html.spec.whatwg.org/multipage/webappapis.html#dom-alert step 3 and the "optionally" in step 7. If any browser has qualms with the current language and would like it to be more flexible, we're certainly open to that, in the same spirit as the semi-recent https://github.com/whatwg/html/pull/714. Maybe we could consider adding language like "this must not block navigation or other parts of the user interface" to step 6, now that more browsers appear to be moving in that direction. But practically these changes are mostly being driven by browsers interested in improving the user experience for their users, and trying to hurry up that process by adding spec language seems like it wouldn't accomplish much. > I don’t think that’s the same topic, though, as what this thread was > originally > about. I forked the thread, since this topic seems sufficiently interesting on its own.
