Seven Nation Army

SVG text has some significant limitations compared to HTML content… but it also has some very real advantages in particular use-cases, and can sometimes be the only way to solve certain text layout challenges on web pages.

SVG Text as Layout

doesn’t think of text as does: that is, as a string of glyphs to be wrapped and styled inside a container. Rather, it thinks of text as a graphical element to be laid out much like everything else: text should have at least a y coordinate value and a font-size to place and scale it in the viewBox area:

<svg xmlns="http://www.w3.org/2000/svg"  viewBox="0 0 500 80">
    <text y="60" font-size="55" font-weight="bold" 
    font-family="Avenir, Helvetica, sans-serif">
        SEVEN NATION ARMY
    </text>
</svg>

font-size is assumed to be in pixels, relative to the viewBox, a feature that makes SVG text automatically responsive. Without a specified font-size, SVG text will render unpredictably across browsers, so it should always be included.

Note that y specifies the location of the text baseline (that is, the line on which letters “sit”). If it is unspecified, y is assumed to be 0. A common error of first-time SVG coders is to leave the y value out, leaving the text baseline at the very top of the viewBox, making the letters effectively invisible.

Positioning Rules

Some guidelines for headline SVG text:

  1. The y value of a <text> element should be at least as large as its font-size if it is to be seen.
  2. The last value of the SVG’s viewBox must also be at least equivalent to this value in order for the text to be seen.
  3. The second to last value of the viewbox will change, depending on how much text there is, it’s anchor point (discussed in an upcoming article), the font-size, capitalisation, font-weight and the <text> element’s x value.
  4. As with HTML text, extra spaces in an SVG <text> element do not make any difference to the way it is laid out.

An x value specified for the text moves it horizontally in the viewBox space. Again, this should be written as a presentation attribute of the <text> element, not a CSS property. If x is not specified, it is assumed to be 0.

Aside from x and y, most of the other SVG text presentation attributes map directly to their CSS equivalents, and should be written that way, making our example code:

<svg xmlns="http://www.w3.org/2000/svg"  viewBox="0 0 500 80">
    <defs>
        <style>
            text { 
                font-family: Avenir, Helvetica, sans-serif;
                font-size: 55px;
                font-weight: bold; 
                text-transform: uppercase;
                }
        </style>
    </defs>
    <text y="60">Seven Nation Army</text>
</svg>

One confusing exception to all this is text color. As SVG really thinks of text as a graphic, to it, the color of text is a fill:

text { 
        font-family: Avenir, Helvetica, sans-serif;
        font-size: 55px;
        font-weight: bold; 
        text-transform: uppercase;
        fill: red;
}

If it is not specified, the default fill of <text> elements is black, just like SVG shape elements.

There are a few CSS typography properties that do not yet map to SVG text, such as text-shadow, although work to do so in various browsers is in progress.

No-Wrap

Importantly, SVG lacks any sense of “wrapping” text, at least in the current specification. This means that all text is effectively treated as single line groups. If the text goes beyond the edge of the viewBox, it disappears from view.

SEO Good

On the upside, <text> is searchable; if the SVG is left inline on the page, it can be also be highlighted and copied by the user.

…and much more to come

This is only the very basics of SVG text; in the next article, I’ll look at the potential problems of, and possible solutions to, using embedded webfonts in SVG.