Re: [whatwg] JavaScript dialogs blocking user experience

> On Apr 14, 2016, at 1:04 PM, Domenic Denicola <d@domenic.me> wrote:
> 
> 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.

Here are two things we might want to address in the specification—not sure either is practical:

- Find some place to emphasize the importance of having UI driven by a webpage not seem to come from the browser or operating system and not block user interface that lets a user “leave”. Documenting this kind of thing makes it more practical to build a new browser engine, cutting down on the “unwritten lore” needed to make an acceptable user experience. I think making this clear is important for the Simple Dialogs feature, but also many other features such as full screen modes. Maybe this calls for a section like the “Security and privacy” section someone wrote for registerProtocolHandler?

- This one is even more “aspirational”: Clarify the relationship between multiple webpages that are separately running JavaScript. When content from the same website is open in multiple windows, the ancient classic version of these Simple Dialogs functions in the oldest web browsers accidentally guaranteed that everything in both windows was paused until the user responded. I think it would be good if there was some way we could clearly state to website authors that this is not the case any more. Ideally we would find a way to make it practical to quickly discover if a website author accidentally relied on something like that, but I am not optimistic that we can.

— Darin

Received on Thursday, 14 April 2016 20:25:46 UTC