Contrib.social

[meta] svg guidelines / requirements

Open on Drupal.org →
Created on 24 February 2015, about 10 years ago
Updated 29 May 2023, almost 2 years ago

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 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 <img> tag, or referenced in CSS backgrounds, in cases where SVG needs to be manipulated (e.g. animated or color changed) via CSS or JavaScript, whereas external SVGs referenced in CSS backgrounds cannot.

    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".

  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 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 <a xlink:href="http://example.com"> tags.

  7. SVG Localization
    SVG can contain text. So if we use <title>and <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

Remaining tasks

User interface changes

API changes

🌱 Plan
Status

Active

Version

11.0 🔥

Component
CSS  →

Last updated 3 days ago

Created by

🇩🇰Denmark mortendk

Live updates comments and jobs are added and updated live.
  • Accessibility

    It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.

  • Needs accessibility review

    Used to alert the accessibility topic maintainer(s) that an issue significantly affects (or has the potential to affect) the accessibility of Drupal, and their signoff is needed (see the governance policy draft for more information). Useful links: Drupal's accessibility standards, the Drupal Core accessibility gate.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment almost 2 years ago →
    🇨🇦Canada mgifford Ottawa, Ontario

    With inline SVG we can manage multilingual content in Twig.

    Lots to pull on from here https://cariefisher.com/a11y-svg-updated/

  • Comment about 1 year ago →
    🇦🇹Austria hudri Austria

    Default presentation attributes (fill/stroke/etc) should be moved off from SVG tags if it reduces the weight, and placed as Internal CSS

    Please don't do this, especially not in core. I even propose to avoid CSS styles and encourage the use of presentation attributes, as they are very easy to overrule in CSS by contrib+custom modules and themes. To avoid repetition and weight, better use an intermediate group (e.g. <g fill="currentcolor">) instead.

    Do not re-enter the dark age of CSS selector specifity battles

    .my-custom-admin-sub-theme .gin-theme #contrib-module a svg path.something { color: blue !important; }
.my-custom-admin-sub-theme .gin-theme #contrib-module a:hover svg path.something { color: red !!!!!!!!!important; }
  • Comment about 1 year ago →
    🇨🇦Canada SKAUGHT
  • Comment 3 days ago →
    🇪🇨Ecuador jwilson3

    Re #58:

    Default presentation attributes (fill/stroke/etc) should be moved off from SVG tags if it reduces the weight, and placed as Internal CSS

    Please don't do this, especially not in core. I even propose to avoid CSS styles and encourage the use of presentation attributes, as they are very easy to overrule in CSS by contrib+custom modules and themes.

    I tend to agree, but I feel like it is hard to make call one way or the other. It seems to me that this is highly dependent on how complex the SVG (or group of SVGs) is and how many attributes there are that would be shared/duplicated. Furthermore, there is a good argument that by using classes instead of inline attributes, the classnames become the api, giving core the freedom to change/tweak things like hex colors getting converted to rgb or CSS attributes eg path.something {fill: var(--my-color, #00ff00); } without breaking the overrides in your custom theme.

    To reframe my point in the context of your example on comment #58...

    This:

    #contrib-module a svg path.something {
  fill: blue !important;
}
#contrib-module a:hover svg path.something {
  fill: red !important;
}

    Seems much less fickle than:

    #contrib-module a svg path[fill="#00ff00"] {
   fill: blue !important;
}
#contrib-module a:hover svg path[fill="#00ff00"] {
   fill: blue !important;
}

    In the second example, if the SVG from core or contrib ever changes the fill attribute value, your theme override breaks. I could be wrong here but it seems unexpected that the fill attribute value is the API, and OTOH, much more obvious that a classname is an API, and has been purposefully added in the SVG to make theme overrides more stable.

  • Comment 3 days ago →
    🇪🇨Ecuador jwilson3

    I've pulled over a few additional best practices from the current issue I was working on 📌 Update Drupal's default file type icons Active .

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024