atalho: CC/SVG

Manual:Convenções de codificação/SVG

Jump to navigation Jump to search
This page is a translated version of the page Manual:Coding conventions/SVG and the translation is 90% complete.
Outdated translations are marked like this.
Other languages:

Esta página descreve as convenções de codificação usadas nos arquivos da base de código MediaWiki escrita em SVG. Veja também as convenções gerais que se aplicam a todas as linguagens de programação e marcação, incluindo SVG.

Por projeto, usamos SVGO como ferramenta de otimização, veja otimização automatizada abaixo. Outra ferramenta útil para otimização manual posterior é SVGOMG. Ele fornece uma comparação visual antes/depois.

Estrutura do código

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

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

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="" width="20" height="20" viewBox="0 0 20 20">
	<path d="M4 9h12v2H4z"/>

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

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="" width="264" height="162" viewBox="0 0 264 162">
        BetaFeatures screenshot template
        <clipPath id="jagged-edge">
            <path d="M0 0v152l12 10 12-10 12 10 12-10 12 10 12-10 12 10 12-10 12 10 12-10 12 10 12-10 12 10 12-10 12 10 12-10 12 10 12-10 12 10 12-10 12 10 12-10V0z"/>
    <g fill="#eaecf0" clip-path="url(#jagged-edge)">
        <path id="background" fill="#fff" d="M0 0h264v162H0"/>
        <path id="logo" d="M11 22c0-8 6-14 14-14s14 6 14 14-6 14-14 14-14-6-14-14M38 45v-5H13v5h25"/>
        <path id="sidebar" d="M38 163V58H13v106h25"/>
        <path id="personal-tools" d="M233 5h26v6h-26V5zM209 5h22v6h-22zM185 5h22v6h-22zM162 5h13v6h-13zM177 5h6v6h-6zM154 5h6v6h-6z"/>
        <path id="search-input" d="M258 16v4h-92v-4h92m1-1h-94v6h94v-6z"/>
        <path id="search-icon" d="M168 17h2v2h-2z"/>
        <path id="article" d="M252 162V29H48v133z"/>
        <path id="border" d="M0 0v162h264V0zm1 1h262v150.533l-11 9.166-12-10-12 10-12-10-12 10-12-10-12 10-12-10-12 10-12-10-12 10-12-10-12 10-12-10-12 10-12-10-12 10-12-10-12 10-12-10-12 10-11-9z"/>

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

Otimização automatizada (SVGO)

A standard set of conventions can be enforced by help of SVGO. If your original SVGs are well-formed, you should be able to automatically optimise them. 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. When using unsafe plugins it's recommended to verify before and after diffing per file to ensure visual quality.

Safe plugins:

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

  • Sorting attributes 'sortAttrs'
    Enable by setting to true; disabled by default
  • Remove DOCTYPE 'removeDoctype'
    Using a DOCTYPE in SVGs is considered harmful by SVG standards authors as of SVG 2 Working Draft; enabled by default
  • Remove or cleanup enable-background attribute when possible 'cleanupEnableBackground'
    Deprecated attribute, only supported by IE/Edge; enabled by default

See SVGO Readme for other enabled, safe plugins.

Plugins to consider carefully: 

  • Round/rewrite number lists 'convertPathData'
    Might cause imprecise rendering; enabled by default
  • Remove unused and minify used IDs 'cleanupIDs'
    Might negatively affect readability in more complex SVGs; enabled by default
  • Remove raster images 'removeRasterImages'
    As general rule dangerous, could cause data loss; disabled by default

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

  • Remove XML processing instructions 'removeXMLProcInst', aka XML declaration <?xml version="1.0" encoding="UTF-8"?>
    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 text/plain rather than image/svg+xml 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 false; enabled by default
  • Remove ‎<title> 'removeTitle'
    Problematic for accessibility reasons; set to false; enabled by default
  • Remove ‎<desc> 'removeDesc'
    Problematic for accessibility reasons; set to false; enabled by default
  • Remove viewBox attribute 'removeViewBox'
    Results in troublesome appearance in some browsers, therefore both, width/height and viewbox should be featured; set to false; enabled by default
  • Remove dimensions width/height when viewbox is available 'removeDimensions'
    As above; set to false; disabled by default

Configuração segura exemplificada

Observe que isso é para svgo v1.x; v2.x tem diferentes argumentos CLI:

$ svgo path/to/image.svg --disable={cleanupIDs,convertPathData,removeDesc,removeTitle,removeViewBox,removeXMLProcInst} --enable='sortAttrs' --pretty --final-newline

Use a saída pretty para código legível por humanos e no código de recuo do processo por guias.

Configuração segura exemplificada (.svgo.yml)

Update Jan 2022: NPM scripts enabled SVGO configuration (phab:T246321).

 * SVGO Configuration
 * Compatible to v2.8.0+
 * Opções recomendadas de:
module.exports = {
	multipass: true,
	plugins: [
			// Set of built-in plugins enabled by default.
			name: 'preset-default',
			params: {
				overrides: {
					cleanupIDs: false,
					removeDesc: false,
					removeTitle: false,
					removeViewBox: false,
					// Se o SVG não começar com uma declaração XML, então seu tipo MIME será detectado como "text/plain" em vez de "image/svg+xml" por libmagic e, consequentemente, o minificador CSS CSSMin do MediaWiki.
					// O banco de dados padrão de libmagic atualmente requer que os SVGs contenham uma declaração XML:
					removeXMLProcInst: false,
	// Configure o recuo (padrão 4 espaços) usado por '--pretty' aqui:
	// @see for more config options
	// Infelizmente o EOL não pode ser configurado, o svgo usa o marcador EOL da plataforma.
	// Em sistemas ''non-unix'', as quebras de linha serão normalizadas para LF (unix) apenas no ''git commit'', assumindo que 'core.autocrlf' é 'true' (padrão) ou 'input'.
	js2svg: {
		indent: "\t",
		pretty: true,

Configuração segura exemplificada (Gruntfile.js)

svgmin: {
	options: {
		js2svg: {
			indent: '\t',
			pretty: true
		plugins: [ {
			cleanupIDs: false
		}, {
			removeDesc: false
		}, {
			removeRasterImages: true
		}, {
			removeTitle: false
		}, {
			removeViewBox: false
		}, {
			removeXMLProcInst: false
		}, {
			sortAttrs: true
		} ]

Otimização manual

Beyond automated optimising SVGs there are further steps to consider:

  • Remove standalone="no" from XML processing instruction, as it's default
  • Remove version attribute from ‎<svg> tag, as all browsers ignore it
  • Lowercase (for better gzipping) and shorten hex color values, if possible, e.g. #fff instead of #FFFFFF.
  • Attributes that are the same for a group of elements can be applied to a common parent ‎<g> instead.
  • Rely on defaults like fill="#000" and stroke-width="1".
  • The <path d="…"/> syntax is almost always shorter than the syntax of basic shapes like ‎<polygon> or even ‎<rect>. The only possible exceptions are ‎<circle>, ‎<ellipse>, and rounded <rect rx="…">, as converting them to paths typically results in sequences of long floating point numbers.
  • Merge <path d="…"/> elements where applicable.
  • Remove redundant ry="…" attribute when identical to rx="…" as renderer must consider both values identical when one's missing.
  • Remove not needed fill-rule="…" and clip-rule="…". These rules only have an effect on certain paths, e.g. when a path intersects itself.
  • Look for IEEE rounding errors like 0.999999999 or 1.000000001. 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 viewBox="<left> <top> <width> <height>".

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

  • auto-closing paths (aka removing z 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