[meta] svg guidelines / requirements

Problem/Motivation

We need some guidelines for svg & svg icons for Drupal core.

The issue have come up during the work on the RSS icon #2427213: replace feed.png with feed.svg

To sum it up we need Guidelines:
- How should a svg icons be created stroke's / vectors
- Which apps do we want it to support (sketch, illustrator ..?
- must be editable colors with css (inline) ?
- Does it even matters & by having "guidelines" the design community will pretty much move on, as they want it to look pretty, not use time on svgo optimization etc.

Proposed resolution

Write a guideline... here is a start:

Goals of SVGs:

1. Support high-resolution displays automatically -- because SVGs are vectors they can scale up to any pixel density without losing clarity.
2. Replace as many static image assets in core as possible -- static image assets (jpgs and pngs) currently in Drupal core are not scalable, and do not support hi-res displays so we should attempt to replace as many of them as possible.
3. Lay framework of best practices that contrib can adopt -- this could mean demonstrations of both inline svgs (ie inside twig templates) as well as external svg assets in core.

Best Practices

1. Minimize file size

   Since these little icon files are assets that will be loaded (downloaded) millions of times across millions of websites, one of the most important tenants is to require the smallest file size possible for the SVGs in core. So just as "profiling" the server-side implications of changing each phptemplate into twig, so important is it also to ensure SVG files are optimized and even potentially minified. This means manual (or automatic) removal of all "crap" produced by vector design applications like Illustrator, Sketch, and Inkscape. Removal of these elements should not inhibit editability in these applications as the resulting SVG still conforms to the spec.

   There are not so many graphics in Drupal core, so it is not problematic to have high standards here. Once created, the SVG file could be unmodified for years.

   There are a number of ways to optimize SVGs including via the svgo command and/or optimized manually -- each of which might produces better results in different cases. The best method usually depends on the complexity of the SVG. For example, the points required for a rounded rectangle as a <path>end up being more code than using a <rect> with the rx and ry attributes to give the rounded corners. The strategy can be that a designer can create the SVG and someone else can optimize it with svgo or by hand.

2. Validate against SVG 1.1

   All core assets should pass through the validator http://validator.w3.org successfully. Although, we can ignore the "DOCTYPE missing" error, it seems not necessary and to be removed in SVG 1.2 according to MDN documentation article (about namespaces)

3. Indentation & coding standards
   • SVG is markup, and therefore should use proper indentation (2 spaces). SVGO strips whitespace by default, so this is something we should maybe discuss further if to sacrifice readability vs weight
   • Like CSS standards, use lowercase hex colors for fill and stroke.
   • Use SMACSS class structures on SVG tags, particularly when there is more than one of the same tag in an SVG. This will facilitate easy style overrides from a theme's CSS.
   • Like CSS standards, classes should be preferred to ID attributes. ID attributes should be stripped, unless they are used as Fragment Identifiers
   • Default presentation attributes (fill/stroke/etc) should be moved off from SVG tags if it reduces the weight, and placed as Internal CSS (inside a <style> tag). Note: this is a manual procedure, there are not many tools to automate this process. Try Illustrator CSS Properties: SVG Elements in the SVG save settings
   • Do not base64 encode inline SVGs -- there are serious performance implications in doing this.
4. Inline SVG preferred over external assets

   Inline SVG (i.e. SVG images embedded directly inside twig templates) is preferred over external SVG asset files added via <img> tag, or referenced in CSS backgrounds. Inline SVGs can be manipulated (e.g. animated or color changed) via CSS, whereas SVGs referenced in CSS backgrounds cannot.

   Although In case of big SVG assets maybe inlining them it's not preferred. SVG images won't be cached by the browser, so we need to weigh the pros/cons and analyze SVG Sprite options also.

5. Fallback methodologies

   Although SVG is widely supported, there are some exceptions, like IE8. There is barely any consensus on the "best way" to support fallbacks. If using inline SVGs (as is the best practice), then by and large the best fallback method has to be the SVG <switch> structure, because it is the only foolproof fallback method that has no dependencies on javascript. The switch tag requires the first element be a group tag <g> followed by a single <foreignObject> tag containing the fallback <img> inside.

   Other fallback methods available: Use .no-svg and .svg classes in css to provide background image fallbacks. Because this fallback method requires modernizr javascript be loaded on the page, this is an inferior solution that should only be considered as a last resort.

6. SVG Accessibility

   SVG Accessibility is only really applicable to inline SVGs. Inline SVGs can be made accessible by adding a <title> tag inside the svg and adding the aria-labelledby="title" attribute on the <svg> tag itself. "ARIA support is introduced officially into the SVG 2.0 specification, but it is still possible to use ARIA with SVG 1.1 content. Some examples in this article will raise a flag when you validate your HTML, but it’s a reasonable exception to make." -- Sitepoint

   If the image content is purely graphical, add the role="img" attribute to the <svg> tag. If the SVG is interactive, make use of <text> tags for readable text and make the interactive elements focusable by wrapping them in <a xlink:href="http://example.com"> tags.

Tools & Resources

• Optimization:
  https://jakearchibald.github.io/svgomg/
  https://github.com/svg/svgo
  https://github.com/svg/svgo-gui
  https://github.com/davidderaedt/SVG-NOW

Remaining tasks

User interface changes

API changes