Grow your CSS skills. Land your dream job.

Issue with Icon Fonts in Chrome 23

  • # January 8, 2013 at 11:06 am

    Hey everyone,

    I was actually pleased to see that there is another corresponding thread dealing with an Icon Font issue in Chrome 23. I decided to start my own because, uh, well I just didn’t want to but in and I just want the visibility (sorry, frustration levels are high).

    I work at an academic library and we are now public testing a small room reservation system we built where–except for the logo–we swapped all icons (keys and locks and users and menus, etc.) with icon fonts (Icomoon, specifically).

    I thought I might be having a local issue, but my coworkers are experiencing the same thing in Chrome only. Basically, the icon fonts are a.) mostly not displaying and b.) mucking up the display when they do appear. This might be shoddy code, I’m cool with that – but it’s pervasive, because I use the same font-face and icon fonts on several concurrent redesigns. None of them show in Chrome.

    The upshot is that all the icons display properly in IE8/9 / Firefox / Safari / Opera.

    A couple hours googling have illustrated that, by far, I am not the only one with this issue. There have been a dead ends, but hopefully the community here can help me figure it out.

    For reference, the dead ends include something about MIME Type, resetting character encoding in Chrome settings, clearing your cache (well, duh), using absolute URL’s in @font-face declaration, and so on.

    Randomly, sometimes, everything appears correctly in Chrome. Lol, I’m going nuts. Check it out in something like Firefox / Safari before hitting it with Chrome to see what I mean.

    Note: I’m using SASS, and the .css file on both sites is compressed. Here is my font-face code and once class example of how I’m using it.

    /* ==================
    * Icon Font
    * ================== */
    @font-face {
    font-family: ‘icomoon’;
    src:url(‘fonts/icomoon.eot’);
    src:url(‘fonts/icomoon.eot?#iefix’) format(‘embedded-opentype’),
    url(‘fonts/icomoon.svg#icomoon’) format(‘svg’),
    url(‘fonts/icomoon.woff’) format(‘woff’),
    url(‘fonts/icomoon.ttf’) format(‘truetype’);
    font-weight: normal;
    font-style: normal;
    }

    [class^="icon-"]:before, [class*=" icon-"]:before {
    font-family: ‘icomoon’;
    font-style: normal;
    speak: none;
    -webkit-font-smoothing: antialiased;
    }

    .icon-help:before { content: “47″;}

    Public Server: http://sherman.library.nova.edu/rooms
    Staging: http://systems.library.nova.edu/rooms

    I appreciate the help.

    # January 8, 2013 at 11:07 am

    Woops, let me codify that CSS for you.


    /* ==================
    * Icon Font
    * ================== */
    @font-face {
    font-family: 'icomoon';
    src:url('fonts/icomoon.eot');
    src:url('fonts/icomoon.eot?#iefix') format('embedded-opentype'),
    url('fonts/icomoon.svg#icomoon') format('svg'),
    url('fonts/icomoon.woff') format('woff'),
    url('fonts/icomoon.ttf') format('truetype');
    font-weight: normal;
    font-style: normal;
    }

    [class^="icon-"]:before, [class*=" icon-"]:before {
    font-family: 'icomoon';
    font-style: normal;
    speak: none;
    -webkit-font-smoothing: antialiased;
    }


    .icon-help:before { content: "47";}
    # January 8, 2013 at 11:19 am

    I have a feeling `[class^="icon-"]` and `[class*=" icon-"]` might be the cause of this. I could be wrong.

    # January 8, 2013 at 11:20 am

    I was off-tab for a few moments doing something else, and when I went back, Chrome had displayed the icons correctly:

    http://www.dropbox.com/s/3fh95vaygrk81uy/chome-worked-then-didnt.jpg

    But then it refreshed and failed:

    http://www.dropbox.com/s/a7t2blto8529ln4/chrome-fail.jpg

    # January 8, 2013 at 11:34 am

    I wonder if @chriscoyier or @paulirish can confirm if this is a bug. There’s actually an article on here by Chris that shows how he did it.

    http://css-tricks.com/html-for-icon-font-usage/

    # January 8, 2013 at 11:40 am

    Thanks, @chrisburton, for the wicked-fast replies! I’m too quick to test and respond. I changed-up the src URI with an absolute path and the browser tricked me by displaying the icons appropriately.

    After a few subsequent refreshes, the icons were lost / or funkified the display.

    At other times I’ve used a different icon font, Chris’s was the approach I used. But just like hitting-up fontsquirrel or whatever, I just plugged in the Icomoon CSS that came with the DL. If that’s a poor CSS, I’m cool with changing it, but with a font as popular as Icomoon I’m surprised it hasn’t come up or been fixed yet.

    # January 8, 2013 at 11:54 am

    @MichaelSchofield Just for the hell of it, try adding `content:””;` here

    [class^="icon-"]:before, [class*=" icon-"]:before {
    content:””;
    font-family: ‘icomoon’;
    font-style: normal;
    speak: none;
    -webkit-font-smoothing: antialiased;
    }

    Edit: Nevermind. That won’t do anything.

    # January 14, 2013 at 9:42 am

    If I’m guessing right, you’re experiencing this bug on Windows. Some of my other users had this issue. But there’s an easy workaround for it: Use the PUA encoding. You can reset the encoding of your font to PUA in the font tab of the IcoMoon app. Another solution would be to reorder the font formats in your @font-face so that WOFF is placed before TTF and SVG.

    SVG fonts render better in the browsers that support them. Therefore I put them first by default.

    # January 18, 2013 at 8:35 pm

    @Keyamoon – I think you hit this right on the head. I made the quick swap secretly and my complaints from my colleagues have suddenly dropped off. The best part is that, wow, that fix is just so logical / easy.

    # April 3, 2014 at 12:29 pm

    @Keyamoon, @MichaelSchofield, thanks for the discussion. I had the same issue, moved the WOFF above TTF and SVG and voilà.

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.

*May or may not contain any actual "CSS" or "Tricks".