Chrome Canary and Beta were hit with a fairly horrible font bug recently. If
you haven't yet noticed the bug, fonts have been unloading and reverting
to a system font after the page has experienced a period of inactivity.
Holy shit, I just assumed it was something borked in my setup (especially since I've been messing with fonts and font paths a lot recently).
Yup, not just canary/beta -- my up-to-date 31.0.1650.63 on OSX has had it for at least a couple of weeks now. It's actually the most obvious browser bug I think I've seen in years, and seems to particularly affect Wikipedia.
Yeah, I have this issue too, though I'm using stable Chrome, I thought that if this is a bug it must be already reported, the funny thing is that I tried to google it and all I got was some articles about web-fonts and icon fonts rendering problems.
Yep, that's one that I've been seeing for a while, but never quite got around to filing a bug report, since it was a bit hard to characterize, and for some reason I got a blank screen when I tried to do a screen recording of it.
Mostly hit Wikipedia, but occasionally saw it in other places too.
The problem is that fonts are icons, in that they are arbitrary collections of curves, shapes, and symbols, which communicate meaning only to the end-user, and are highly dependent on the end-users understanding of what the thing is that they are clicking, will do.
An icon, a font symbol, a glpyh, a ligature - these are all mere lines in the sand. You want to make another file-format with that, kid?
You can use whatever curve, shape and symbol you like, but the unicode U+0079 should essentially represent the letter 'y' (rather than 'umbrella'): that's precisely the point of it.
If I don't get your symbol, I should be able to revert to a font that I do get.
Symbols are random things that mean nothing until someone says it. If you and I agree that U+0079 is 'y', then so be it. But lets use the other namespaces of the index, too .. and in that regard .ttf has much to offer the aspiring user of the format. Problem is, a shallow look at it, of course, renders the conclusion that it is an investment; but if I know for sure my glyphs render the same way for grandma, no matter if she's using it on some grungy screen, somewhere, then I'm okay with letting the heart-beat monitor screen be composed mostly of cache-able sub-functions derived from somewhere_safe.ttf.
On the other hand, using SVG to pre-load values, then modifying the decomposed stack, somewhere appropriate, in order to attain sustainable realtime SVG rendering performance .. seems as if its a matter of principle. Could it be the jury is out until someone says screw it, and bases the entire OS of their new device on SVG, alone, and not much else?
I think the recent xkcd about symbols is very relevant here, interestingly. As more and more folks were having fun with icons, whether fonts or otherwise, to represent things, it is hilarious how many more slight variations of a symbol I had to learn. Only to usually have sites revert back to using the words at some point.
That is, arguing that symbols are random seems silly. The whole point is that there is a large base of agreed upon symbols affixed with meanings already. They can even be combined to form different already agreed upon symbols.
Ok, allow me to rephrase. Fonts shouldn't be used as icons in such a way that the same point gives me a wholly different icon in a different font. A 'y' will look like a 'y' in any reasonable font. Github's settings icon just looks like a broken box in most other fonts () and if it doesn't, then you're still not sure it resembles something that would, in some way, remind you of "settings".
I know and because of this something nice looking in one font becomes something completely useless when not using that font. (like the Github character in my previous post) It's exactly what I dislike about the entire practice. I don't want to have to use a certain font to make sure your site doesn't break.
I like the consistency of having the same fonts that I like and find readable in my browser as I have in every other window on my computer. Browsers give me the chance to aim for that consistency by picking one font for all sites, but then some sites look terrible because they rely on some particular font to show non standardized icons.
You seem to be confusing fonts with letters or characters (graphemes). A font is simply a collection of specific visual representations of graphemes, each of which should be readily understandable by any reader as a representation of a certain grapheme. An icon, on the other hand, has no strict tie to a grapheme (some might happen to be graphemes, but most aren't). Of course, Unicode, in all its vastness and splendor, has chosen to include lots of code points that wouldn't traditionally be considered graphemes, and fonts are expected to contain specific visual representations for those as well. So at the end of the day things are complicated.
As an aside from the post's content, I really dig the use of counter arguments directly within the article. Not sure if this is a thing or not, but I'm going to start using it.
I disable third-party fonts primarily because of the poor choices of "designers" out there, but also in case they become an attack vector. As a result, I need to use a combination of guesswork, tooltips and URLs on the status bar when navigating some of the more fashionable sites.
Are you sure you mean JIT? That page doesn't mention JIT anywhere, and I can't think how a JIT would be very useful in a font engine. Maybe extremely complicated Unicode combining characters?
They have a lot of tables which are (depending on the browser) interpreted by OS functions, so if there was a buffer overflow bug in the OS font code then you could exploit it with a webfont.
Most (all? Not sure about Safari) use the "OpenType Sanitizer" on all webfonts, which parses and validates all of the tables and all of the offsets contained within them. http://code.google.com/p/ots
Is this really any more of a risk than the code that parses and renders the SVG? Or the PNG for that matter (there have been issues with image libraries in the past)?
There is some weight in the argument. It goes like this:
a) font-file, indexed set of glpyhs. A glyph is any set of line primitives that is associated with the symbol. We load the file of 'sub-routines to draw', and index it .. stupidly .. with some font_glyph_array[]. Which we then index, according to keycode-translation-{NSA-insert}-pipeline.
ahem
b) SVG. SVG is 'pure math', in that the glyphs and bitmaps aren't there, but rather the CPU is going to be asked to calculate things. For this reason, 'most SVG rendering libs are crap' is true, because SVG is intended to be turned into whatever is useful for your CPU, before then being re-rendered for the next frame. Of course this takes a lot of time .. but at least it prevents buffer sploits.
Hmm.
What I like about SVG is that for every id="" there is to be found, there could be a unique 'identifier' to the application, at the user level, that abstracts the <g>. So, if I want a 'button', I just wrap everything up in <g id="button">, and off we go. Of course, ymmv, and probably I'm not trawling the DOM per-frame, like you're supposed to, but hey: its a button that can be immediately Cut-/_Pasted by the designer, and I don't have to think about it.
So SVG serves the purpose of every graphics file-format, ever, which is to stop the Designer and the Programmer from actually having to talk to each other.
For many years the practical attack surface of desktop computers has been shaped by doing work in the kernel better left on a different, less-privileged plane (userland.)
Some systems have chosen a different path and draw the line elsewhere.
Weird. Citing Opera mini as a reason to switch from icon fonts to svg, despite the fact that IE8 and back does not render SVG's. I'm willing to bet the latter has a large audience share.
I would add a counter argument to "it feels hacky" because to me, it feels like the perfect solution: icons are symbols that we use to explain things, just like words.
The font format in particular seems perfect for this:
- One single download to get your entire icon set
- Font rendering engines have been around long before web
browsers, so they are relatively mature on all platforms
Then you run into someone like me whose eyes are not as young as they once were, and who doesn't care to be abused with whatever happens to be the stylish designer's font palette du jour, and who therefore uses his browser settings to apply a minimum font size and a set of preferred typefaces which page styles aren't allowed to override, and then everything goes to hell.
Can you argue that it's my fault, not yours, that your page doesn't render well under the requirements I impose on the web content I consume? Sure, you can so argue. But every time you have to make that argument with a user, even if you win the argument in that instance, you're still both limiting your potential user base and risking a perception that you're less concerned with your users' needs than with satisfying your own desires.
I'm going to go out on a limb and suggest that if you're applying font size minimums and enforcing certain typefaces, you're probably fairly use to a web experience that isn't as the web developer / designer intended. I don't know anyone who QA's their designs with different browser font sizes.
I do; it's not very hard to build a layout which looks like what the designer intended for those who don't enforce font sizes or faces, and which also behaves gracefully for those who do (e.g., no text spilling out of its containers, &c.) You might be surprised how little effort that takes, and I think the result is much better for it.
Well, that minimum font size wouldn't apply to SVG icons, so you're still not going to see them very well. So, it may be more effective to zoom the entire page overall rather than just font sizes.
Also, note that you apparently don't assign any culpability to browser vendors for the state of affairs. I encourage you to revisit that, plenty of blame to go around.
Sure. But that's an occasional need, while not enforcing a minimum font size means hitting C-+ a couple of times for pretty much every page I ever load. In any case, the icon-font problem has less to do with the minimum font size than with the enforced typeface selections, which necessarily and completely break icon fonts.
I'm not sure which portion, of the blame in question here, you contend belongs properly with browser vendors. There are lots of things they might do differently, but I don't see how this is one of those.
> I would add a counter argument to "it feels hacky" because to me, it feels like the perfect solution: icons are symbols that we use to explain things, just like words.
Interesting point! But I think where it falls down is that the HTML content used to conjure a given icon is never related to the icon's content. If there was some way of representing words as icons with a font (perhaps using ligatures?), that would be one thing. But as things stand, it's still a hack.
I don't think it's a good point. A font is a collection of specific visual representations of existing and known symbols. That is why you can (barring this use case) change the font of text and lose no meaning. To use the old HTML/CSS mantra: text is semantic; fonts are presentational.
I've been a huge fan of single-.ttf packages for various industrial applications - i.e. all the symbols of the app are simply custom glyph indices. This sort of stopped being 'a thing', somewhere along the line, but in some quarters, .ttf is just as performant a file-format as a .zip-appended-.exe is to others.
Font-rendering is an important science and branch of Human Communication, imho, and a lot of very difficult problems have been forward-solved by fontographers, before us, we must always remember! Those who propose to make new symbols must be compelled not to forget the old!
It always seemed to me that the benefits of icon fonts would be fleeting. Their popularity has been directly correlated with monochromatic icons being "in-style".
Eventually such fonts will inevitably fall out of style. When that happens, will we be left with a useless ecosystem surrounding a fundamentally inflexible core? Or will font rendering engines have evolved to adapt?
Not to be pedantic, but letterforms are fundamentally chain-able icons and those have been around since written language.
More contemporarily, other marks/icons we now would think of as standard are really icons for language control or words themselves. Typographers have been using monochromatic marks and glyphs since the dawn of the printing press.
Typographical symbols work in part because they exist within a specific problem domain whose practitioners are trained to understand them, and also because the constraints of their native domain privilege function (expressing some directive regarding how a given chunk of text should be typeset) over form (the look and feel of the glyphs themselves). Neither of these properties seems likely to be guaranteed for the much more general domain in which web icons exist.
But the types of icons were talking about here (clock, fork and knife, location marker, star, etc.) do not have such a long history in web design as being monochromatic. It's a fairly recent design trend. A fork and knife icon (used to represent restaurants) could just as easily be a detailed, shaded, multi-colored icon.
> When that happens, will we be left with a useless ecosystem surrounding a fundamentally inflexible core
I'm not sure what you're referring to here. Bootstrap's use of font icons? If font icons ever became an issue, they could easily[1] swapped out of such frameworks.
Also note that font icons are also useful in places that can only display text, but allow for changes in fonts. You can see people make use of such icons for things like (e.g.) displaying the weather in xmobar or dzen.
[1] Might be a bunch of work on the back-end, but I don't see how the interface would change all that much. You get the icons now by just applying a class to an element, just the behind-the-scenes CSS would have to change.
It's buttery-smooth for me on IE 10 (not yet on Win 8.1, so I can't check th fps in the dev tools), jerky (< 30 fps) for both PNG and SVG in Chrome (with PNG being actually slower) and very jerky for SVG on Firefox.
Chrome is puzzling and suggests that there are other factors at play that result in poor performance here.
SVG rendering should properly be paired with proper use of the dejeur hardware accelerations of choice, and for that I'm personally finding various fringes of the MOAI community of much interest, as it puts SVG into a fabulous playground.
That's a fairly extreme outlier, though – other than font/icon preview pages, how many sites want to display hundreds of different icons in rapid succession?
In my experience, you can see noticeable performance losses pretty quickly on mobile devices in as few as 9 on-screen icons, especially in cases of animated elements.
Look at it this way, everywhere on your screen you see repetition is an opportunity for a new, simple symbol that can be represented with fundamental glyphs.
Is it just me or is the OP's page font very difficult to read? On my system it seems low contrast and blurry, almost out of focus. I had to abandon reading the post by the 3rd paragraph, ironically because my eyes couldn't handle the font choice.
It's fine. On my screen (Windows 7, latest Chrome) it's a readable serif font with decent contrast. Text is sharp, though I personally don't favor serif fonts for main text.
I always wonder at all these HN comments about impossible to read sites, is it the computer, the software, the display or the thing that sits between the keyboard and the chair?
Win 7 here, Latest FireFox, LCD monitor at 1680x1050. Just looks blurry to me, but by comparison reading HN (or dozens of other sites today) hasn't been an issue.. nice and sharp. Don't think it's a case of PEBKAC... but maybe. :)
It's not just you, it looks horrible here as well. The font "chaparral-pro-display" seems poorly hinted (at least on my firefox) and has hideous geometry (big blobs / spots on letters like 'r' and 'u' for example).
It's a horrible thing indeed, especially when trying to use a print-optimized font. Luckily the canary version uses the fancy Windows font rendering pipeline so it's merely a matter of time.
We ended up applying a text shadow of 0.15px to smooth out the eaten-by-mice effect. It's a bit softer, but a good compromise. Fonts with good hinting seem to work better.
Yes, I was just dealing with this for my job. Windows Chrome renders web fonts very jankily, even the fonts provided by Google Fonts! (Fittingly, the current "solution" involves serving an SVG version of the web font to Chrome, instead of WOFF or whatever.)
I often see font icons that are done poorly. It's not a problem with the concept, but implementation:
* Irrelevant/meaningless characters used without textual label, which is total crap from accessibility perspective.
* Icons littering text copied to clipboard.
* Awful loading performance. Browsers optimize image loading very well: preload scanner, async loading, fetch priority, multithreaded decoding, but custom fonts almost always only start downloading after CSS is fetched, parsed and applied to the document (in order to avoid loading unused fonts), which delays loading by a network roundtrip + CSS processing time and either delays rendering or causes extra reflows.
I hate seeing 99%-loaded websites with hidden text so much that I've completely disabled support for Web Fonts in my mobile browser. That's a huge improvement overall, but makes font icons a collateral damage.
Icon fonts have always been kind of a hack. SVG is the right formats for many reason - the primary reason: it's XML. We just need better browser support.
> We consider a small subset of our icons to be critical to the user's experience but we don’t think that way about our font or the other icons.
Why don't you consider your font to be critical? In my experience, with Safari, if you use a custom font, text won't render at all until the font has loaded.
We consider the system font critical, and we render the page with that because it it will load instantly. The custom font is then loaded after the content and used on the following page.
Note: this setup is only used sparingly on our site as it has been waiting for this piece of work to be completed.
Curious, the first time I read your post, I saw exactly what I described, which is all text was missing for a second, and then appeared in the custom font.
But when I try now, I get the system font for a second, then it switches over to the custom font.
Please, please kill icon fonts. Redefining special font characters for graphics is just asking for all kinds of cross-platform browser compatibility trouble.
You do that inside the SVG. Instead of having a yet another path or a group of paths, you just have that `use` element (which just references some other node).
Basically, it lets you reuse something, but you can transform it and set some styles.
I've never been really fond of icon fonts, but they've appeared to have some pretty compelling advantages not easily obtainable otherwise; I'm glad to see such a well-reasoned article describe a means of replacing them which has most of the same advantages and what looks to be a considerably narrower range of drawbacks.
Just throwing it out there: are paint times effected by the implementation of svg's? I don't remember exactly but I do recall a situation where svg was causing jankiness. Probably not wholly responsible, but I want to know if anyone else ran into this.
