5 ms·

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

100 points by js4all 15y ago

consultutah 15y ago
Doesn't work on ipad
- workhorse 15y ago
  Doesn't work on the iPhone either.
wulczer 15y ago
Looks useful, but why make smoke.confirm work differently from plain confirm? It uglifies the API for no gain, IMHO.
- georgefox 15y ago
  How would you make it return true/false immediately when the user has to click OK or Cancel?
  - wulczer 15y ago
    Oh, good point. I clearly need more caffeine in my system.
libria 15y ago
I feel like the alert and confirm modals should not be allowed to be dismissed by clicking outside. Especially confirm: "Destroy all. Yes, No?" -> click outside...nothing.
- beaumartinez 15y ago
  It's the "panic" action, akin to a "close dialog" button. Clicking outside (should) default to the "safe" choice, in this case, "no".
  - nitrogen 15y ago
    I would disagree. If there is a choice to be made, and that choice truly matters, I believe there should be no way to accidentally make the choice.
padolsey 15y ago
I like its simplicity. But, I thought this was dead: onClick="javascript:smoke.alert('this is a normal alert');" ... apparently, not. The 'javascript:' (attempted psuedo protocol), is just acting as a pointless label here. I also thought we said goodbye to obtrusive JS altogether. 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.
- JangoSteve 15y ago
  Most of that is no doubt due to the fact that it's framework-agnostic, meaning it can't rely on all the things frameworks like jquery do to make it easy to create reliable, unobtrusive javascript. I don't so much have a problem with the getElementById calls, as that really is the best and quickest way to do things. Even jQuery's $('#some-element') selector is simply calling getElementById('some-element') under the hood and then wrapping it in a jQuery object. And technically the onClick stuff can still be unobtrusive, as long as the link still works as intended with javascript disabled (i.e. it's a normal link and doesn't have something like href="#". But all technicalities aside, I totally agree with your sentiment. Almost every site I build now is using jQuery or some other framewor; I'd prefer not to use some library that has to re-implement all the bindings and selectors and browser-specific hacks and work-arounds that are already being included elsewhere in my framework. Furthermore, if my site is so low-level or small that it can't easily include jQuery, I doubt I'll be worried about replacing or trying to spruce up the standard javascript confirm dialog.
  - oinksoft 15y ago
    var listen = function(el, evt, cbk) { if (el.addEventListener) { el.addEventListener(evt, cbk, false); } else { el.attachEvent('on' + evt, cbk); } }; No jQuery or whatever necessary ... if all you're doing is basic event handling and you know how the DOM works for other things, it really isn't much trouble to include this and a couple other small functions in a one-off, and is far preferable to including a hefty all-purpose DOM abstraction library like jQuery or MooTools. Their example including an ugly onclick attribute doesn't imply that that is the only way to do things, it merely demonstrates the absolute simplest way to use the library. Of course any fool can use a script that includes the function above and locates the element manually.
jsavimbi 15y ago
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. Don't interrupt CRUD. If you can't trust the user to not perform an irreversible action, then you're doing it wrong.
- baggachipz 15y ago
  Noticed that it didn't work on my iPad as well. May be an early release, but mobile compatibility is crucial.
rgbrgb 15y ago
Similar interface http://thrivingkings.com/apprise/ http://thrivingkings.com/apprise/
- BillSaysThis 15y ago
  +1 for Apprise
beaumartinez 15y ago
Fly. 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.
- nitrogen 15y ago
  A counterpoint: I don't like things that appear near my mouse. My mouse is rarely positioned where I'm looking, and anything that appears under my mouse when I'm about to click on something interferes with (and occasionally "steals") normal clicks. The worst is when a dialog pops up with important information, and the OK or Cancel button right under the mouse, just as I was halfway through clicking on something else.
chopsueyar 15y ago
I like the CSS stylings.
feydr 15y ago
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
chris_engel 15y ago
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). 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.
- frankil 15y ago
  To my knowledge, you can't overwrite the existent confirm function because you can't pause the running of JS like the standard function does.
dav-id 15y ago
It seems to be broken on an iPad.
taitems 15y ago
Show stopper for me is that it breaks the convention of disabling clicking with alerts and confirms.
chime 15y ago
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. Edit: rgbrgb posted http://news.ycombinator.com/item?id=2748038 http://news.ycombinator.com/item?id=2748038 about Apprise. It does what smoke.js does and then some. Thanks

100 points by js4all 15y ago

consultutah 15y ago

Doesn't work on ipad

workhorse 15y ago
Doesn't work on the iPhone either.

wulczer 15y ago

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

georgefox 15y ago
How would you make it return true/false immediately when the user has to click OK or Cancel?
- wulczer 15y ago
  Oh, good point. I clearly need more caffeine in my system.

libria 15y ago

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

beaumartinez 15y ago
It's the "panic" action, akin to a "close dialog" button. Clicking outside (should) default to the "safe" choice, in this case, "no".
- nitrogen 15y ago
  I would disagree. If there is a choice to be made, and that choice truly matters, I believe there should be no way to accidentally make the choice.

padolsey 15y ago

I like its simplicity. But, I thought this was dead: onClick="javascript:smoke.alert('this is a normal alert');" ... apparently, not. The 'javascript:' (attempted psuedo protocol), is just acting as a pointless label here. I also thought we said goodbye to obtrusive JS altogether. 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.

JangoSteve 15y ago
Most of that is no doubt due to the fact that it's framework-agnostic, meaning it can't rely on all the things frameworks like jquery do to make it easy to create reliable, unobtrusive javascript. I don't so much have a problem with the getElementById calls, as that really is the best and quickest way to do things. Even jQuery's $('#some-element') selector is simply calling getElementById('some-element') under the hood and then wrapping it in a jQuery object. And technically the onClick stuff can still be unobtrusive, as long as the link still works as intended with javascript disabled (i.e. it's a normal link and doesn't have something like href="#". But all technicalities aside, I totally agree with your sentiment. Almost every site I build now is using jQuery or some other framewor; I'd prefer not to use some library that has to re-implement all the bindings and selectors and browser-specific hacks and work-arounds that are already being included elsewhere in my framework. Furthermore, if my site is so low-level or small that it can't easily include jQuery, I doubt I'll be worried about replacing or trying to spruce up the standard javascript confirm dialog.
- oinksoft 15y ago
  var listen = function(el, evt, cbk) { if (el.addEventListener) { el.addEventListener(evt, cbk, false); } else { el.attachEvent('on' + evt, cbk); } }; No jQuery or whatever necessary ... if all you're doing is basic event handling and you know how the DOM works for other things, it really isn't much trouble to include this and a couple other small functions in a one-off, and is far preferable to including a hefty all-purpose DOM abstraction library like jQuery or MooTools. Their example including an ugly onclick attribute doesn't imply that that is the only way to do things, it merely demonstrates the absolute simplest way to use the library. Of course any fool can use a script that includes the function above and locates the element manually.

jsavimbi 15y ago

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. Don't interrupt CRUD. If you can't trust the user to not perform an irreversible action, then you're doing it wrong.

baggachipz 15y ago
Noticed that it didn't work on my iPad as well. May be an early release, but mobile compatibility is crucial.

rgbrgb 15y ago

Similar interface http://thrivingkings.com/apprise/ http://thrivingkings.com/apprise/

BillSaysThis 15y ago
+1 for Apprise

beaumartinez 15y ago

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

nitrogen 15y ago
A counterpoint: I don't like things that appear near my mouse. My mouse is rarely positioned where I'm looking, and anything that appears under my mouse when I'm about to click on something interferes with (and occasionally "steals") normal clicks. The worst is when a dialog pops up with important information, and the OK or Cancel button right under the mouse, just as I was halfway through clicking on something else.

chopsueyar 15y ago

I like the CSS stylings.

feydr 15y ago

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

chris_engel 15y ago

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

frankil 15y ago
To my knowledge, you can't overwrite the existent confirm function because you can't pause the running of JS like the standard function does.

dav-id 15y ago

It seems to be broken on an iPad.

taitems 15y ago

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

chime 15y ago

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. Edit: rgbrgb posted http://news.ycombinator.com/item?id=2748038 http://news.ycombinator.com/item?id=2748038 about Apprise. It does what smoke.js does and then some. Thanks