I like it. Would it be very complicated to add left/right arrow key support?
Show HN: Veneer, modal dialogs in 75 lines of JavaScript
21–29 of 29 posts
Re: Show HN: Veneer, modal dialogs in 75 lines of JavaScript
#22We've worked with ColorBox ( http://jacklmoore.com/colorbox/ ) for the past couple years and it does the job well, just have to clean up the IE6 cruft. 3rd example would be just $('.stuff').colorbox({ rel: 'stuff' }) When you're creating one of these everyday you really don't want to setup the events and logic everytime.
Great, now how many more lines to move the arrows from the top of the image (as in http://jacklmoore.com/colorbox/example2/ ) to the sides of the window as in my example?
They're positioned via CSS, so probably 2 or 3 line changes.
Re: Show HN: Veneer, modal dialogs in 75 lines of JavaScript
#23It's great that you've written a modal dialog library but what differentiates it from the other popular options out there? A 75 line modal dialog library (+mootools) isn't a huge achievement by itself -- I usually write my own dialog modals until I need a feature or compatibility that is more easily attainable using one of the more well-written options out there.
Every modal dialog plugin I’ve seen takes the following approach: try to anticipate the ways people will use it and provide configuration options accordingly. The problem is that as soon as you require anything the developer didn’t anticipate, the plugin becomes useless (or you start messing with the source). If you’ve read Spolsky’s essay, you’ll recognize this as a leaky abstraction. Veneer tries to minimize leakin…
I'm not following how or why this is a leaky abstraction. My understanding of leaky abstraction is an interface or API that fails to mask the implementation details of it's functionality.
A library that does more than you want, without addressing your specific (and probably custom) application needs seems inevitable. I don't think that's a bad thing and I don't see how this library is any more insulated from that problem.
Re: Show HN: Veneer, modal dialogs in 75 lines of JavaScript
#24As a user, I find modal dialogs very annoying, independently of whether they appear in the browser or in any other GUI application. Nice JS and all, but please think twice (or better thrice) before using a modal dialog.
There are usability concerns that you should consider, but that doesn’t mean there are no appropriate use cases. Anyway, you don’t have a choice when it’s a feature a client asks for.
I'm curious, can you name an appropriate use case for a modal dialog? The first few uses cases I know of that came to my mind didn't turn out to be so great after I thought a bit about them.
Re: Show HN: Veneer, modal dialogs in 75 lines of JavaScript
#25Your landing page should say that this requires Mootools.
Re: Show HN: Veneer, modal dialogs in 75 lines of JavaScript
#26Earlier quoted context omitted.
Every modal dialog plugin I’ve seen takes the following approach: try to anticipate the ways people will use it and provide configuration options accordingly. The problem is that as soon as you require anything the developer didn’t anticipate, the plugin becomes useless (or you start messing with the source). If you’ve read Spolsky’s essay, you’ll recognize this as a leaky abstraction. Veneer tries to minimize leakin…
I'm not following how or why this is a leaky abstraction. My understanding of leaky abstraction is an interface or API that fails to mask the implementation details of it's functionality. A library that does more than you want, without addressing your specific (and probably custom) application needs seems inevitable. I don't think that's a bad thing and I don't see how this library is any more insulated from that pro…
I’m referring to leakage in the other direction. Think of a lightbox library as a layer over JavaScript’s API. When working with a library you can either use the configuration options provided or just go back down a layer. The space spanned by the configuration options is inevitably smaller than the full space of possibilities you have when working at the JavaScript level, so it’s likely that you have to go back down to JavaScript anyway. That’s why I prefer working with libraries with less friction between the layers over those that try to anticipate a use case but are useless as soon as you need something different. As phzbOx mentioned the Django authentication system is another example.
Re: Show HN: Veneer, modal dialogs in 75 lines of JavaScript
#27Earlier quoted context omitted.
Great, now how many more lines to move the arrows from the top of the image (as in http://jacklmoore.com/colorbox/example2/ ) to the sides of the window as in my example?
They're positioned via CSS, so probably 2 or 3 line changes.
We’re still quite far from my example. The next and previous buttons are images instead of text, and I don’t want the close button or the caption above the image. If you still don’t get my point, you can try actually reproducing my example.
Re: Show HN: Veneer, modal dialogs in 75 lines of JavaScript
#28Earlier quoted context omitted.
There are usability concerns that you should consider, but that doesn’t mean there are no appropriate use cases. Anyway, you don’t have a choice when it’s a feature a client asks for.
I'm curious, can you name an appropriate use case for a modal dialog? The first few uses cases I know of that came to my mind didn't turn out to be so great after I thought a bit about them.
I think there’s a usability concern only when the dialog presented is in some way dependent on the main page, e.g. if it provides some information that requires the original context. If you’re just showing zoomed-in photographs from a gallery, for example, I don’t see a problem.
Re: Show HN: Veneer, modal dialogs in 75 lines of JavaScript
#29I wish more "library" would be written that way. I.e. make the 80% use case as simple and clear as possible, and let the programmer change it if needed.. instead of providing hundreds of useless configuration (knowing exactly that you'll encounter a case where you'll have to hack your way in the code anyway because it wasn't part of the "configuration"). I'm not bitching in any way on the existing jQuery plugins. I u…
I completely agree. I think this problem is rather pervasive in Django (it goes far beyond just the authentication system).