Smoke.js - A framework-agnostic styled alert/confirm system for javascript
11–20 of 28 posts
Re: Smoke.js - A framework-agnostic styled alert/confirm system for javascript
#12I 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.
Re: Smoke.js - A framework-agnostic styled alert/confirm system for javascript
#13On 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.
Re: Smoke.js - A framework-agnostic styled alert/confirm system for javascript
#14I 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 event…
Re: Smoke.js - A framework-agnostic styled alert/confirm system for javascript
#15Re: Smoke.js - A framework-agnostic styled alert/confirm system for javascript
#16Re: Smoke.js - A framework-agnostic styled alert/confirm system for javascript
#17Earlier quoted context omitted.
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 ho…
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-…
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?
Re: Smoke.js - A framework-agnostic styled alert/confirm system for javascript
#18I 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.
Re: Smoke.js - A framework-agnostic styled alert/confirm system for javascript
#19Re: Smoke.js - A framework-agnostic styled alert/confirm system for javascript
#20I 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 event…
What do you mean by 'obtrusive'?