Live data from Hacker News

Web Designers should all be using this idea by now: Font Icons.

somerandomdude.com

61–70 of 78 posts

Re: Web Designers should all be using this idea by now: Font Icons.

#62
post #60

The post acts as if the idea is really new (some article is said to have introduced the idea "one week ago") but I have seen this in practice at least months ago. It’s not a new idea. But there are reasons it hasn’t taken off like crazy. There are still serious disadvantages to (ad least the obvious implementations of) the technique, as powerful as it is when it works right. Others on this page mention drawbacks. Not…

yeah, i'm really not sure what's new here. but then again the article is from May 4, 2010. i can't remember that far back, but i'm not sure if it was a new idea then, either.

Re: Web Designers should all be using this idea by now: Font Icons.

#64
post #13

They missed one obvious disadvantage - it doesn't work where users force their browser to use a specific font. All I see are letters instead of icons. That said, would it not also make more sense to use codepoints within the "Miscellaneous Symbols And Pictographs" range where possible ( http://unicode.org/charts/PDF/U1F300.pdf ), where you'll find things like volume icons, padlocks, pins, etc. These are missing from…

>it doesn't work where users force their browser to use a specific font. All I see are letters instead of icons.

Or where the user configures his browser not to use downloadable fonts, like I do.

Re: Web Designers should all be using this idea by now: Font Icons.

#65
post #59
post #49

I like this idea, for simple icons. Standard Unicode code points for symbols could be used to even allow screen readers to read them! Another alternative for pages with simple icons is to use the Data URI scheme: This compresses very well with HTTP content encoding when the same icon is repeated in multiple places in the page: http://en.wikipedia.org/wiki/Data_URI_scheme

And if your user visits more than one page on your site, you've successfully killed asset caching. More data for your server to send _and_ a slower experience for the user, losses all round

True, there is no caching. But that's still a technique worthy to use when they are very small (hundreds of bytes), or when the images should never be cached (eg. low-resolution real time status graphs). In these cases, they reduce the amount of data on the wire (no extra HTTP requests) and reduce page load time.

Re: Web Designers should all be using this idea by now: Font Icons.

#66
post #13

They missed one obvious disadvantage - it doesn't work where users force their browser to use a specific font. All I see are letters instead of icons. That said, would it not also make more sense to use codepoints within the "Miscellaneous Symbols And Pictographs" range where possible ( http://unicode.org/charts/PDF/U1F300.pdf ), where you'll find things like volume icons, padlocks, pins, etc. These are missing from…

Trying to introduce a design compatible with a user that specifically overrides your design seems like a losing battle, not one that should even be waged.

Here it is my phone which is overriding your design, i can't see the icons

Re: Web Designers should all be using this idea by now: Font Icons.

#67
post #59
post #49

I like this idea, for simple icons. Standard Unicode code points for symbols could be used to even allow screen readers to read them! Another alternative for pages with simple icons is to use the Data URI scheme: This compresses very well with HTTP content encoding when the same icon is repeated in multiple places in the page: http://en.wikipedia.org/wiki/Data_URI_scheme

And if your user visits more than one page on your site, you've successfully killed asset caching. More data for your server to send _and_ a slower experience for the user, losses all round

[deleted]

Re: Web Designers should all be using this idea by now: Font Icons.

#69
I did this half a year ago on neovella.com. It seemed brilliant at first, but ultimately failed for two reasons: A) cross-browser compatibility for @font-face can be a real hassle when you're juggling a few different filetypes and trying to be compatible with everyone; B) filesize of the fonts themselves outweighed their aggregate image-counterparts.
Post reply on HN