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 [1]. This is a minor details considering browser marketshare, but a fallback using cookies would be a nice-to-have feature.
That depends on your user base. If it's just the wider internet that's accurate, but if you're aiming at government or big corporate clients, you'd better check your analytics first.
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.
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.
One of the sites I built recently has a ton of backbone.js dynamic loading.
I tried to test it in IE 6, and the browser just immediately crashes. Not like an alert box, just an instant shut down!
In the past I would have started the unpleasant task of figuring that out and fixing it up, or perhaps detecting and redirecting to a more lightweight page.
This time I said screw it - I'm done with IE 6! Call me irresponsible or lazy or whatever you want but I'm just done with IE 6 and it feels great!
By the way YouTube shows a giant warning on their page if you view it with IE 6, saying that it won't be supported in 6 months.
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[1] 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?
[1] Though you can do tricks/hacks to make it work for IE7.
Adding many lines of code to a library to support two browsers that have 1.5% of worldwide share and should die because we would all be better off if they did is not the right solution.
Those who still have a need to support those browsers should code up and release an additional library that adds support to garlic.js so it can be used only by those that need it.
In fact, it'd be great if every library added cross browser support for old browsers as add-ons to libraries instead of making them a core part of the library.
Oh of course IE8 isn't going anywhere, but there is no reason at all for people to be on 7. Can you explain why someone on XP would move off 6 but not go all the way?
It depends on your market. In China, IE6 is still at 20-25% and it's even more if you count all of the smaller browsers that simply wrapped IE6 Trident into their own browser interface.
I get the sentiment here but considering this is an enhancement to the user experience that IE6/7 users will never know they missed out on either way...
You don't need to backport everything, only the critical stuff.
"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.
No more ew than people being on IE.
In my opinion, flash is a viable alternative where modern technologies aren't able to be used, especially if it's a trivial enhancement.
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.
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.
> It seems that everything requires jQuery these days
And there's your answer: The "cost" of depending on jQuery is small since so many things depend on it that most potential users probably already pull it in.
JavaScript is an extremely bare language that largely lacks a standard library. Libraries like jQuery make code easier to write and easier to maintain and sometimes even result in smaller downloads for the user.
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.
It seems to use it for events, selectors, and data attributes.
Some uses are unnecessary, eg. using `closest` to get the container form element. `element.form` can be used on any form input or control to access the form itself.
I dunno though. I don't like adding jQuery as a dependency but there are still some cases where it's just pragmatic, especially with handling events.
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 problem is more about the download size than the actual deployment (unless you mean using only the parts of jQuery you need, in which case I guess it would be hard to share between apps).
Why not? This is a plug-in aimed to help in the event something happened with the browser window. Besides accidently closing it there aren't many other scenarios where this plug-in would be useful.
I disagree to a certain extent. I don't believe in catering to the possible 5% [1] 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% [1] 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.
This library solves a problem and solves it well. The local storage issue should be left up to other libraries who are designed to solve that gripe. :-)
I figure those folks using IE 6 or 7 are used to a lackluster internet experience. Little perks like this are not critical features and can be foregone for this small userbase.
Not a link, but without any plugins of that type installed, this is the behavior I've had for a long time now. (I use Chrome for everything until I need to test apps in FF).
Oh, I was totally unaware of this one. Never mind, it clearly shows that there's a lack here on this browser behavior. My project is juste a few hours pet project. I'll try to maintain it and make it as advanced & usefull as sisyphus, for fun :)
Is there a way to differentiate between data that's only saved using Garlic (local) vs data that's also been saved to the server? This could be a huge confusion for users if there isn't.
I agree with this. Outside of explicitly signaling to users that they have a saved 'draft' of the form, and having them click a button on the page to restore their filled out fields from the draft, there aren't really very many sane implementations.
Some other issues:
- doesn't work in IE
- saved data doesn't expire
- Storage keys aren't unique to the URL, so if two pages have the same exact layout, but different content, identical forms on the page will be filled out with stored information.
So it's a good concept, but I think that there are definitely some questions about user privacy, and that it needs to be paired with some extra UI cues that make it clear to the user that they're looking at draft information, and not something that's saved.
I wonder if you should have some sort of icon or text indicator (per field) that shows there is saved form data available, but don't populate until the user triggers it, or an option to restore all available form data in one click? There are situations where I want to clear a form so I'll refresh the page if a clear option isn't available. I guess the solution would be for everyone that uses garlic.js to make sure they have a clear option.
There are all sorts of use cases that might want one thing over the next (display server data vs local data for example).
Keep you API open and flexible for the UX designer to choose what's best when. Also, if it's showing local data do something simple, like give the field a class of "garlic-data". That way the UX designer can choose the best way to differentiate it for their use case.
It's still a work in progress, but of course! I have many (many!) bookmarked pages with more libraries in my instapaper feed, some emails to myself and a few emacs .org files I use as buckets. I just decided to start collecting them last week and made a quick sweep-clean with the most recent tabs I had open and the few I had linked to recently:
I'll probably end up posting the list (or the mind map that forms it) on my blog sooner or later (probably as soon as I hit 30 or when I finish my current Javascript RTE project)
Should add an option for users to disable this (like remember me on login forms)... not good for public computers if you don't know the form you just filled in but didn't submit will retain the data. Other than that, cool!
Persisting localStorage seems to be controlled by the setting to delete cookies after exiting the browser. If i have it set to delete cookies, it deletes localStorage. if i allow it to keep cookies after quitting the browser, then it persists localStorage.
(Noticed this because the demo failed for me the first time.)
Are you sure of that? I've tested the behavior of cookies / localStorage on iPads recently, and on private sessions without cookies, Safari on iPad had localStorage persisted.
I had this same thought, but I think it would just be best to use these sort of plugins wisely, and not on every form element possible. Or to maybe have some sort of form "note/tip" that mentions it's being auto saved. Sites like Quora do this via drafts of your comments/responses that you write. That way people know to erase the content if they truly don't want it saved.
Like many UX features similar to this, I would say it mainly comes down to who your audience is, and where it's being used on how "weirded out" users would feel by this feature.
Pretty cool - another very similar option that comes in the form of a jQuery plugin that I just noticed in the [new] section of HN.... https://github.com/simsalabim/sisyphus - It looks pretty slick.
As a side note do not use the Bootstrap class .well together with .row cause it overflow because of padding. Create this structure: div.row > div.well > the content.
I think anothermachine meant it should be default behavior in browsers. I agree, with the attribute to disable or enable this from the html it would be a nice feature for browsers to implement.
It's not standard because people frequently do things like type a credit card number into a form on a public computer. Lots of potential for privacy breaches.
With and option to disable this behavior from the HTML websites could chose to disable it on forms which might contain sensitive data. Browsers could even disable it by default and let the websites enable using an attribute.
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 [1]. This is a minor details considering browser marketshare, but a fallback using cookies would be a nice-to-have feature.
Besides that, awesome work!
[1] http://www.quirksmode.org/dom/html5.html#t00