I think the desire for this kind of project is very reasonably based, and it looks like you have done great work on most of the implementation. I have one gripe with it, though.
It would be nice if the documentation mentioned that garlic.js requires an HTML5 browser with localStorage implemented. Remember, there are people who are still using Internet Explorer 6 and 7, and these browsers are incompatible . This is a minor details considering browser marketshare, but a fallback using cookies would be a nice-to-have feature.
We're talking about something that prevents form data loss. If it doesn't error on IE6/7 and simply doesn't work, then that's fairly graceful degradation that provides a benefit to users on more modern browsers.
But I suppose if your userbase is predominantly IE6/7, then it may not be worth the effort for you.
At least in the federal government in the DC area, IE6 and 7 are all but dead, basically. While there are still plenty of legacy servers running older versions, desktops are far less behind than they were even 2 years ago.
I'm admittedly only speaking for a dozen agencies or so, but things are definitely better off lately than they used to be.
Sure you can quote stats all day, but it depends on your target audience. If you are running a tech website (such as HN/TC/Reddit/etc) you will see a HUGE portion of visitors using browsers like Chrome/Firefox and hardly any IE.
However if you are building websites that regular people use they still use XP and IE7... so much so that it can account for 10-30% of your website traffic.. It really pains me when HTML frameworks like Foundation 3.x drop support for IE7 and below because there is still the userbase there.
IE7/8 is not dead for most of the world yet. People who run statcounter websites are getting data from people who run their tools. I would trust if someone like Google Analytics released an average browser usage as they are more widely used. Who the F uses statcounter nowadays?
 Though you can do tricks/hacks to make it work for IE7.
"Ew"? Flash is practically ubiquitous, works reliably and predictably in both modern and legacy browsers, and is used as a fallback for HTML5 by tech giants like Google. No need to let your prejudice get in the way.
Hmm, what does jQuery provide that is so essential that someone decides to add a dependency this big for something so simple? It seems that everything requires jQuery these days, even when a 5-line for loop would do.
Ii your website uses the Google CDN to download jQuery new visitors will often not even download jQuery when arriving at your website because their browser probably has it already cached from visiting one of the dozens of other websites they have visited.
Ideally this would be solved in a similar way as when you statically link to libraries in C - the parts of your dependency are pulled in and users don't have to worry about it. (There are other issues with this of course, but they are well understood by now that someone could develop a system to mitigate that by now)
The code is pretty much idiomatic jQuery js following most of their style rules, layout rules and standard constructs so it's obviously been written as a jQuery extension. He must know jQuery well, hence why not use it?
As for why, well I spotted a bit of sizzle, jQuery.data and the event framework in one pass of a small code base. Given the nature of the library I can even guess what they're all for without reading the code.
Quite a lot more than the inevitable each that is also in there.
I disagree to a certain extent. I don't believe in catering to the possible 5%  market share that will not upgrade their browsers. Anything that strongly suggests people to upgrade is better, imo. I don't care for the entire notion of including everybody when it calls for more code bloat and makes the code more difficult to maintain or upgrade.
> I don't believe in catering to the possible 5%  market share that will not upgrade their browsers
Please remember there are large numbers of users who cannot upgrade the browser they use at work, and there are valid reasons why their IT departments do not let them upgrade.
If your webapp is for entertainment, social, or otherwise not useful for corporate, government, etc. users then you're probably right. But otherwise you may be punishing users who have no choice in the matter, hate IE6 as much as you do, and use Chrome at home.
I agree about code bloat, etc., and if there's a clean way to maintain a separate branch or plugin to support IE6/7 users that's great, but if a library doesn't support them, I simply can't use it given my userbase.