We need some guidelines for svg & svg icons for Drupal core.
The issue have come up during the work on the RSS icon
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.
Write a guideline... here is a start:
Goals of SVGs:
- Support high-resolution displays automatically -- because SVGs are vectors they can scale up to any pixel density without losing clarity.
- 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.
- 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.
- 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
svgocommand 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
ryattributes 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.
- 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)
- 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.
- Inline SVG Vs external SVG
There is no single right answer to inline versus external SVG.
Inline SVG (i.e. SVG images embedded directly inside twig templates) is preferred over external SVG asset files added via
When SVG does not need manipulation, keeping them as external assets has the benefit of SVG files being cached by the browser.
We need to weigh the pros/cons and analyze the SVG Sprite option also (less HTTP requests, and cacheable).
Consider also that HTTP 2.0 is minimizing the benefit of "saving HTTP requests".
- 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
<g>followed by a single
<foreignObject>tag containing the fallback
Other fallback methods available: Use
- SVG Accessibility
SVG Accessibility is only really applicable to inline SVGs. Inline SVGs can be be given text alternatives by adding a
<title id="title">tag inside the SVG and referencing this using an
aria-labelledby="title"attribute on the
<svg>tag itself, i.e.:
<svg aria-labelledby="title"> <title id="title">Alternative text goes here</title> <!-- Remaining SVG code follows. --> </svg>
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.
-- Léonie Watson Tips for Creating Accessible SVG (Sitepoint article)
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
- SVG Localization
SVG can contain text. So if we use
<desc>for accessible labels, these will need to be localizable.
Can we generate SVG using Twig? How do we cache these per locale?
The current recommendation is that text in SVGs (particularly visible text) should be avoided. As stated on a blog post from Una Kravets:
Running the website through the web interface Google Translate Tool could possibly translate the SVG text if the character glyphs exist in the specified font, but may also break the SVG due to viewbox constraints. So even though the diagram text is highlightable, don't rely on SVG images to be the tools you need for text translation.
Tools & Resources
- A Compendium of SVG Information
- SVG `symbol` a Good Choice for Icons
- Using ARIA to enhance SVG accessibility - very detailed information about the state of browser and screenreader support, as of December 2013
- Tips for Creating Accessible SVG