Smoke.js - A framework-agnostic styled alert/confirm system for javascript
ssssnakes.com
ssssnakes.com
But, I thought this was dead:
onClick="javascript:smoke.alert('this is a normal alert');"
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.
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.
var listen = function(el, evt, cbk) {
if (el.addEventListener) {
el.addEventListener(evt, cbk, false);
} else {
el.attachEvent('on' + evt, cbk);
}
};
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.
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?
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.
Edit: rgbrgb posted http://news.ycombinator.com/item?id=2748038 about Apprise. It does what smoke.js does and then some. Thanks
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.
Don't interrupt CRUD. If you can't trust the user to not perform an irreversible action, then you're doing it wrong.