33
Death to Icon Fonts (speakerdeck.com)
8 years ago from Catalin Cimpanu
15 comments
Drew Beck, 8 years ago (edited 8 years ago )
This is important. But SVG is not as simple of a solution as suggested. In order to change the styling of SVG it needs to be inline w/ your HTML, which makes for a pretty convoluted development process, IMHO.
An enterprising coder could create an HTML preprocessor w/ some template tags that could streamline the process.
I'd love that, actually. SVG has great potential but is frustrating to work with. (Unless I'm missing some standard process folks are using?)
Also, I'm curious about the specific extension the author is using to change the fonts and the decisions made on what to override — if you change the font-face of just the body element's rule in the css on GitHub, for instance, all the copy changes (as you'd want) but the icons do not.
I imagine they're doing a blanket font change because there's no telling what level of specificity a designer/dev has used to declare the font for any particular piece of copy. Perhaps the app could have a slider that allows the user to incrementally increase the specificity (and hence, power) of the font override for sites where this is an issue.
A different solution could be a standard by which creators could indicate that an icon font is in use — always declare font-face !important on those, for instance, or a particular class or attribute applied that tells extensions that you're using an icon font.
Some Designer, 8 years ago
That was just what I was going to say. When I tell a dev that I'm going to deliver assets in svg they accept with a huge frown at first. Then we have to change them back to png's to speed up the process. Ofc I'm not sure that I'm tricked but even if it's that every svg means a few another lines of code (or more)
I may also be a fool actually
I may also be a fool actually
Brb changing my email sig
Matt Anderson, 8 years ago Chris Coyier has a fairly convincing argument for most of your concerns: https://www.youtube.com/watch?v=tsGa-gcckwY
Marc Edwards, 8 years ago
In order to change the styling of SVG it needs to be inline w/ your HTML, which makes for a pretty convoluted development process, IMHO.
Depending on what you’re actually after, there can be lots of good solutions. SVGs scale, so you often don't need more images for more sizes. SVGs can be used where images can be used, so they can be used as background images and CSS masks, if you need dynamic colour changing abilities. Plus, they’re tiny in most cases, so having a few different versions for different colours may not be a big deal anyway.
Often they’re so small you can inline base64 into your CSS. :D
I like SVG. It really does depend what you're trying to do though.
Chris Newton, 8 years ago
SVGs scale, so you often don't need more images for more sizes.
Pure vector graphic scaling is a significant limitation when you’re working with icons, though.
At a minimum, for small icons you tend to need hinting to avoid nasty artifacts, for exactly the same reasons that on-screen fonts do. Font formats support this; SVG does not.
More generally, a well-designed set of icons might have more detail at larger sizes and reduce to completely different, simpler designs at smaller sizes where the extra detail won’t help (or actively hinders).
What I’d really like to see is a way of supplying vector graphics for web use that is flexible enough to represent multiple designs but only use the bandwidth for the necessary ones (also relevant to high-dpi vs low-dpi versions and the like), that supports hinting in a similar fashion to screen font formats, and that renders with acceptable speed and quality in browsers (which are almost universally awful at doing anything with SVG today).
Until we have something on that kind of level, for both quality and accessibility reasons, I suspect bitmap graphics selected via media queries or the equivalent will remain the optimal solution for many use cases, and icon fonts will remain the preferred alternative for those willing and able to accept their limitations.
At a minimum, for small icons you tend to need hinting to avoid nasty artifacts, for exactly the same reasons that on-screen fonts do.
If you draw your SVGs at the size they’ll appear, that’s not an issue.
More generally, a well-designed set of icons might have more detail at larger sizes and reduce to completely different, simpler designs at smaller sizes where the extra detail won’t help (or actively hinders).
I have never needed or wanted that requirement.
I’m not saying the need doesn’t exist. Worth noting that you can do that with SVG as well.
(which are almost universally awful at doing anything with SVG today).
Really? I honestly haven’t had any issues.
If you draw your SVGs at the size they’ll appear, that’s not an issue.
If you draw bitmap graphics at the size they’ll appear it’s not an issue either, but isn’t the major advantage of vector graphics in this context supposed to be that you only have to draw them once and they scale?
I have never needed or wanted that requirement.
Genuine question: Do you do a lot of work with icons? It’s not often that I could see using the same style at say 96x96px for a high-dpi display and 32x32px or even 16x16px on a low-dpi display. Like working with optical fonts designed for use with captions or large displayed text, you can use finer, more subtle details with larger pixel counts, but with smaller sizes I find a simpler design without a lot of detail or stylised effects often works better.
Worth noting that you can do that with SVG as well.
Not really, unfortunately. Those techniques are far from portable: having just tested before writing this, only some work with current Chrome, and none with current Firefox. Even if it worked everywhere, the same SVG with all possible variations is used with that sort of media query technique, which would be an issue if we want to use greater numbers of detailed images without wasting bandwidth.
Really?
I’m afraid so. Rendering glitches are widespread, even with the most simple things like putting an arrowhead on a line. There are clearly some rounding issues in how different shapes are positioned/joined in some browsers. Also, the performance of SVG leaves much to be desired in some browsers, most often Chrome and Firefox in my experience. A single image might work fine, but try working with many small images and doing things like animation or hooking up lots of events to make something interactive, and the cracks show all too easily. To give credit where it’s due, the browsers do seem to be getting a little better with time, but we’re a long way short of the ubiquitous, reliable support that something like PNG enjoys across all major browsers today.
If you draw bitmap graphics at the size they’ll appear it’s not an issue either, but isn’t the major advantage of vector graphics in this context supposed to be that you only have to draw them once and they scale?
It’s common for the other resolution targets to be exact multiples. If you draw your SVG at 1×, you don’t have to worry about snapping to the 2× grid.
Do you do a lot of work with icons?
we’re a long way short of the ubiquitous, reliable support that something like PNG enjoys across all major browsers today.
That’s a fair point, but I really haven’t had any issues that mattered. A big part of it is choosing when to use SVG vs a bitmap. I freely admit that icon fonts have their place as well, although I’m not as keen on using them as you are.
Thanks for linking to your site. I think I see why our experiences might differ now.
I do a fair bit of work with user interfaces, mostly web-based lately, so I wouldn’t necessarily assume any convenient ratios between icon sizes — of course there are similarities, but each job has its own requirements. Sometimes I’d go down as small as maybe 20x20 or 16x16 pixels, perhaps for use on diagrams or charts, or maybe as an annotation that needs to fit with body text sizes.
To borrow an example from your post, at such a small size it would be difficult to maintain the clarity you have at the sizes you show there. Directly scaling down to 16x16 would keep the current proportions and the stylised “S” shape would become just an antialiased smudge/dot in the middle. So in this case, it might make sense to use a modified design preserving that distinctive shape as the main part of the icon, probably at the expense of the circular frame and coloured background. I’d also experiment with whether to keep the subtle gaps in the letterform.
I do appreciate that this icon looks like it’s used for branding rather than UI, so the kind of scenario I’m thinking of might not apply in this particular case and adapting the design might have concerns of its own, but please try to imagine similar issues as they might apply to, say, icons indicating that a certain behaviour is active or a certain warning condition exists in a UI, where preserving the meaning and the clarity of the basic symbol is paramount.
I freely admit that icon fonts have their place as well, although I’m not as keen on using them as you are.
Sorry, I’ve apparently given a misleading impression. I don’t much like icon fonts and rarely use them at all, because of the accessibility issues and the monochrome limitation. I think in principle SVG should be a much more appropriate tool for this kind of job, I’m just acknowledging that in practice scaling down to very small sizes has its limitations in SVG because of the lack of hinting and because of performance concerns if you use a lot of SVG images at once in some browsers.
I automatically disagree with destructive opinions. We live in a perfect age to fix things. Infinite communications and shared skills. OFC I mostly assume this on slide visuals since I don't have a text to read.
Instead of DESTROYING a functioning for the majority of the people, why not make it compatible with accessibility features. The icons used in fonts are not used for text. throwing ideas why not browser would let ICON ascii codes override the dyslexia font?
Killing a functioning feature is not a solution. It was never been a solution for humanity as well.
Wouter Ramaker, 8 years ago
In regards to screenreaders; you can simply instruct them to not read the icons, see this filament group blog.
But in regards to the dyslectic users changing out the font; that's an interesting problem. One that is in line with my recent question here: Do you design for accessibility?
Anwar Choukah, 8 years ago
Interesting post! After checking out SerenD's slides I'll not automatically use Icon fonts for single-colour icons any more.
Thanks to Adobe Illustrator I was ready to give up on SVGs altogether (Sara Soueidan's manyposts and talks always made me hold off on that rash decision, luckily).. Sketch, at least, exports SVGs properly, even though I'm much better at AI..
Regarding SVGs versus PNGs - go with what works best..
Icon fonts were brilliant for colour-changing icons - allowing for CSS transitions and what-not. You can do this with inline SVGs, otherwise they work exactly like images.
Recently, I tried going for a full colour svg sprite (English Premier League badges) which weighed in at a whopping 1.3mb. Nothing I did would make it smaller. PNG sprite it is, then – in THIS case...
This web-design malarkey's not as easy as it looks!
Jimmy Hooker, 8 years ago
I currently create sprites that handle retina scaling in css. I use Sprity with gulp to handle it. This workflow makes a ton of sense to my brain and gives me more options in terms of colored icons than a font would.
However, I am curious about SVG sprites. If I have approximately 50 icons, I could reduce my overhead significantly by using SVG, and it gives me more styling options. For some reason it still feels like optimized PNG sprites are just easier to implement in my workflow. Am I totally wrong about this? Should I be using SVG sprites from here on out?
SVGs can typically be used anywhere PNGs can: img tags, CSS backgrounds, and other places. They don't have to be inlined with your HTML (which I agree is a mess).
And SVGs can also be great as sprites, although if you're trying to lower HTTP requests, there's other techniques you can use. As mentioned above, we just inline base64 encoded SVGs into our CSS (they’re in their own SCSS files, so we don’t junk up our other CSS files).
Login to Comment
You'll need to log in before you can leave a comment.
LoginRegister Today
New accounts can leave comments immediately, and gain full permissions after one week.
Register now