SVG Guidelines — Firefox Source Docs documentation (original) (raw)

Authoring guidelines

A lot of SVG files (particularly those generated by SVG editors) ship without being cleaned up and can contain a ton of junk that bloats the file size and slows down rendering. In general the best way to combat this is to first run SVG files through a linter such assvgo (see the Tools section below). However, when authoring SVGs by hand here are some best practices to help keep them lightweight. These rules are based on some real examples seen in Mozilla’s code.

Basics

Whitespace and line breaks

Whitespace

In addition to trailing whitespace at the end of lines, there are a few more cases more specific to SVGs:

Whitespace examples

This path:

can be cut down to this:

Similarly, this polygon:

can be cut down to this:

Line breaks

You should only use line breaks for logical separation or if they help make the file readable. You should avoid line breaks between every single element or within attribute values. It’s recommended to put the attributes on the same line as their tag names, if possible. You should also put the shortest attributes first, so they are easier to spot.

Unused tags and attributes

Editor metadata

Vector editors (Inkscape, Adobe Illustrator, Sketch) usually add a bunch of metadata in SVG files while saving them. Metadata can mean many things, including:

Other metadata

In addition to non-standard editor metadata, standard compliant metadata also exists. Typical examples of this are <title> and <desc>tags. Although this kind of data is supported by the browser, it can only be displayed when the SVG is opened in a new tab. Plus, in most of the cases, the filename is quite descriptive So it’s recommended to remove that kind of metadata since it doesn’t bring much value.

You shouldn’t include DOCTYPEs in your SVGs either; they are a source of many issues, and the SVG WG recommends not to include them. See SVG Authoring guidelines.

Avoid the use of CDATA sections

CDATA sectionsare used to avoid parsing some text as HTML. Most of time, CDATA isn’t needed, for example, the content in <style> tags doesn’t need to be wrapped in a CDATA section as the content inside the tag is already correctly parsed as CSS.

Invisible shapes

There are two kinds of invisible shapes: The off-screen ones and the uncolored ones.

The offscreen shapes are hard to spot, even with an automated tool, and are usually context aware. Those kinds of shapes are visible but off theSVG view box. Here’s an exampleof a file with offscreen shapes.

On the other hand, the uncolored ones are easier to spot, since they usually come with styles making them invisible. They must meet two conditions: they must be devoid of any fill (or a transparent one) or stroke.

Unused attributes on root <svg> element

The root <svg> element can also host many useless attributes. Here’s anexampletaking into account the list below:

Other

Styling

Styling basics

Styling examples

Here are some examples for excessive number precision:

As for descriptive IDs:

Use of class names

Default style values

There’s usually no need to set the default style value unless you’re overriding a style. Here are some commonly seen examples:

SVG grouping

Style grouping

Group similarly styled shapes under one <g> tag; this avoids having to set the same class/styles on many shapes.

Avoid excessive grouping

Editors can sometimes do excessive grouping while exporting SVGs. This is due to the way editors work.

Nested groups

Avoid multiple-level nesting of groups, these make the SVG less readable.

Nested transforms

Some editors use <g> tags to do nested transforms, which is usually not needed. You can avoid this by doing basic algebra, for example:

can be cut down to:

because: -62+60 = -310+308 = -2

Performance tips

These rules are optional, but they help speeding up the SVG.

Tools

Tools can help to clean SVG files. Note, however that some of the rules stated above can be hard to detect with automated tools since they require too much context-awareness. To this date, there doesn’t seem to be a tool that handles all of the above. However, there are some utilities that cover parts of this document: