Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Mon, 5 Mar 2012, Biju wrote: Today I again landed on a malicious site which trap users using alert/confirm to download some application. On Mon, 5 Mar 2012, Rick Waldron wrote: All three of these are considered highly effective tools in mobile web development - they offer functional UI for free. On Tue, 6 Mar 2012, Biju wrote: along with window.open() malicious sites also love those features. to make browsing safe (especially for kids, non techies) we need to ban alert/confirm/prompt And we should have an alternative to window.open() may by a CONTROL attribute for IFRAME tag. ie, IFRAME src=http://google.com; CONTROL /IFRAME will create a dragable/movable IFRAME with title bar, a pop-up button. If user clicks on pop-up button it pops out of the webpage. I don't think there's any reason to believe that malware authors would be any less able to use that kind of UI than alert(). Historically, the problem with alert() and friends is that they are implemented in a bit of a blunt manner. However, this has been improving. Browsers offer to abort the script, browsers keep them modal to less than the entire browser, browsers detect abuse patterns like multiple alerts in a row, etc. Practically speaking, we can't stop supporting them. Lots of the Web rely on them. So there's no point deprecating them, it wouldn't change anything. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
Today I again landed on a malicious site which trap users using alert/confirm to download some application. URL : http://usaaccount2.com/?q=MzI1ODA0MTZEkBZYYoU0AEZuUVlSQUVaV0lWc05hc0NnenljeURJTABhOTNkNTY2M2YwNmI1OWIxZWI1NTEwYjE0ZDg1NjE0M2VkZGUzOTZkMjUwN2Q5M2NlYWI2Yzk5NzA5NjkxY2NlNjM0NTMzZmU4M2Q5ZDA5NgBEQWVCd1psR0pqRklrTFJIb1MxMzMwOTk3MzQzbVdPWU53SlBLbjc= (or go it by http://snipurl.com/22hv8zh ) I landed there when I got redirected from. http://ndia-tvc.org/jiamd_luncheon_18nov08/pages/letter-formation-worksheets I think that page is hacked as its links and contents is not same as other regular page at http://ndia-tvc.org/ Also I feel if download is not triggered by CLICK event browsers should not prompt user to download content that not HTML/JPG/PNG. Cheers Biju On 6 February 2012 19:03, Ian Hickson i...@hixie.ch wrote: On Tue, 10 Jan 2012, Ojan Vafai wrote: The only complaint I'm aware of is in http://crbug.com/97206. The bug comments are confusing. The primary issue there is WebKit not firing beforeunload/unload from frames in some cases, but there is one comment about code that calls confirm from unload handlers followed by a sync XHR to save data that now breaks. I've specced this (it's optional for now). I didn't check how closely what I specced matches Chrome. -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
All three of these are considered highly effective tools in mobile web development - they offer functional UI for free. Rick On Mon, Mar 5, 2012 at 10:34 PM, Biju bijumaill...@gmail.com wrote: Today I again landed on a malicious site which trap users using alert/confirm to download some application. URL : http://usaaccount2.com/?q=MzI1ODA0MTZEkBZYYoU0AEZuUVlSQUVaV0lWc05hc0NnenljeURJTABhOTNkNTY2M2YwNmI1OWIxZWI1NTEwYjE0ZDg1NjE0M2VkZGUzOTZkMjUwN2Q5M2NlYWI2Yzk5NzA5NjkxY2NlNjM0NTMzZmU4M2Q5ZDA5NgBEQWVCd1psR0pqRklrTFJIb1MxMzMwOTk3MzQzbVdPWU53SlBLbjc= (or go it by http://snipurl.com/22hv8zh ) I landed there when I got redirected from. http://ndia-tvc.org/jiamd_luncheon_18nov08/pages/letter-formation-worksheets I think that page is hacked as its links and contents is not same as other regular page at http://ndia-tvc.org/ Also I feel if download is not triggered by CLICK event browsers should not prompt user to download content that not HTML/JPG/PNG. Cheers Biju On 6 February 2012 19:03, Ian Hickson i...@hixie.ch wrote: On Tue, 10 Jan 2012, Ojan Vafai wrote: The only complaint I'm aware of is in http://crbug.com/97206. The bug comments are confusing. The primary issue there is WebKit not firing beforeunload/unload from frames in some cases, but there is one comment about code that calls confirm from unload handlers followed by a sync XHR to save data that now breaks. I've specced this (it's optional for now). I didn't check how closely what I specced matches Chrome. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On 5 March 2012 23:52, Rick Waldron waldron.r...@gmail.com wrote: All three of these are considered highly effective tools in mobile web development - they offer functional UI for free. along with window.open() malicious sites also love those features. to make browsing safe (especially for kids, non techies) we need to ban alert/confirm/prompt see pages listed at https://www.google.com/search?q=worksheet%20site:ndia-tvc.org (even if you report phishing they point to new renamed site. in this case http://ndia-tvc.org not the phishing site, but it just is the infested site ) And we should have an alternative to window.open() may by a CONTROL attribute for IFRAME tag. ie, IFRAME src=http://google.com; CONTROL /IFRAME will create a dragable/movable IFRAME with title bar, a pop-up button. If user clicks on pop-up button it pops out of the webpage.
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Tue, 10 Jan 2012, Adam Barth wrote: On Tue, Jan 10, 2012 at 2:35 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 14 Jun 2011, Adam Barth wrote: On Tue, Jun 14, 2011 at 2:03 PM, Alexey Proskuryakov a...@webkit.org wrote: 28.02.2011, в 21:38, Ojan Vafai написал(а): FWIW, chromium is planning on experimenting with disallowing modal dialogs during the beforeunload/unload events. http://code.google.com/p/chromium/issues/detail?id=68780 What is the big difference between alerts from unload and alerts in general? Alerts are not particularly useful for anything besides debugging, and pagehide/unload handlers is a place where they I've found them particularly useful for debugging. Do we have at least anecdotal evidence that many sites are showing alerts from unload? When I'm seeing a site that tries to prevent me from leaving it, it's always by returning a string from onbeforeunload. I believe the motivation is to be able to close tabs quickly. If a tab doesn't register for any unload / beforeunload events, the tab can be kill instantly. If the site registers for unload but not beforeunload, then, today, we need to wait for JavaScript to execute before closing the tab. Without the ability to trigger alert and friends during unload, we can hide the tab instantly and unload it in the background. We have lots of stats for how many tabs would benefit from this optimization and how much time would be saved. It's surprisingly large. Any news on this? If Chrome was able to do this, it would be worth putting in the spec to give cover to other browsers interested in the same potential performance improvement. Ojan probably has more concrete data. I think we got one or two complaints, but no major problems. On Tue, 10 Jan 2012, Ojan Vafai wrote: The only complaint I'm aware of is in http://crbug.com/97206. The bug comments are confusing. The primary issue there is WebKit not firing beforeunload/unload from frames in some cases, but there is one comment about code that calls confirm from unload handlers followed by a sync XHR to save data that now breaks. I've specced this (it's optional for now). I didn't check how closely what I specced matches Chrome. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Tue, 14 Jun 2011, Adam Barth wrote: On Tue, Jun 14, 2011 at 2:03 PM, Alexey Proskuryakov a...@webkit.org wrote: 28.02.2011, в 21:38, Ojan Vafai написал(а): FWIW, chromium is planning on experimenting with disallowing modal dialogs during the beforeunload/unload events. http://code.google.com/p/chromium/issues/detail?id=68780 What is the big difference between alerts from unload and alerts in general? Alerts are not particularly useful for anything besides debugging, and pagehide/unload handlers is a place where they I've found them particularly useful for debugging. Do we have at least anecdotal evidence that many sites are showing alerts from unload? When I'm seeing a site that tries to prevent me from leaving it, it's always by returning a string from onbeforeunload. I believe the motivation is to be able to close tabs quickly. If a tab doesn't register for any unload / beforeunload events, the tab can be kill instantly. If the site registers for unload but not beforeunload, then, today, we need to wait for JavaScript to execute before closing the tab. Without the ability to trigger alert and friends during unload, we can hide the tab instantly and unload it in the background. We have lots of stats for how many tabs would benefit from this optimization and how much time would be saved. It's surprisingly large. Any news on this? If Chrome was able to do this, it would be worth putting in the spec to give cover to other browsers interested in the same potential performance improvement. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Tue, Jan 10, 2012 at 2:35 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 14 Jun 2011, Adam Barth wrote: On Tue, Jun 14, 2011 at 2:03 PM, Alexey Proskuryakov a...@webkit.org wrote: 28.02.2011, в 21:38, Ojan Vafai написал(а): FWIW, chromium is planning on experimenting with disallowing modal dialogs during the beforeunload/unload events. http://code.google.com/p/chromium/issues/detail?id=68780 What is the big difference between alerts from unload and alerts in general? Alerts are not particularly useful for anything besides debugging, and pagehide/unload handlers is a place where they I've found them particularly useful for debugging. Do we have at least anecdotal evidence that many sites are showing alerts from unload? When I'm seeing a site that tries to prevent me from leaving it, it's always by returning a string from onbeforeunload. I believe the motivation is to be able to close tabs quickly. If a tab doesn't register for any unload / beforeunload events, the tab can be kill instantly. If the site registers for unload but not beforeunload, then, today, we need to wait for JavaScript to execute before closing the tab. Without the ability to trigger alert and friends during unload, we can hide the tab instantly and unload it in the background. We have lots of stats for how many tabs would benefit from this optimization and how much time would be saved. It's surprisingly large. Any news on this? If Chrome was able to do this, it would be worth putting in the spec to give cover to other browsers interested in the same potential performance improvement. Ojan probably has more concrete data. I think we got one or two complaints, but no major problems. Adam
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Tue, Jan 10, 2012 at 2:38 PM, Adam Barth w...@adambarth.com wrote: On Tue, Jan 10, 2012 at 2:35 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 14 Jun 2011, Adam Barth wrote: On Tue, Jun 14, 2011 at 2:03 PM, Alexey Proskuryakov a...@webkit.org wrote: 28.02.2011, в 21:38, Ojan Vafai написал(а): FWIW, chromium is planning on experimenting with disallowing modal dialogs during the beforeunload/unload events. http://code.google.com/p/chromium/issues/detail?id=68780 What is the big difference between alerts from unload and alerts in general? Alerts are not particularly useful for anything besides debugging, and pagehide/unload handlers is a place where they I've found them particularly useful for debugging. Do we have at least anecdotal evidence that many sites are showing alerts from unload? When I'm seeing a site that tries to prevent me from leaving it, it's always by returning a string from onbeforeunload. I believe the motivation is to be able to close tabs quickly. If a tab doesn't register for any unload / beforeunload events, the tab can be kill instantly. If the site registers for unload but not beforeunload, then, today, we need to wait for JavaScript to execute before closing the tab. Without the ability to trigger alert and friends during unload, we can hide the tab instantly and unload it in the background. We have lots of stats for how many tabs would benefit from this optimization and how much time would be saved. It's surprisingly large. Any news on this? If Chrome was able to do this, it would be worth putting in the spec to give cover to other browsers interested in the same potential performance improvement. Ojan probably has more concrete data. I think we got one or two complaints, but no major problems. The only complaint I'm aware of is in http://crbug.com/97206. The bug comments are confusing. The primary issue there is WebKit not firing beforeunload/unload from frames in some cases, but there is one comment about code that calls confirm from unload handlers followed by a sync XHR to save data that now breaks. Ojan
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Tue, Jun 14, 2011 at 2:03 PM, Alexey Proskuryakov a...@webkit.org wrote: 28.02.2011, в 21:38, Ojan Vafai написал(а): FWIW, chromium is planning on experimenting with disallowing modal dialogs during the beforeunload/unload events. http://code.google.com/p/chromium/issues/detail?id=68780 What is the big difference between alerts from unload and alerts in general? Alerts are not particularly useful for anything besides debugging, and pagehide/unload handlers is a place where they I've found them particularly useful for debugging. Do we have at least anecdotal evidence that many sites are showing alerts from unload? When I'm seeing a site that tries to prevent me from leaving it, it's always by returning a string from onbeforeunload. I believe the motivation is to be able to close tabs quickly. If a tab doesn't register for any unload / beforeunload events, the tab can be kill instantly. If the site registers for unload but not beforeunload, then, today, we need to wait for JavaScript to execute before closing the tab. Without the ability to trigger alert and friends during unload, we can hide the tab instantly and unload it in the background. We have lots of stats for how many tabs would benefit from this optimization and how much time would be saved. It's surprisingly large. Adam
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
28.02.2011, в 21:38, Ojan Vafai написал(а): FWIW, chromium is planning on experimenting with disallowing modal dialogs during the beforeunload/unload events. http://code.google.com/p/chromium/issues/detail?id=68780 What is the big difference between alerts from unload and alerts in general? Alerts are not particularly useful for anything besides debugging, and pagehide/unload handlers is a place where they I've found them particularly useful for debugging. Do we have at least anecdotal evidence that many sites are showing alerts from unload? When I'm seeing a site that tries to prevent me from leaving it, it's always by returning a string from onbeforeunload. - WBR, Alexey Proskuryakov
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Fri, Jun 10, 2011 at 2:35 PM, Aryeh Gregor simetrical+...@gmail.com wrote: Do we have any data on whether these warnings have any useful effect? I don't, but then, browsers barely ever emit such warnings. So it would be worth trying to mark some methods as deprecated in this fashion and see if it's useful, if browsers are interested in going along with it. I'd predict that it would help out some percentage of savvier authors. Currently some authors try to avoid writing code that validators tell them is bad, so it's a good guess that some would try to avoid writing code that browsers tell them is bad. In theory Gecko emits a bunch of warnings for obsolete bits. http://mxr.mozilla.org/mozilla-central/source/dom/locales/en-US/chrome/dom/dom.properties?rev=c551b62cf2e8mark=53-62#53 53 DocumentAllUsed=Non-standard document.all property was used. Use W3C standard document.getElementById() instead. 54 GlobalScopeElementReference=Element referenced by ID/NAME in the global scope. Use W3C standard document.getElementById() instead. 55 UseOfCaptureEventsWarning=Use of captureEvents() is deprecated. To upgrade your code, use the DOM 2 addEventListener() method. For more help http://developer.mozilla.org/en/docs/DOM:element.addEventListener 56 UseOfReleaseEventsWarning=Use of releaseEvents() is deprecated. To upgrade your code, use the DOM 2 removeEventListener() method. For more help http://developer.mozilla.org/en/docs/DOM:element.removeEventListener 57 UseOfRouteEventWarning=Use of routeEvent() is deprecated. To upgrade your code, use the DOM 2 dispatchEvent() method. For more help http://developer.mozilla.org/en/docs/DOM:element.dispatchEvent 58 UseOfPreventBubbleWarning=Event=%S, use of preventBubble() is deprecated. Use W3C standard stopPropagation() instead. 59 UseOfPreventCaptureWarning=Event=%S, use of preventCapture() is deprecated. Use W3C standard stopPropagation() instead. 60 UseOfDOM3LoadMethodWarning=Use of Document.load() is deprecated. To upgrade your code, use the DOM XMLHttpRequest object. For more help https://developer.mozilla.org/en/XMLHttpRequest 61 UnexpectedCanvasVariantStyle=canvas: an attempt to set strokeStyle or fillStyle to a value that is neither a string, a CanvasGradient, or a CanvasPattern was ignored. 62 EmptyGetElementByIdParam=Empty string passed to getElementById(). Warning: Non-standard document.all property was used. Use W3C standard document.getElementById() instead. Source File: data:text/html,scriptdocument.all.foo/script Line: 1 Is one example.
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Thu, Jun 9, 2011 at 3:49 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 1 Mar 2011, Aryeh Gregor wrote: We could define script APIs, or features of them, as deprecated if browsers were willing to log some kind of notice to their error consoles when the feature is used. They all have error consoles with different reporting levels already, so it shouldn't be a pain for them to implement. They can have the deprecation warnings off by default so they don't clutter the output. At least Firefox already does this for some things, like document.getSelection() (although that message will probably go away in a future release). Of course, this would only be useful if we had a good alternative to recommend. Don't use alert(), use some giant JavaScript library instead is unlikely to be a very helpful message. But it would be nice for some of the crazier or more horrible APIs, if they have saner replacements. Do we have any data on whether these warnings have any useful effect? I don't, but then, browsers barely ever emit such warnings. So it would be worth trying to mark some methods as deprecated in this fashion and see if it's useful, if browsers are interested in going along with it. I'd predict that it would help out some percentage of savvier authors. Currently some authors try to avoid writing code that validators tell them is bad, so it's a good guess that some would try to avoid writing code that browsers tell them is bad. Of course, we'd have to be careful to only do this when we're reasonably sure that authors really want to never use the feature even in legacy code, not for every property or method that we wish didn't exist. I'm not sure if there really are very many such properties or methods.
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Tue, 1 Mar 2011, Ojan Vafai wrote: FWIW, chromium is planning on experimenting with disallowing modal dialogs during the beforeunload/unload events. http://code.google.com/p/chromium/issues/detail?id=68780 Please let us know how this goes, so I can update the spec accordingly (to at least allow this, or maybe require it, depending on how other browser vedors feel about this). On Tue, 1 Mar 2011, Robert O'Callahan wrote: That sounds fairly unpleasant for users of pages which give are you sure you want to leave this page and lose your data? warnings. Presumably this would continue to work, indeed. On Tue, 1 Mar 2011, WeBMartians wrote: On 2011-02-28 19:42, Ian Hickson wrote: On Thu, 25 Nov 2010, Biju wrote: 2. if we are still keeping them, can we disable them in onbeforeunload/onunload[/onhide] etc. Many sites add extra dialogs in those events to confuse users, so that they can trap users for little longer. That's not a bad idea. I recommend approaching the browser vendors to see if they are willing to implement it; if they do, then updating the spec accordingly would be a no-brainer. I agree that the various traps put in place are exceptionally annoying. An alternative would be a forced closing via the browser rather than some modification of the behavior of Javascript. That would side step the question of Have you covered all of the annoying cases (onbeforeunload, on unload, on hide...)?. Well the browser is always allowed to just close things willy nilly, sure. 3. also if we are keeping them, can we add an optional parameter for a timeout milliseconds to self dismiss the modal prompt. What's the use case? For comment 3, simply reference the use cases for Microsoft's AfxMsgBox, ::MessageBox and its derivatives. The time out is a well-received idea. On Tue, 1 Mar 2011, Aryeh Gregor wrote: Timeouts on dialogs are typically a terrible idea, and we shouldn't encourage them. They mean that if the user wasn't paying attention -- which could just mean they were looking at another tab, in browsers with tab-modal dialogs -- they never see the dialog. This is only useful in the case where the dialog is so useless you don't actually care if the user doesn't see it, in which case, why show it? In practice, authors often add timeouts to things that they expect the user to see, leaving the user confused if they don't wind up seeing it. IIRC, one of the nice little improvements I made to MediaWiki a few years ago was removing the last of the timed redirects from it. OS APIs are much more enthusiastic about permitting programmers to shoot themselves in the foot than web APIs. Microsoft specifically also cares much more about developers and less about users, because they depend on developers to write Windows-only apps and maintain Microsoft's lock-in, while users are forced to buy Windows anyway. Browsers, on the other hand, care very strongly about users, because users can easily switch to another browser at any time, while developers (authors) don't help or hurt them much as long as they write cross-browser code. So for multiple reasons, the fact that Windows supports something doesn't mean we should. You need to give actual specific use-cases, not just cite the fact that the feature exists in Windows. I have to agree with Aryeh here. On Tue, 1 Mar 2011, WeBMartians wrote: Aryeh! You have made an ad-hominem attack: shame on you! I mention the Microsoft use cases only to save space. There are similar cases in the Linux and Macintosh realms. Judge an idea by its merits, not by its source (even if that source is as disreputable as I certainly am). The existence of an API is not a use case (and Aryeh's comments weren't an ad hominem attack -- the only attack, if any, was in the description of timer-based messaging APIs as terrible, but he backed that up with sound reasoning). You are correct that short duration time outs are, often, a terrible idea ... but the standard should not hobble the developer. Terrible ideas are a matter of opinion; my ideas are always grand and glorious, never terrible ... just ask me ... for I never lie and am always right. It's our job to filter out the bad ideas. ...and consider this: just how would you handle the case in which the WWWeb page says: There is an approaching storm! Do you wish to close the dykes? No (let everybody drown) Yes (if you don't answer in an hour, this will be the default) To say that the WWWeb should not be used for this is in itself a terrible idea for you know that it will be used in this manner and neither of us can prevent such stupidities. I think this kind of thing might be reasonable to have, but the way to do that is probably more using a non-modal inline dialog, so that the script can react to the storm's sudden growth or disappearance as well. On Tue, 1 Mar 2011, Aryeh
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Tue, Mar 1, 2011 at 9:52 PM, WeBMartians webmarti...@verizon.net wrote: Aryeh! You have made an ad-hominem attack: shame on you! I mention the Microsoft use cases only to save space. There are similar cases in the Linux and Macintosh realms. Judge an idea by its merits, not by its source (even if that source is as disreputable as I certainly am). I didn't make any ad hominem attacks. I pointed out that we want use-cases, not just the fact that something is present in an OS API. Possibly Linux and/or Mac have similar APIs, but it still wouldn't help your case if there are no concrete use-cases you can present. OS implementers have very different audiences and goals than browser implementers, and just because OS implementers add a feature doesn't mean browser implementers will want to. You are correct that short duration time outs are, often, a terrible idea ... but the standard should not hobble the developer. Attempting to prevent developers from doing bad things to users, either through malice or incompetence, is a recurring theme in web APIs. ...and consider this: just how would you handle the case in which the WWWeb page says: There is an approaching storm! Do you wish to close the dykes? No (let everybody drown) Yes (if you don't answer in an hour, this will be the default) Is this meant to be in a multiplayer game, where the player has to make a decision within an hour? I don't think such a game would want to use modal dialogs at all, because they prevent JS from running, so it wouldn't be able to update its state as long as the dialog is displayed. They should use custom dialogs instead. More generally, any proposed addition to alert()/prompt()/confirm() needs to explain why its intended audience would actually use those APIs to begin with instead of hacking something more flexible up in JavaScript. They're not the best tool for almost any job except a very simple one.
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Tue, Mar 1, 2011 at 6:38 PM, Ojan Vafai o...@chromium.org wrote: FWIW, chromium is planning on experimenting with disallowing modal dialogs during the beforeunload/unload events. http://code.google.com/p/chromium/issues/detail?id=68780 That sounds fairly unpleasant for users of pages which give are you sure you want to leave this page and lose your data? warnings. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
For comment 3, simply reference the use cases for Microsoft's AfxMsgBox, ::MessageBox and its derivatives. The time out is a well-received idea. As to comment 2, I agree that the various traps put in place are exceptionally annoying. An alternative would be a forced closing via the browser rather than some modification of the behavior of Javascript. That would side step the question of Have you covered all of the annoying cases (onbeforeunload, on unload, on hide...)?. On 2011-02-28 19:42, Ian Hickson wrote: On Thu, 25 Nov 2010, Biju wrote: 1. Can we deprecate alert(), confirm(), prompt() ? At present many web2.0 js libs are providing alternate [and cool looking] methods to achieve use cases where we need to use alert(), confirm(), prompt(). So do we need those modal dialogs any longer? Well we can't remove support for them from browsers, since millions of pages use them. Conformance checkers can't really complain about usage of those APIs, since they can't easily check JavaScript runtime compliance. So what would deprecating them mean? 2. if we are still keeping them, can we disable them in onbeforeunload/onunload[/onhide] etc. Many sites add extra dialogs in those events to confuse users, so that they can trap users for little longer. That's not a bad idea. I recommend approaching the browser vendors to see if they are willing to implement it; if they do, then updating the spec accordingly would be a no-brainer. 3. also if we are keeping them, can we add an optional parameter for a timeout milliseconds to self dismiss the modal prompt. What's the use case? On Thu, 25 Nov 2010, Biju wrote: In a software application there is no need to have prompt to the user if the application is not planning to do any branching after user response. When we have alert(), it dont give user any choice other than pressing OK Hence it not possible to code any branching statement after result of user action. (with exception Press OK after you insert DVD to the drive ) So only use for alert() I see is not make a delay, that use case can be improved if web programmer can provide a default time out. As you point out in your original e-mail, it seems like this kind of use case is better handled by Web 2.0 JavaScript libraries. In the medium term I expect we will introduce a feature to create modal and non-modal in-page dialogs using markup, so this will likely become moot. On Thu, 25 Nov 2010, Markus Ernst wrote: Maybe, instead of your original suggestion, it might be worth thinking about making alert()/confirm()/prompt() dialogs styleable via CSS? Then those fancy JS lib dialogs would get obsolete, and we had the favour of both nice look and support for the special purposes of those dialogs. This would be a side-effect of the aforementioned markup-based dialogs. On Thu, 25 Nov 2010, Biju wrote: The request I put is NOT about whether you can make it PRETTY looking or not. The question is about why we are allowing website have something which is MODAL (ie, both window modal and tab modal https://bugzilla.mozilla.org/show_bug.cgi?id=59314) In my opinion a no website should have that much control over user interaction. On Thu, 25 Nov 2010, Nikita Popov wrote: That alert()s, prompt()s and confirm()s are window-modal is only an implementation issue: Some years ago browsers implemented these prompts the most convenient way: By opening a native modal dialog. But right now broswer vendors realize that this isn't really the best solution - because of DOS attacks and simply because it doesn't make any sense. And as you already mentioned: Firefox landed tab-modal dialogs a few days ago. Opera already had them. Other browsers will follow. On Thu, 25 Nov 2010, Markus Ernst wrote: Opera even provided a Stop executing scripts checkbox in the alert() dialog for years already, which made it my preferred browser for debugging my scripts (handy if you have forgotten an i++ in a loop, and placed an alert() inside). Indeed. On Thu, 25 Nov 2010, Benjamin Poulain wrote: The specification deprecates some elements that use to be widely used (the elements font, big, center, etc). Actually it obsoletes them. Deprecating is only a recommendation for authors to not use the feature. It's hard to effectively do that with script since there's no good way to do scripting validation.
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
2011-03-01 11:13 EEST: Robert O'Callahan: On Tue, Mar 1, 2011 at 6:38 PM, Ojan Vafai o...@chromium.org wrote: FWIW, chromium is planning on experimenting with disallowing modal dialogs during the beforeunload/unload events. http://code.google.com/p/chromium/issues/detail?id=68780 That sounds fairly unpleasant for users of pages which give are you sure you want to leave this page and lose your data? warnings. We already have onbeforeunload that almost does the trick... How about adding a new property for this that needs to be set before user tries to unload the page in the first place. For example: window.onbeforeunloadmessage defaults to an empty string and if this property is set to non-empty string, then the UA should prompt this message with buttons Close anyway and Stay on page (or equivalent) before unloading the document. This allows for following fixes to current unload and onbeforeunload features: - Page script must set this message at the moment the page should not be closed without consideration - UA may display visual clue that a tab should not be closed even before the closing is tried - UA does not need to run any JS code before closing a tab because this is only a string that is either empty or not - UA may disable/stop running JS the moment the user tries to close the tab and continue running JS only if user hits the Stay on page button. What do you think? -- Mikko
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Tue, Mar 1, 2011 at 1:13 AM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Mar 1, 2011 at 6:38 PM, Ojan Vafai o...@chromium.org wrote: FWIW, chromium is planning on experimenting with disallowing modal dialogs during the beforeunload/unload events. http://code.google.com/p/chromium/issues/detail?id=68780 That sounds fairly unpleasant for users of pages which give are you sure you want to leave this page and lose your data? warnings. Please see my identical question and Tab's answer, which Ojan's reply quoted. PK
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Mon, Feb 28, 2011 at 7:42 PM, Ian Hickson i...@hixie.ch wrote: Well we can't remove support for them from browsers, since millions of pages use them. Conformance checkers can't really complain about usage of those APIs, since they can't easily check JavaScript runtime compliance. So what would deprecating them mean? We could define script APIs, or features of them, as deprecated if browsers were willing to log some kind of notice to their error consoles when the feature is used. They all have error consoles with different reporting levels already, so it shouldn't be a pain for them to implement. They can have the deprecation warnings off by default so they don't clutter the output. At least Firefox already does this for some things, like document.getSelection() (although that message will probably go away in a future release). Of course, this would only be useful if we had a good alternative to recommend. Don't use alert(), use some giant JavaScript library instead is unlikely to be a very helpful message. But it would be nice for some of the crazier or more horrible APIs, if they have saner replacements. On Tue, Mar 1, 2011 at 9:12 AM, WeBMartians webmarti...@verizon.net wrote: For comment 3, simply reference the use cases for Microsoft's AfxMsgBox, ::MessageBox and its derivatives. The time out is a well-received idea. Timeouts on dialogs are typically a terrible idea, and we shouldn't encourage them. They mean that if the user wasn't paying attention -- which could just mean they were looking at another tab, in browsers with tab-modal dialogs -- they never see the dialog. This is only useful in the case where the dialog is so useless you don't actually care if the user doesn't see it, in which case, why show it? In practice, authors often add timeouts to things that they expect the user to see, leaving the user confused if they don't wind up seeing it. IIRC, one of the nice little improvements I made to MediaWiki a few years ago was removing the last of the timed redirects from it. OS APIs are much more enthusiastic about permitting programmers to shoot themselves in the foot than web APIs. Microsoft specifically also cares much more about developers and less about users, because they depend on developers to write Windows-only apps and maintain Microsoft's lock-in, while users are forced to buy Windows anyway. Browsers, on the other hand, care very strongly about users, because users can easily switch to another browser at any time, while developers (authors) don't help or hurt them much as long as they write cross-browser code. So for multiple reasons, the fact that Windows supports something doesn't mean we should. You need to give actual specific use-cases, not just cite the fact that the feature exists in Windows.
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
Aryeh! You have made an ad-hominem attack: shame on you! I mention the Microsoft use cases only to save space. There are similar cases in the Linux and Macintosh realms. Judge an idea by its merits, not by its source (even if that source is as disreputable as I certainly am). You are correct that short duration time outs are, often, a terrible idea ... but the standard should not hobble the developer. Terrible ideas are a matter of opinion; my ideas are always grand and glorious, never terrible ... just ask me ... for I never lie and am always right. ...and consider this: just how would you handle the case in which the WWWeb page says: There is an approaching storm! Do you wish to close the dykes? No (let everybody drown) Yes (if you don't answer in an hour, this will be the default) To say that the WWWeb should not be used for this is in itself a terrible idea for you know that it will be used in this manner and neither of us can prevent such stupidities. By-the-Way - I advocate no change to alerts and such ... the above can be implemented with setTimeout without any changes to existing browsers. Best (and please understand my admonitions to be accompanied by affection and great respect)! BdG/WeBMartians === On 2011-03-01 19:46, Aryeh Gregor wrote: On Mon, Feb 28, 2011 at 7:42 PM, Ian Hicksoni...@hixie.ch wrote: Well we can't remove support for them from browsers, since millions of pages use them. Conformance checkers can't really complain about usage of those APIs, since they can't easily check JavaScript runtime compliance. So what would deprecating them mean? We could define script APIs, or features of them, as deprecated if browsers were willing to log some kind of notice to their error consoles when the feature is used. They all have error consoles with different reporting levels already, so it shouldn't be a pain for them to implement. They can have the deprecation warnings off by default so they don't clutter the output. At least Firefox already does this for some things, like document.getSelection() (although that message will probably go away in a future release). Of course, this would only be useful if we had a good alternative to recommend. Don't use alert(), use some giant JavaScript library instead is unlikely to be a very helpful message. But it would be nice for some of the crazier or more horrible APIs, if they have saner replacements. On Tue, Mar 1, 2011 at 9:12 AM, WeBMartianswebmarti...@verizon.net wrote: For comment 3, simply reference the use cases for Microsoft's AfxMsgBox, ::MessageBox and its derivatives. The time out is a well-received idea. Timeouts on dialogs are typically a terrible idea, and we shouldn't encourage them. They mean that if the user wasn't paying attention -- which could just mean they were looking at another tab, in browsers with tab-modal dialogs -- they never see the dialog. This is only useful in the case where the dialog is so useless you don't actually care if the user doesn't see it, in which case, why show it? In practice, authors often add timeouts to things that they expect the user to see, leaving the user confused if they don't wind up seeing it. IIRC, one of the nice little improvements I made to MediaWiki a few years ago was removing the last of the timed redirects from it. OS APIs are much more enthusiastic about permitting programmers to shoot themselves in the foot than web APIs. Microsoft specifically also cares much more about developers and less about users, because they depend on developers to write Windows-only apps and maintain Microsoft's lock-in, while users are forced to buy Windows anyway. Browsers, on the other hand, care very strongly about users, because users can easily switch to another browser at any time, while developers (authors) don't help or hurt them much as long as they write cross-browser code. So for multiple reasons, the fact that Windows supports something doesn't mean we should. You need to give actual specific use-cases, not just cite the fact that the feature exists in Windows.
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Thu, 25 Nov 2010, Biju wrote: 1. Can we deprecate alert(), confirm(), prompt() ? At present many web2.0 js libs are providing alternate [and cool looking] methods to achieve use cases where we need to use alert(), confirm(), prompt(). So do we need those modal dialogs any longer? Well we can't remove support for them from browsers, since millions of pages use them. Conformance checkers can't really complain about usage of those APIs, since they can't easily check JavaScript runtime compliance. So what would deprecating them mean? 2. if we are still keeping them, can we disable them in onbeforeunload/onunload[/onhide] etc. Many sites add extra dialogs in those events to confuse users, so that they can trap users for little longer. That's not a bad idea. I recommend approaching the browser vendors to see if they are willing to implement it; if they do, then updating the spec accordingly would be a no-brainer. 3. also if we are keeping them, can we add an optional parameter for a timeout milliseconds to self dismiss the modal prompt. What's the use case? On Thu, 25 Nov 2010, Biju wrote: In a software application there is no need to have prompt to the user if the application is not planning to do any branching after user response. When we have alert(), it dont give user any choice other than pressing OK Hence it not possible to code any branching statement after result of user action. (with exception Press OK after you insert DVD to the drive ) So only use for alert() I see is not make a delay, that use case can be improved if web programmer can provide a default time out. As you point out in your original e-mail, it seems like this kind of use case is better handled by Web 2.0 JavaScript libraries. In the medium term I expect we will introduce a feature to create modal and non-modal in-page dialogs using markup, so this will likely become moot. On Thu, 25 Nov 2010, Markus Ernst wrote: Maybe, instead of your original suggestion, it might be worth thinking about making alert()/confirm()/prompt() dialogs styleable via CSS? Then those fancy JS lib dialogs would get obsolete, and we had the favour of both nice look and support for the special purposes of those dialogs. This would be a side-effect of the aforementioned markup-based dialogs. On Thu, 25 Nov 2010, Biju wrote: The request I put is NOT about whether you can make it PRETTY looking or not. The question is about why we are allowing website have something which is MODAL (ie, both window modal and tab modal https://bugzilla.mozilla.org/show_bug.cgi?id=59314) In my opinion a no website should have that much control over user interaction. On Thu, 25 Nov 2010, Nikita Popov wrote: That alert()s, prompt()s and confirm()s are window-modal is only an implementation issue: Some years ago browsers implemented these prompts the most convenient way: By opening a native modal dialog. But right now broswer vendors realize that this isn't really the best solution - because of DOS attacks and simply because it doesn't make any sense. And as you already mentioned: Firefox landed tab-modal dialogs a few days ago. Opera already had them. Other browsers will follow. On Thu, 25 Nov 2010, Markus Ernst wrote: Opera even provided a Stop executing scripts checkbox in the alert() dialog for years already, which made it my preferred browser for debugging my scripts (handy if you have forgotten an i++ in a loop, and placed an alert() inside). Indeed. On Thu, 25 Nov 2010, Benjamin Poulain wrote: The specification deprecates some elements that use to be widely used (the elements font, big, center, etc). Actually it obsoletes them. Deprecating is only a recommendation for authors to not use the feature. It's hard to effectively do that with script since there's no good way to do scripting validation. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Mon, Feb 28, 2011 at 4:42 PM, Ian Hickson i...@hixie.ch wrote: 2. if we are still keeping them, can we disable them in onbeforeunload/onunload[/onhide] etc. Many sites add extra dialogs in those events to confuse users, so that they can trap users for little longer. That's not a bad idea. I recommend approaching the browser vendors to see if they are willing to implement it; if they do, then updating the spec accordingly would be a no-brainer. Isn't this important for the you're trying to navigate away from gmail with an open draft; abandon changes y/n? case? PK
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Mon, Feb 28, 2011 at 4:49 PM, Peter Kasting pkast...@google.com wrote: On Mon, Feb 28, 2011 at 4:42 PM, Ian Hickson i...@hixie.ch wrote: 2. if we are still keeping them, can we disable them in onbeforeunload/onunload[/onhide] etc. Many sites add extra dialogs in those events to confuse users, so that they can trap users for little longer. That's not a bad idea. I recommend approaching the browser vendors to see if they are willing to implement it; if they do, then updating the spec accordingly would be a no-brainer. Isn't this important for the you're trying to navigate away from gmail with an open draft; abandon changes y/n? case? No, that's handled by having the onbeforeunload handler return a string containing the query you want to show. ~TJ
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
FWIW, chromium is planning on experimenting with disallowing modal dialogs during the beforeunload/unload events. http://code.google.com/p/chromium/issues/detail?id=68780 On Tue, Mar 1, 2011 at 11:57 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Mon, Feb 28, 2011 at 4:49 PM, Peter Kasting pkast...@google.com wrote: On Mon, Feb 28, 2011 at 4:42 PM, Ian Hickson i...@hixie.ch wrote: 2. if we are still keeping them, can we disable them in onbeforeunload/onunload[/onhide] etc. Many sites add extra dialogs in those events to confuse users, so that they can trap users for little longer. That's not a bad idea. I recommend approaching the browser vendors to see if they are willing to implement it; if they do, then updating the spec accordingly would be a no-brainer. Isn't this important for the you're trying to navigate away from gmail with an open draft; abandon changes y/n? case? No, that's handled by having the onbeforeunload handler return a string containing the query you want to show. ~TJ
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Thu, Nov 25, 2010 at 3:30 AM, Nils Dagsson Moskopp 1. Can we deprecate alert(), confirm(), prompt() ? If sites rely on them, it is not possible to deprecate them. That is why I asked to deprecate, but not obsolete.. However, I melieve browsers are making these dialogs tab-modal. Yes I know but still there are problems https://bugzilla.mozilla.org/show_bug.cgi?id=613800#c1 (I assume that will be fixed) But see also https://bugzilla.mozilla.org/show_bug.cgi?id=391834 2. if we are still keeping them, can we disable them in onbeforeunload/onunload[/onhide] etc. Many sites add extra dialogs in those events to confuse users, so that they can trap users for little longer. “Do you want to save your complicated mashup?” For that we dont need alert/confirm/prompt. Return value in onbeforeunload will take care of it You may want to also look Jesse Ruderman suggestion on that https://bugzilla.mozilla.org/show_bug.cgi?id=578828 3. also if we are keeping them, can we add an optional parameter for a timeout milliseconds to self dismiss the modal prompt. Why would you need that? This is especially useful with alert() In a software application there is no need to have prompt to the user if the application is not planning to do any branching after user response. When we have alert(), it dont give user any choice other than pressing OK Hence it not possible to code any branching statement after result of user action. (with exception Press OK after you insert DVD to the drive ) So only use for alert() I see is not make a delay, that use case can be improved if web programmer can provide a default time out. On Thu, Nov 25, 2010 at 3:41 AM, a...@ashleysheridan.co.uk a...@ashleysheridan.co.uk wrote: Modal dialogues have a very special purpose, which works consistently across various browsers in that we can program in with javascript some very specific responses. What would happen if someone came to your site with a speech/Braille browser? How would they know your pretty js lib built That is a valid point. But how many good sites use alert/confirm/prompt for every thing. So all those case speech/Braille browser have problem to deal with. If we want use that feature the web site need to code their site for speech/Braille browser. If that is the case we could achieve same thing with HTML.
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On 11/25/2010 08:30 AM, ext Nils Dagsson Moskopp wrote: Bijubijumaill...@gmail.com schrieb am Thu, 25 Nov 2010 02:29:31 1. Can we deprecate alert(), confirm(), prompt() ? At present many web2.0 js libs are providing alternate [and cool looking] methods to achieve use cases where we need to use alert(), confirm(), prompt(). So do we need those modal dialogs any longer? If sites rely on them, it is not possible to deprecate them. The specification deprecates some elements that use to be widely used (the elements font, big, center, etc). Deprecating is only a recommendation for authors to not use the feature. I would personally welcome a better alternative to alert(), confirm(), prompt(). Something explicitly page modal and not pseudo-blocking Javascript. Although in my opinion, it would not make sense to deprecate without a good alternative for modal dialogs. cheers, Benjamin
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Thu, Nov 25, 2010 at 8:26 AM, Benjamin Poulain Although in my opinion, it would not make sense to deprecate without a good alternative for modal dialogs. But how many good sites use it. Only place in GMail is when user try to send mail with no text in Subject or Body field. Which they will be able to rewrite with the same way they do for blank To/cc/bcc address field.
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
Am 25.11.2010 13:21 schrieb Biju: On Thu, Nov 25, 2010 at 3:41 AM, a...@ashleysheridan.co.uk a...@ashleysheridan.co.uk wrote: Modal dialogues have a very special purpose, which works consistently across various browsers in that we can program in with javascript some very specific responses. What would happen if someone came to your site with a speech/Braille browser? How would they know your pretty js lib built That is a valid point. But how many good sites use alert/confirm/prompt for every thing. So all those case speech/Braille browser have problem to deal with. If we want use that feature the web site need to code their site for speech/Braille browser. If that is the case we could achieve same thing with HTML. Maybe, instead of your original suggestion, it might be worth thinking about making alert()/confirm()/prompt() dialogs styleable via CSS? Then those fancy JS lib dialogs would get obsolete, and we had the favour of both nice look and support for the special purposes of those dialogs.
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Thu, Nov 25, 2010 at 1:45 PM, Markus Ernst derer...@gmx.ch wrote: Maybe, instead of your original suggestion, it might be worth thinking about making alert()/confirm()/prompt() dialogs styleable via CSS? Then those fancy JS lib dialogs would get obsolete, and we had the favour of both nice look and support for the special purposes of those dialogs. Hear, hear. I really like those dialogs, they are very easy and nice to use. However, Internet Explorer doesn't support prompt(), which is incredible irritating and infuriating. So I had to implement one of those js-libs instead, and tell you what? That was NOT a nice experience, I tried many different ones, none were as easy and to-the-point as just the nice prompt(). -- Beste helsing, Odin Hørthe Omdal odin.om...@gmail.com http://velmont.no
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Thu, Nov 25, 2010 at 8:45 AM, Markus Ernst Maybe, instead of your original suggestion, it might be worth thinking about making alert()/confirm()/prompt() dialogs styleable via CSS? Then those fancy JS lib dialogs would get obsolete, and we had the favour of both nice look and support for the special purposes of those dialogs. The request I put is NOT about whether you can make it PRETTY looking or not. The question is about why we are allowing website have something which is MODAL (ie, both window modal and tab modal https://bugzilla.mozilla.org/show_bug.cgi?id=59314) In my opinion a no website should have that much control over user interaction.
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On 25.11.2010 15:55, Biju wrote: The request I put is NOT about whether you can make it PRETTY looking or not. The question is about why we are allowing website have something which is MODAL (ie, both window modal and tab modal https://bugzilla.mozilla.org/show_bug.cgi?id=59314) In my opinion a no website should have that much control over user interaction. Well, you just said it: Bug 59314! That alert()s, prompt()s and confirm()s are window-modal is only an implementation issue: Some years ago browsers implemented these prompts the most convenient way: By opening a native modal dialog. But right now broswer vendors realize that this isn't really the best solution - because of DOS attacks and simply because it doesn't make any sense. And as you already mentioned: Firefox landed tab-modal dialogs a few days ago. Opera already had them. Other browsers will follow. So, what is your issue?
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
Am 25.11.2010 17:12 schrieb Nikita Popov: On 25.11.2010 15:55, Biju wrote: The request I put is NOT about whether you can make it PRETTY looking or not. Sorry, that was how I understood point 1 your initial message. The question is about why we are allowing website have something which is MODAL (ie, both window modal and tab modal https://bugzilla.mozilla.org/show_bug.cgi?id=59314) In my opinion a no website should have that much control over user interaction. Well, you just said it: Bug 59314! That alert()s, prompt()s and confirm()s are window-modal is only an implementation issue: Some years ago browsers implemented these prompts the most convenient way: By opening a native modal dialog. But right now broswer vendors realize that this isn't really the best solution - because of DOS attacks and simply because it doesn't make any sense. And as you already mentioned: Firefox landed tab-modal dialogs a few days ago. Opera already had them. Opera even provided a Stop executing scripts checkbox in the alert() dialog for years already, which made it my preferred browser for debugging my scripts (handy if you have forgotten an i++ in a loop, and placed an alert() inside).
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Thu, Nov 25, 2010 at 1:29 AM, Biju bijumaill...@gmail.com wrote: 1. Can we deprecate alert(), confirm(), prompt() ? At present many web2.0 js libs are providing alternate [and cool looking] methods to achieve use cases where we need to use alert(), confirm(), prompt(). So do we need those modal dialogs any longer? It's a very basic feature, necessary even for Hello World-type coding in JavaScript. We shouldn't require authors to use libraries to get this functionality. 2. if we are still keeping them, can we disable them in onbeforeunload/onunload[/onhide] etc. Many sites add extra dialogs in those events to confuse users, so that they can trap users for little longer. This is a browser implementation issue. Browsers should allow users to suppress modal dialogs, and should make them tab-modal instead of window-modal. They're in the process of doing this -- no spec change is needed, and a spec change will not speed the process. 3. also if we are keeping them, can we add an optional parameter for a timeout milliseconds to self dismiss the modal prompt. You mean the author should be able to add a parameter saying dismiss this alert() after 10 seconds if the user hasn't clicked? That's a bad idea. What if I opened the tab in the background, or had another window active, or was just off getting coffee when the dialog popped up? I'd never see it. We shouldn't make it easy for authors to do this.
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
Biju bijumaill...@gmail.com schrieb am Thu, 25 Nov 2010 02:29:31 -0400: 1. Can we deprecate alert(), confirm(), prompt() ? At present many web2.0 js libs are providing alternate [and cool looking] methods to achieve use cases where we need to use alert(), confirm(), prompt(). So do we need those modal dialogs any longer? If sites rely on them, it is not possible to deprecate them. However, I melieve browsers are making these dialogs tab-modal. 2. if we are still keeping them, can we disable them in onbeforeunload/onunload[/onhide] etc. Many sites add extra dialogs in those events to confuse users, so that they can trap users for little longer. “Do you want to save your complicated mashup?” 3. also if we are keeping them, can we add an optional parameter for a timeout milliseconds to self dismiss the modal prompt. Why would you need that? Cheers, -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net signature.asc Description: PGP signature
Re: [whatwg] Can we deprecate alert(), confirm() , prompt() ?
I'm not sure what your definition of web 2.0 is, but its not about the way something looks. Removing those modal dialogues would be a very bad idea indeed. There are still valid uses for them, even if they have been abused in the past. Thinking your way, we ought to get rid of the ability to open new windows and display flash too. Modal dialogues have a very special purpose, which works consistently across various browsers in that we can program in with javascript some very specific responses. What would happen if someone came to your site with a speech/Braille browser? How would they know your pretty js lib built interface was meant to be modal? You could implement a modal switch, but then you're back to where you were with the existing methods! These modal dialogues are a whole lot more than appearances, as they have a behaviour to them that just cannot be replicated as well in as many cases as it may be required. Thanks, Ash http://www.ashleysheridan.co.uk - Reply message - From: Biju bijumaill...@gmail.com Date: Thu, Nov 25, 2010 06:29 Subject: [whatwg] Can we deprecate alert(), confirm(), prompt() ? To: whatwg wha...@whatwg.org 1. Can we deprecate alert(), confirm(), prompt() ? At present many web2.0 js libs are providing alternate [and cool looking] methods to achieve use cases where we need to use alert(), confirm(), prompt(). So do we need those modal dialogs any longer? 2. if we are still keeping them, can we disable them in onbeforeunload/onunload[/onhide] etc. Many sites add extra dialogs in those events to confuse users, so that they can trap users for little longer. 3. also if we are keeping them, can we add an optional parameter for a timeout milliseconds to self dismiss the modal prompt. Thanks Biju
