Proposed Chromium policy on JavaScript dialogs | Hacker News Reader

Proposed Chromium policy on JavaScript dialogs

developers.google.com

45 pointsr72118 comments

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.

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

The main proposal (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.

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 clusterfk 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.

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

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!

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.

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.

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...

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...

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

100% agreeing.

In 2017, not being able to have native dialog, a datepicker or a solid i18l for content is just sad.

Looks like <dialog> only works in blink so far, and it's not easily polyfilled unfortunatley

>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...

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."

" Alexander Nestorov 51 minutes ago - Shared publicly

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

Very good point =P

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.

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

Reply on news.ycombinator.com