31 comments

  • Er. F.Er. F., over 5 years ago

    The bold appearance of text in Firefox used to drive me crazy. It's only a problem in OSX, and there's a solution for it: -moz-osx-font-smoothing: grayscale;

    6 points
    • Hadrien BHadrien B, over 5 years ago (edited over 5 years ago )

      It's because Firefox has it's own font rendering engine, to make it uniform across platforms. On Windows, it looks different - and better - compared to Cleartype, used in Chrome and IE.

      I think it's a bad thing to change font-rendering on a per-site basis. As a user, you can play in about:config with the gfx.font_rendering and layout.css.osx-font-smoothing properties.

      0 points
      • Er. F.Er. F., over 5 years ago (edited over 5 years ago )

        Why do you think that? What about the article's point that icon fonts in FF look 'too bold'? If you could write a rule for all the instances of font icons on a website to make them appear less bold in FF, why would you not?

        Also, why is it bad to change the font rendering in general? What if it improves the appearance of the design? And isn't about:config something that the majority of FF users don't use?

        1 point
  • Elliott ReganElliott Regan, over 5 years ago

    Icon fonts are super easy to implement, especially with a service like Fontello, but it always has felt like a hack...

    3 points
  • Tor Løvskogen BollingmoTor Løvskogen Bollingmo, over 5 years ago

    Any pictures of these icons rendered at small sizes? That's where most icon fonts (and SVG?) fails.

    2 points
    • Dirk HCM van BoxtelDirk HCM van Boxtel, over 5 years ago

      I could be wrong here, hoping some font-guy jumps in and corrects me if so, but;

      Yeah, I thought the good thing about fonts was that they allow for pixel hinting at lower resolutions, making it possible to get consistently crisp icons across all font-sizes. That, in combination with the fact that most icon fonts look pretty shoddy at small sizes, makes you wonder if people bother with the pixel-hinting option at all.

      Are icon-font designers that lazy? Or am I just dead wrong with these assumptions? (the latter being a fair possibility!)

      0 points
    • Marc EdwardsMarc Edwards, over 5 years ago

      Any pictures of these icons rendered at small sizes? That's where most icon fonts (and SVG?) fails.

      For things within SVG’s wheelhouse, SVG can be pixel perfect. We’re using SVG sprite sheets for all header and footer images on our site. It’s been great (provided you don’t care about pre-IE9 support, which we don’t).

      Icon fonts can also be pixel perfect, with some hacking.

      I far prefer SVG though. Vector images and icons is precisely what SVG was intended for. Icon fonts are a pretty ugly hack (yeah, that’s my opinion and not one that’s shared by all!).

      0 points
  • Julian LloydJulian Lloyd, over 5 years ago

    I spent some time working with SVG in lieu of an icon font just this past week—and it was great.

    I ran into a couple oddities with CSS transforms and SVG in some places, but I’m sure with more tinkering I’ll iron the bugs out.

    1 point
    • Dirk HCM van BoxtelDirk HCM van Boxtel, over 5 years ago

      I wish I could share your enthusiasm, and I kind of do, but there's that gnawing browser-support issue in the back of my mind that makes SVG a bit of a "dirty" solution to me.

      Note those last two words, "to me". I'm stuck with several projects that have target audiences that use older browsers, so my opinion is biased as hell.

      Having said that, it's comments like yours that make me want to push forward on SVG icons. They're just so mouth-wateringly useful.

      1 point
      • Julian LloydJulian Lloyd, over 5 years ago

        Icon fonts are still easier to use for me, but I see things like this and like you say, I can’t deny SVG’s appeal.

        I’m sure you‘ve see this, but CSS Tricks goes over Using SVG (and some fallback techniques) that were helpful in getting things off the ground.

        1 point
        • Dirk HCM van BoxtelDirk HCM van Boxtel, over 5 years ago

          Yeahp. I used the color-changing kiwi bird SVG to illustrate a key reason why I wanted to use SVG to my manager. We have some white-label products where styling changes allow us to customize applications to fit specific brands. A sprite that changes color with a single line of CSS would be insanely useful.

          1 point
    • Tj TanTj Tan, over 5 years ago

      Visually I really like the rendering consistancy of SVG compared to icon fonts. But the front-end dev was a big advocate about the file size savings of icon fonts (About 100kb difference). Ultimately we went with icon fonts.

      1 point
      • joe andersonjoe anderson, over 5 years ago

        This doesn't sound right if the SVG is hardcoded with paths and doesn't need to be requested as a file. It's just a set of dom elements. You save a lot of time not making a request to fetch the font file.

        Hope someone else can chime in on this

        0 points
      • Marc EdwardsMarc Edwards, over 5 years ago

        But the front-end dev was a big advocate about the file size savings of icon fonts (About 100kb difference). Ultimately we went with icon fonts.

        Make sure you’re comparing apples with apples.

        Icon fonts are definitely small, but SVGs can be arranged in sprite sheets, can be optimised to remove some of the junk (if saved from Illustrator), and they can be gzipped. By the time you’ve done all that, I doubt there’s going to be much difference to the already tiny files.

        If your dev is citing this article as evidence, take note that there’s no mention of sprite sheets and that the file sizes show are all tiny for 50 icons.

        0 points
  • Aaron SagrayAaron Sagray, over 5 years ago

    So how do you deal with the performance loss from hundreds of http connections to download the SVG files, vs one connection to download a dedicated icon font?

    0 points
    • Ben JenningsBen Jennings, over 5 years ago

      Data URIs.

      3 points
      • Dirk HCM van BoxtelDirk HCM van Boxtel, over 5 years ago

        SVG sprite?

        2 points
        • Marc EdwardsMarc Edwards, over 5 years ago

          Yeah, SVG sprites!

          One issue where it took me a second to work out a good solution: hover states. Being vector, SVG’s are rendered at size, using fractional offsets. But, using background-postion is snapped to the nearest pixel. So if you’re using an SVG sprite sheet for hover state, things can move slightly on state changes, which looks terrible.

          The solution is to use two sprite sheets — one for normal state and one for hover state. This means the size and position maths works out identical for both, and there’s no movement on state change. 2 SVGs for your entire header and footer images is still likely to be tiny from a file size and HTTP request point of view.

          Win!

          1 point
          • Joe HowardJoe Howard, over 5 years ago

            The solution is to use two sprite sheets — one for normal state and one for hover state.

            This kinda defeats the purpose of using an SVG for an icon (in terms of being a dynamic object).

            You can use jQuery to inject the inline SVG data directly into the DOM. This way, you just store all your SVG data in a JavaScript doc, which only gets loaded once and is cachable. Then you can manipulate all the SVG for hover/click states as much as you like with CSS/jQuery.

            0 points
            • Marc EdwardsMarc Edwards, over 5 years ago (edited over 5 years ago )

              This kinda defeats the purpose of using an SVG for an icon (in terms of being a dynamic object).

              It depends what you want to change. If you’re changing scale, opacity or many other properties, you can de them with CSS anyway.

              This way, you just store all your SVG data in a JavaScript doc

              GAH! That doesn’t sound like fun at all.

              which only gets loaded once and is cacheable

              How is that a benefit over SVG sprite sheets? They get cached, too.

              Then you can manipulate all the SVG for hover/click states as much as you like with CSS/jQuery.

              Sure, if the manipulations fit with using CSS or jQuery. Or... you can just stick the variations you need in your SVG, which is likely a tiny file. In fact, depending on what you’re trying to change, your JS/CSS code might be bigger.

              I’m not at all against using CSS/jQuery. I’m just suggesting that often it’s quicker and easier to have the versions you need already in the SVG (assuming you don’t need many variants).

              0 points
              • Joe HowardJoe Howard, over 5 years ago

                Sure, if the manipulations fit with using CSS or jQuery. Or... you can just stick the variations you need in your SVG, which is likely a tiny file. In fact, depending on what you’re trying to change, your JS/CSS code might be bigger.

                All SVG manipulations fit to using CSS, because SVG markup for the web in itself is styled in CSS, regardless of how it's implemented.

                Two SVG sprite sheets contain the exact same CSS styling as if you were to style it externally. The only difference is you're loading the SVG data twice, instead of once.

                The only way it would be smaller, is if you were working on a project that doesn't use any jQuery at all. Which is highly unlikely.

                BTW it's not complicated at all. It's actually really lightweight, plus it gives you full control over styling the SVG.

                var SVGIcon = "<!--SVG Mark-Up Goes Here-->"; $(SVGIcon).appendTo('#MYDIV');

                Even for a hover state, I would advise this over a sprite - it's a lot more future-proof, particularly when you need to make changes, as the styling isn't hardcoded into the SVG markup.

                Here's some simple examples you should look at (that i made using the same technique): http://www.pencilscoop.com/2013/12/150-free-animated-svg-icons/

                0 points
                • Marc EdwardsMarc Edwards, over 5 years ago (edited over 5 years ago )

                  Fair points.

                  Two SVG sprite sheets contain the exact same CSS styling as if you were to style it externally. The only difference is you're loading the SVG data twice, instead of once.

                  What if the actual vector data changes? The normal state might be a person sitting, and the hover state might be the same person standing.

                  Here’s a real world example from our site:

                  Bjango logo

                  It’d be a lot more effort to use CSS to alter one version to become the other than just having two copies. And all for what? A couple of K, if you’re lucky?

                  I‘ve just saved some tests as single SVG files:

                  • 4,918 bytes — both logo versions
                  • 3,286 bytes — a single logo version

                  Could you write the code to make all those changes using jQuery, in less than 1,632 bytes? If you did, how long would it take and what would be the reward?

                  The only way it would be smaller, is if you were working on a project that doesn't use any jQuery at all. Which is highly unlikely.

                  I’ve never built a site using jQuery.

                  1 point
                  • Joe HowardJoe Howard, over 5 years ago

                    What if the actual vector data changes? The normal state might be a person sitting, and the hover state might be the same person standing.

                    It depends on what kind of vector changes you need, and how you want it to change. The main advantage with separating the styles is that you can have fluid changes and animations (without using jQuery), rather than on/off toggle changes.

                    For your example, the SVG data isn't really changing either, your just displaying the house and changing the colors. The advantage of doing it externally would be that the changes within the actual logo could be more fluid.

                    But like I said, it depends on what you want to achieve.

                    Could you write the code to make all those changes using jQuery, in less than 1,632 bytes? If you did, how long would it take and what would be the reward?

                    You don't make any changes using jQuery. It's all CSS.

                    You don't make the changes with jQuery. jQuery's only used to load the SVG data to reduce HTTP requests (for a big site with many icons) while maintaining SVG dynamic state-changes.

                    Even if you don't use jQuery, you can still put the SVG markup inline into your page and style it externally.

                    That being said for your example, since the there isn't really any animation of the logo itself, using a sprite to toggle is easier.

                    0 points
                    • Marc EdwardsMarc Edwards, over 5 years ago

                      The main advantage with separating the styles is that you can have fluid changes and animations (without using jQuery), rather than on/off toggle changes.

                      Yeah, that is definitely a plus.

                      Unrelated: I wonder how far DN can nest comments?

                      0 points
                      • Joe HowardJoe Howard, over 5 years ago

                        hehe. Eventually the text will become like one word per line. BTW I really like the the Bjango logo.

                        0 points
    • joe andersonjoe anderson, over 5 years ago

      I thought if you serve SVGs directly with hardcoded html (), its just like displaying something drawn in canvas/dom and css, so no request time. Is this wrong?

      Got this from nettuts "If your image is instead a set of dom nodes, it cuts that extra HTTP request out, making your website faster and more user friendly."

      0 points
      • Marc EdwardsMarc Edwards, over 5 years ago

        Different file always equals a different HTTP request, right? You can (of course) embed the SVG if you’d like, just like any image can be embedded. You may lose some caching benefit in doing so.

        0 points
        • joe andersonjoe anderson, over 5 years ago (edited over 5 years ago )

          I don't think there is an http request with embedded svg's since they just act like dom elements. I will need to try serving foo.svg vs the full embed hardcoded.

          <img src="kiwi.svg"

          vs.

          <svg ... <path ... / /svg

          0 points