Manual:Coding conventions/SVG/en

This page describes the coding conventions used within files of the MediaWiki codebase written in SVG. See also the general conventions which apply to all programming and markup languages, including SVG.

We make use of SVGO as optimisation tool, see automated optimisation below.

Code structure
Minimal code as possible with readability in mind is the premise.

Example for simple optimised file – subtract.svg from OOUI:

For minimalists, exactly the same can be drawn with

Example for slightly more complex, optimised file – BetaFeatures screenshot template:

We will explain the different coding conventions in the following section.

How to use
Is it recommended to install  from https://github.com/svg/svgo or from   for the command line. There is also an in-browser demo to help with preview and general understanding of the tool at https://jakearchibald.github.io/svgomg/. This should not be used to create production files however.

Safe plugins:
As some SVGO default plugins (options) might result in unexpected appearance with more complex SVGs, we differentiate between safe, considerably less-safe and unsafe plugins. Set the "transformPrecision" at least to 7 to reduce the rist of breaking files. When using unsafe plugins it's recommended to verify before and after diffing per file to ensure visual quality.

Mentioning only plugins, that are changed from default setting or that might be counter-intuitive:

See SVGO Readme for other enabled, safe plugins.
 * Sorting attributes . Enable by setting to ; disabled by default
 * Remove or cleanup  attribute when possible  . Deprecated attribute, only supported by IE/Edge; enabled by default

Plugins to consider carefully:


 * Remove unused and minify used IDs 'cleanupIDs' Might negatively affect readability and breaks some files ; enabled by default
 * Remove raster images 'removeRasterImages' As general rule dangerous, could cause data loss, some raster-images are difficult to spot ; disabled by default
 * inlineStyles some users prefer to use CSS than inlineStyles, can reduce editability
 * removeDoctype for SVG 1.1 there is not reason to remove it, however for the upcommong SVG2-draft it will be deapreciated

Unsafe rules to disable (don't use!):


 * 'convertPathData' Might cause (i) imprecise rendering, (ii) wrong rendering by librsvg, (iii) breaking files  ; enabled by default
 * Round/rewrite number lists cleanupListOfValues breaks Wikimedia-renderin
 * convertShapeToPath can reduce readability and breaks files
 * Remove XML processing instructions 'removeXMLProcInst', aka XML declaration   Issues when viewed as standalone file in some editors, also possible issues with MIME type interpretation Example: If the SVG doesn't start with an XML declaration, then it's MIME type will be detected as   rather than   by libmagic and consequently, MediaWiki's CSSMin CSS minifier. libmagic's default database currently requires that SVGs contain an XML declaration; disable by setting to ; enabled by default
 * Remove 'removeTitle' Problematic for accessibility reasons ; set to ; enabled by default
 * Remove 'removeDesc' Problematic for accessibility reasons; set to ; enabled by default
 * Remove  attribute 'removeViewBox' Results in troublesome appearance in some browsers, therefore both,  /  and   should be featured; set to ; enabled by default
 * Remove dimensions /  when   is available 'removeDimensions' As above; set to ; disabled by default
 * removeMetadata Possible Copyright-Information
 * removeHiddenElems Possible reference lines, editor data, real text before convertion, Copyright-informations
 * removeUnknownsAndDefaults removes Flow-Text
 * cleanupNumericValues breaks some files
 * minifyStyles breaks some files
 * removeComments reduces readability and possible removes reference lines, editor data, real text before convertion, Copyright-informations
 * removeEditorsNSData reduces editability with GUI-SVG-Editors
 * collapseGroups reduced readabilty and editability and breaks some files
 * removeStyleElement breaks some files
 * removeOffCanvasPaths breaks some files
 * removeEmptyContainers breaks some files
 * removeElementsByAttr breaks some files
 * convertStyleToAttrs breaks some files
 * convertTransform breaks some files
 * cleanupNumericValues breaks some files
 * inlineStyles breaks some CSS-features
 * reusePaths breaks some files

Exemplified safe configuration
Note that this is for SVGO v1.x; v2.x takes different CLI arguments:

Use  output for human readable code and in the process indent code by tabs.

Exemplified safe configuration (.svgo.config.js)
Update 2023-06: SVGO v3.0.0+ compatibility, amending to new  plugin name (phab:T324899).

Update 2022-01: NPM run scripts enabled SVGO configuration (T246321).

Exemplified safe configuration (Gruntfile.js)
svgmin: { options: { js2svg: { indent: '\t', pretty: true },		plugins: [ { cleanupIDs: false }, {			removeDesc: false }, {			removeRasterImages: true }, {			removeTitle: false }, {			removeViewBox: false }, {			removeXMLProcInst: false }, {			sortAttrs: true }, {			convertPathData: false // https://github.com/svg/svgo/issues/880 }, {			removeMetadata: false // Copyright-Violation }, {			removeHiddenElems: false // source for converted text2path }, {			removeUnknownsAndDefaults: false // removes Flow-Text }, {			cleanupNumericValues: false // https://github.com/svg/svgo/issues/1080 }, {			minifyStyles: false //https://github.com/svg/svgo/issues/888 }, {			removeComments: false //reduces readability }, {			removeEditorsNSData: false // https://github.com/svg/svgo/issues/1096 }, {			collapseGroups: false // https://github.com/svg/svgo/issues/1057 }, {			removeOffCanvasPaths: false //https://github.com/svg/svgo/issues/1732 }, {			removeEmptyContainers:false // https://github.com/svg/svgo/issues/1194 https://github.com/svg/svgo/issues/1618 }, {			convertTransform: fasle // https://github.com/svg/svgo/issues/988 https://github.com/svg/svgo/issues/1021 }, {			cleanupNumericValues: false // https://github.com/svg/svgo/issues/1080 }, {			inlineStyles: false // https://github.com/svg/svgo/issues/1486 } ]	} }

Manual optimisation
Beyond automated optimising SVGs there are further steps to consider:


 * retain the following code,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  , ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  , see c:Help:SVG guideline
 * Remove  from XML processing instruction, as it's default
 * Lowercase (for better gzipping) and shorten hex color values, if possible, e.g.  instead of.
 * Attributes that are the same for a group of elements can be applied to a common parent instead, or sometimes even specified by the   statement (see an example: CHE Bettens COA.svg). This might reduce the editability or readability
 * Rely on defaults like  and.
 * The  syntax is almost always shorter than the syntax of basic shapes like  or even, however , ,  are generally more easy to read&edit, therfore there is generally prefered to use more specific ones.
 * Merge  elements where applicable. Do not do that if the both path should be edited speratly.
 * Do not remove redundant  attribute when identical to   it get's more difficult to read&edit.
 * Remove not needed  and  . These rules only have an effect on certain paths, e.g. when a path intersects itself.
 * Look for IEEE rounding errors like  or  . Such numbers take up space without providing any additional information. They can almost always be cut off without visually changing anything.
 * Work with a non-fractional pixel grid while drawing, and align as much points as possible on this grid. These points have a much higher chance of being represented as short integer numbers in the resulting code.
 * Pick a non-fractional grid so that it matches the features of an existing image, and scale or redraw shapes so that as many points as possible fall on the grid. The result might be misaligned and can be cropped using.

If you want to dig even deeper, there are more optimisations to compress delivery, such as:


 * auto-closing paths (aka removing  for certain shapes),
 * use relative commands when creating paths (instead of absolute commands, e.g. "m" for "move by", instead of "M" for "move to"),
 * optimising for compression backreferences

Other tools
Other tools that may be helpful to know about:


 * 1) SvgWorkAroundBot
 * 2) SVGOMG
 * 3) scour
 * 4) svgcleaner
 * 5) check Help:SVG guidelines#How to optimize for more options.

Description&History
This opimizer was one of the first optimizers: Since 2009 it included with the installation of Inkscape, it can be used by saving Inkscape-files with "Optimized Inkscape SVG", and in 2013 seperated into an self-contained project available at https://github.com/scour-project/scour. It is maintained by the Inscape-Developer Patrick Storz (Ede123).

How to use
You can use in the browser at https://svgworkaroundbot.toolforge.org/ or install it via  from the command line (Linux-PC/Mac-PC/Windows).

safe plugins
Scour is a very cautious optimizer, however some plugins can still be break the file or remove important non-visible parts, to be on the safe side you can use

Description&History
This optimizer was developed from Jan 2012 to 2022 by Yevhenii Reizner. It focusses on following the current w3c-Standards (SVG1.1). Compared to scour or svgo it breaks less files, reduces the file size more and the performance is magnitues faster.

How to use
You can use in the browser at https://svgworkaroundbot.toolforge.org/ or download it from https://github.com/RazrFalcon/svgcleaner-gui/releases.

safe plugins
Files will be treated according to the standards, however sometimes file non-svg-elements which are importante for reading and/or editing the file, to be on the safe side you can use