By Anthony Martinez
Check out what else the script offers for those who need more power and/or control over the output!
(Added in 0.9.0; modified in 1.2.0) Mark the "Generate CSS for IE9 (Data URI Output)" checkbox before clicking "Convert", and then along with the standard SVG output, you'll see another text box with data URI output. This takes the text of the SVG file and embeds it, so you can then plug it into your CSS file without the need for adding extra HTTP requests for images.
Note that this feature is currently IE-specific. When you use rgba, hsla, or transparent colors, this feature retains those original colors in order to reduce output file size, instead of the default of converting them to hex colors with added stop-opacity. IE9+ (as well as Firefox 4+ and Opera 10 to 12.1) will render the original input correctly, but not Chrome, Safari, Opera 15+, or other WebKit-based browsers, which (in agreement with the current SVG spec) ignore alpha values in colors. Later releases will likely address this, as SVG can serve as a viable fallback for more than IE9; it can be useful in all major browsers as an alternative to listing -webkit-linear-gradient, et al, at least until browser versions lacking support for unprefixed linear-gradient become extinct.
Previously, I offered the alternative of simply copying the SVG output to an online converter such as decodebase64.com to get cross-browser base64 output, but now that doesn't work, as the script no longer offers SVG in base64 output. Instead, as of Version 1.2.0, it offers output in partially encoded ASCII via encodeURI and further replace() calls to convert %20 back to spaces (they don't need to be encoded), and # to %23 (otherwise, browsers think you're denoting an ID or anchor, I suppose). The resulting output tends to be 15-20% smaller than the same output in base64, plus, it compresses better. Gzipped ASCII in this format tends to be around 30% smaller than gzipped base64, almost eliminating the file-size increase inherent to base64 usage. Let me not forget to mention that the output is now quasi-legible! That's much better than the total gibberish base64 produces. However, no online text converter (much less any gradient generator) I'm aware of duplicates my encoding method. So, until I update the script again, cross-browser data-URI output by default will have to be a manual endeavor.
One last little issue to point out: the new output format is difficult if not impossible to use in inline CSS. 999 times out of 1000, manually typed inline CSS is a poor practice, anyway... CSS is much better suited for external usage (promotes browser caching), or usage in internal stylesheets (the <style> block in the <head>) on single pages.
(Added in 0.9.5) Mark both the "Generate CSS for IE9 (Data URI Output)" and "Batch Mode" checkboxes, and you'll enable a special mode that lets you convert a whole bunch of gradients at once! Mark these checkboxes before adding any text input, and you'll see an example of how to use Batch Mode, show up in the input text box. Just paste your CSS selectors (containing only gradients and optional background-size) in the input, click "Convert", and you'll see data URI output for each selector appear in the output below. There is no preview or code updating enabled while Batch Mode is active, however.
(Added in 1.0.0; modified in 1.2.0) If you use background-size in your CSS for custom sizing of your gradients, then include background-size in the script input to alter the script's behavior. The behavior change will only be apparent with input of multiple gradients; the script will make an SVG file for each individual gradient (instead of the default of one layered file for all gradients), then output a cross-browser data URI (or IE9-specific if you have the relevant checkbox marked). That way, your CSS background-size will work as expected.
Why automatic data URI output, however? Because, adding HTTP requests in the form of a bunch of external SVG files reduces performance for your website visitors and therefore is not recommended.