Smoke.js - A framework-agnostic styled alert/confirm system for javascript

I like its simplicity.<p>But, I thought this was dead:<p><pre><code> onClick="javascript:smoke.alert('this is a normal alert');" </code></pre> ... apparently, not.<p>The 'javascript:' (attempted psuedo protocol), is just acting as a pointless label here.<p>I also thought we said goodbye to obtrusive JS altogether.<p>Also, the API isn't great. There's no instance to work with... It doesn't work in IE7 (probably because it doesn't cater for non-W3C events APIs). The source is littered with getElementById calls, and non configurable HTML IDs and classes. And it uses the window's 'load' event to initiate itself, when there's absolutely no need to. There's also 'smoketimeout' polluting the global scope when it could just be a property of the 'smoke' object itself.

Similar interface <a href="http://thrivingkings.com/apprise/" rel="nofollow">http://thrivingkings.com/apprise/</a>

Looks useful, but why make smoke.confirm work differently from plain confirm? It uglifies the API for no gain, IMHO.

I feel like the alert and confirm modals should not be allowed to be dismissed by clicking outside. Especially confirm: "Destroy all. Yes, No?" -&#62; click outside...nothing.

I wouldn't use it, because it doesn't use the main hotkeys for user interaction on the alert box (enter, space) or the confirm box (enter, space, escape).<p>I also would have liked it better, if the default functions of alert and confirm would have been overwritten, instead of recreated into an object. Overwriting the existent functions would have been made it a snap to integrate smoke.js into existing projects.

I wish it also did prompt(). That would save a lot of work when you just want to input one field or want to let users copy-paste a URL to the page.<p>Edit: rgbrgb posted <a href="http://news.ycombinator.com/item?id=2748038" rel="nofollow">http://news.ycombinator.com/item?id=2748038</a> about Apprise. It does what smoke.js does and then some. Thanks

Doesn't work on ipad

Fly.<p>On the usability tip, why don't you allow making the dialog appear near the user's mouse? Having to move it from the link (or wherever the user's mouse is at the time) to the action buttons is unnecessary.

Show stopper for me is that it breaks the convention of disabling clicking with alerts and confirms.

want to get the gold star? make it to where I can have a styled confirmation box when onbeforeunload gets fired and make it have cross-browser support

It seems to be broken on an iPad.

I like the CSS stylings.

Sorry, but this is the latest entry in obsolete and obtrusive functionality. It's useless for mobile (just tested iOS Safari and Opera), which is the platform you should start with, and it's been proven out to be an annoying hindrance to the user on the desktop.<p>Don't interrupt CRUD. If you can't trust the user to not perform an irreversible action, then you're doing it wrong.