In a little experiment I’m working on I recently found a bit of a show-stopping problem. After an APB on Twitter I got a rapid reply which helped me solve it, but it seems that I may be the first person to encounter this error, therefore it’s encumbent on me to document it. So this is that.
For some time now, since Safari 6 and Chrome 18 were released, we’ve been able to use the -webkit-filter CSS property to apply graphical filters to HTML content. But it seems that many people aren’t aware that you can also do this in Firefox and — within a very limited set of parameters — IE9 and above.
The reason for this is that all of these browsers support SVG filter effects, and CSS filter effects are basically shorthand functions that apply predefined configurations of SVG filters.
As you probably know, icon (or, symbol) fonts are a great way to implement scalable, styleable icons which work across pretty much every browser (every one that supports web fonts, anyway). There are many top quality icon fonts available, such as Pictos and Font Awesome, but sometimes you’ll want to create your own bespoke icons. Github wrote detailed instructions of how they made their icon set, Octicons, in their post The Making of Octicons, but that relies on using some professional tools. In this article I’m going to show simple alternative method that uses the brilliant free tool, IcoMoon. Read the full article
Using SVG for scalable icon sprites isn’t a new idea, but the technique required to use them is (as with all CSS spriting) a little verbose, needing multiple instances of background-position. A feature from SVG1.1, Fragment Identifier Linking, makes it much easier, and will be available in the forthcoming Firefox 15.
With the release of IE9 and Firefox 4 all major browsers are going to support using SVG in the img element or as a CSS background image, which is great news as SVG images are good for high definition, scalable websites. I’ve written a couple of posts recently about using SVG with the background-image property, and how to cope with browsers that don’t support it. The method I came up with works, but is far from elegant; for one thing, it doesn’t allow for transparency.
Another approach we can take to the problem is to use JavaScript to detect SVG support. Alexis Deveria wrote a script which detects if your browser supports SVG and, if not, replace the images with PNG. It’s a good script, but I wondered if there was an alternative.
My last post was about using SVG values for the background-image property, and I pointed out one big problem with the technique:
The drawback of this is that it’s not ready for use just yet — browsers that don’t support SVG in
background-imagewill not provide any fallback, even if you supply anotherbackground-imagevalue; so in non-supporting browsers, no image at all will be displayed.
This was annoying me a little, and I couldn’t find any workarounds that didn’t use JavaScript. However, after a bit of head-scratching I’ve come up with a way to get around it.