Problem/Motivation
The use of externally-sourced SVG using <use> tags is perfectly fine for most scenarios. However, it has a few shortcomings, including the following:
- The inability to target specific SVG child elements (like paths) using classes or IDs using CSS
- Handling color can be troublesome. You can have your SVG inherit the currentColor, but ¿what happens with icons with more than two colors? (i.e a SVG icon that on :hover contrasts its colors and needs to handle a foregroudn and background colors)
This is why I think a great addition to this module could be the ability to decide wether the SVG needs to be externally sourced or inlined.
Proposed resolution
I have developed a working solution, it is a quick workaround and might not be the "best" way to handle this, but it might serve as a starting point or proof-of-concept.
I'm just loading the markup on each Icon plugin definition and allowing the user to pass a '#use_markup' flag to the template. This way, you can pass a fourth parameter to the Twig function :
{{ ex_icon(link.class, {width: 30, height: 30}, link.text, true) }}
...or to a render array:
return [
'#theme' => 'ex_icon',
'#id' => $icon,
'#title' => $title,
'#attributes' => $attributes instanceof Attribute ? $attributes->toArray() : $attributes,
'#use_markup' => $use_markup
];
The markup is loaded on SvgSpriteSheet:decode(), on a new getRawSvg() function
$data['icons'][$id] = [
'width' => (double) $viewbox[2] - (double) $viewbox[0],
'height' => (double) $viewbox[3] - (double) $viewbox[1],
'label' => $title ? $title->nodeValue : '',
'markup' => self::getRawSvg($symbol),
'viewbox' => $symbol->getAttribute('viewBox'),
];
There are several areas of concern, the first one being that this might pose a security risk if anybody can access and alter the sprite SVG
sheet. Drupal's sanitization filters strip SVG, so I have used an external dependency (enshrined/sanitizer) to perform a sanitization prior to output.
Also, due to Drupal's shortcomings on SVG rendering, the markup has to be rendered using 'inline_template'' in order to avoid the SVG strippiing.
As I said before, this is a quick workaround and there is clearly a lot of area for improvements. The code can be abstracted, there are several ugly string concatenations that might be improved, in general the SVG markup generation could be much better. Nevertheless, I think it is an interesting feature to support.