
Proposed Chromium policy on JavaScript dialogs - r721
https://developers.google.com/web/updates/2017/03/dialogs-policy
======
kalleboo
The proposal says that Safari "dismisses dialogs when a tab is switched away
from" which clashes with what "dismissing a dialog" means to me. To me,
"dismiss a dialog" means hitting cancel/esc so the dialog is gone forever.

What Safari does these days is has replaced the OS modal dialog with an in-tab
custom modal dialog (that basically looks like your typical custom "javascript
dialog" rounded-corner white DIV with a drop shadow and dimmed page cover),
and when you switch tabs, the dialog is still there on the old page, it's just
not blocking anything else. In practice this works beautifully.

~~~
JoshTriplett
Firefox has done that for the last several versions as well.

------
amluto
The main proposal ([https://crbug.com/629964](https://crbug.com/629964))
doesn't remove the old features; it just makes them per-tab, as they always
should have been. This is IMO better in essentially all respects. Your code
will keep working.

------
px1999
They're suggesting avoiding long-standing useful functionality because some
people abuse it. There's no viable simple alternative to each of these
methods, which is _why_ they're in common use. They provide a reliable way to
stop the user from interacting with the page until they've received a
notification / provided a piece of data. onbeforeunload provides a way for a
page to have the user ensure that data is saved before they navigate away.
More importantly, they're one-liners.

No proposed alternative achieves these goals, and they definitely don't
achieve them as simply or as elegantly. I understand switching alerts from
app- to tab-modal, but when did the web become such a clusterf __k of
complexity? Not every page needs (or should need) to bring in their own dialog
library, to save changes incrementally, or be concerned about users not
accepting notifications before being able to provide important information to
them.

This policy makes no sense because it recommends using ~10 lines of code which
probably won't work for all your users in place of the 1 that definitely will.
Telling people to avoid alert etc (by threatening to break the functionality
in the future) just avoids actually solving the problem (which they could do)
by taking away an incredibly useful and important piece of functionality.

------
jontro
Funny how google calendar abuses alert to steal focus right before an event is
scheduled. They're not really following their own best practices

------
mschuster91
Great. Really great. /s

Let me explain the /s:

alert/prompt/confirm have one very huge advantage: they're native. Which
means: screenreaders, tab, escape and everything I expect from the OS are
working consistently across sites.

Now people will have to implement the wheel all over again - everyone will do
it a bit different, 90% won't give a sh.t if tab works and 99% won't care if
Esc works. It will be the fake-scrollbar-styling once again.

Stop messing around and replacing OS-native stuff with lowest-grade JS
bullsh.t. Thanks!

~~~
comex
Esc is handled automatically by the suggested replacement <dialog>, although
only Chrome has implemented <dialog> so far.

With respect to Tab, doesn't that problem already exist in all other (non-
dialog) web content? If a webpage's dialogs are accessible but everything else
is broken, I feel like you're going to have a bad time regardless… Though I
suppose that if you're not impaired and typically use the mouse to click
buttons, but are used to using the keyboard for dialogs, this could be an
annoyance.

~~~
mschuster91
The problem is most people will skip over the "make it feel really native"
part, except when they're forced by law (ADA comes to my mind). It costs a lot
to implement right across browsers and even more to properly test.

To make it worse: Windoes has different native UI than OS X, and on linux it
entirely depends on the desktop environment and window manager - there is no
way to "get it native" there, so it is a loss of consistency.

Oh, and JS cr.p also does not know about stuff like OS color schemes, DPI
settings, OS-level-set hotkeys etc., so all this will be lost.

------
notamy
One thing I don't get. They recommend using <dialog> instead, but the MDN page
they link to[0] explicitly says

> This is an experimental technology

> Because this technology's specification has not stabilized, check the
> compatibility table for usage in various browsers. Also note that the syntax
> and behavior of an experimental technology is subject to change in future
> versions of browsers as the specification changes.

Which makes me wonder about backwards-compatibility-handling etc.

[0] [https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/di...](https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/dialog)

~~~
niftich
Up until 2016-08-23, Service Workers were marked in MDN as experimental [1],
despite the concentrated push by various parties to get people to stop using
stuff like AppCache and use Service Workers instead.

That being said, at least Dialog is part of both the WHATWG HTML5 "Living
Standard" (a fancy name for snapshot), and the W3C HTML 5.1 Recommendation,
making it approved and finalized by both the practical body of rapidly-
evolving browser makers and the political body that historically set web
standards. In contrast, Service Workers are still a draft, despite having been
pushed for years, and its predecessor technologies having largely been
deprecated.

In other words, this is quite normal in the world of the Web Platform today,
for better and for worse.

[1] [https://developer.mozilla.org/en-
US/docs/Web/API/Service_Wor...](https://developer.mozilla.org/en-
US/docs/Web/API/Service_Worker_API$history)

~~~
TheAceOfHearts
I'd argue that any serious production app should still be using both AppCache
and Service Worker. Heck, if you have AppCache setup and working already, why
would you remove it? Service Worker isn't supported by Internet Explorer,
Safari, or Firefox ESR. Those browsers can account for a large portion of the
market, depending on your target demographic.

The <dialog> element is supported in even fewer browsers [0]! You can sorta
polyfill it, but not perfectly.

[0] [http://caniuse.com/#feat=dialog](http://caniuse.com/#feat=dialog)

------
gruez
>For XSS proofs-of-concept, devtool’s console.log(document.origin) can be
used.

meanwhile, in blink-dev:
[https://groups.google.com/a/chromium.org/forum/#!topic/blink...](https://groups.google.com/a/chromium.org/forum/#!topic/blink-
dev/CO52Bt15cuc)

------
aidos
Interesting tidbit:

"What is Site Engagement? Site Engagement is a measure of how much the user
interacts with a site. The more that a user visits/uses a site, the higher the
engagement score is. If you want to see engagement scores on your Chrome,
check out chrome://site-engagement."

------
carlosdp
" Alexander Nestorov 51 minutes ago - Shared publicly

Does this mean that you'll finally stop using alert() on Google Calendar? :)﻿
"

Very good point =P

------
Pxtl
Wait, onbeforeunload is going away too? So no more "you have unsaved changes
are you sure you want to close the tab?"

And yes, just make the popups modal to the tab instead of modal to the browser
and stop breaking the web with standards churn.

------
jasonkostempski
Darn, though this was going to be about JS requiring a user prompt to run.

