
Smoke.js - A framework-agnostic styled alert/confirm system for javascript - js4all
http://ssssnakes.com/smoke/
======
padolsey
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
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

      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.

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

Why is that far preferable?

So you can throw out all that extra code as soon as your events have to
actually _do_ something, and you decide you do need jQuery? :)

To be honest, I do the same thing. It starts off as a small project one-off,
and I think nah I don't have to include jQuery for something small if I just
code these tiny DOM helper functions.

And there hasn't been a single time, when after an hour or so of coding, I
didn't wish I had started out using jQuery right away :)

But sometimes then it's already too far, easier to just kludge along and
finish the task than include jQuery and rewrite all the code so far to use it.

So how's this preferable again?

------
rgbrgb
Similar interface <http://thrivingkings.com/apprise/>

~~~
BillSaysThis
+1 for Apprise

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

~~~
georgefox
How would you make it return true/false immediately when the user has to click
OK or Cancel?

~~~
wulczer
Oh, good point. I clearly need more caffeine in my system.

------
libria
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
It's the "panic" action, akin to a "close dialog" button. Clicking outside
(should) default to the "safe" choice, in this case, "no".

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

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

------
chime
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> about
Apprise. It does what smoke.js does and then some. Thanks

------
consultutah
Doesn't work on ipad

~~~
workhorse
Doesn't work on the iPhone either.

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

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

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

------
dav-id
It seems to be broken on an iPad.

------
chopsueyar
I like the CSS stylings.

------
jsavimbi
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
Noticed that it didn't work on my iPad as well. May be an early release, but
mobile compatibility is crucial.

