SVG Helper

[rdimascio]

Is your enhancement related to a problem? Please describe.

We end up adding an SVG helper to every project, usually a variation of this template tag, and would benefit from a unified approach added the our theme scaffold.

While this helper function works 90% of the time, I think something to consider is that this approach uses file_get_contents for every icon on the page — which can end up in many calls. It also uses inline SVGs, which can be one of the best approaches in terms of performance, but for sites with large or unoptimized SVGs, it's by far the worst - https://cloudfour.com/thinks/svg-icon-stress-test/#breakdown-by-technique.

It's also important to consider how we're rendering icons in other contexts (JS template tags and the block editor). Ideally, we would have approach that can use the same SVGs in every context, so that we don't repeat ourselves.

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[Firestorm980]

Just wanted to note, we were considering something similar in the old scaffold. See previous discussion for which direction that was going (ultimately not merged): 10up/theme-scaffold#120

It's also important to consider how we're rendering icons in other contexts (JS template tags and the block editor). Ideally, we would have approach that can use the same SVGs in every context, so that we don't repeat ourselves.

Consistency would be nice between all contexts.

Places we'd want this to work so far:

• On front end templates (authored by us)
• Gutenberg / React (editor and front end, includes dynamic and static blocks)
• Other JS (vanilla or otherwise, for non-Gutenberg contexts)

[dainemawer]

Great idea. I have often gone with embedding 1 SVG sprite file into the DOM and the function referencing <use> tags - this method makes 1 server request on page load and any and all SVG's can be referenced pretty easily:

function get_svg( $id, $attrs, $echo = false ) {

	if( empty( $id ) ) {
		return;
	}

	$config = [
		'width'       => ! empty( $attrs['width'] ) ? $attrs['width'] : '',
		'height'      => ! empty( $attrs['height'] ) ? $attrs['height'] : '',
		'class'       => ! empty( $attrs['class'] ) ? $attrs['class'] : '',
		'title'       => ! empty( $attrs['title'] ) ? $attrs['title'] : '',
	];

	$filename = 'symbol-defs';

	$svg = '<svg xmlns="http://www.w3.org/2000/svg" class="'. $config['class'] .'" aria-hidden="true" role="presentation" width="'. $config['width'] .'" height="'. $config['height'] .'">';

	$svg .= '<use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="' . BDC_2020_TEMPLATE_URL . '/assets/symbol-defs.svg#' . $id . '"></use>';

    $svg .= '<use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="' . BDC_2020_TEMPLATE_URL . '/assets/' . $filename . '.svg#' . $id . '"></use>';

	$svg .= '</svg>';

	if ( ! empty( $config['title'] ) ) {
		$svg .= '<span class="screen-reader-text">'. $config['title'] .'</span>';
	}

	if( $echo ) {
		echo wp_kses(
			$svg,
			array(
			'span' => array(
				'class' => true,
			),
			'svg' => array(
				'version'           => true,
				'class'             => true,
				'height'            => true,
				'width'             => true,
				'aria-hidden'       => true,
				),
				'title' => array(
					'id' => true
				),
				'desc' => array(
					'id' => true
				),
				'defs' => true,
				'use' => array(
					'xmlns:xlink' => true,
					'xlink:href' => true,
				),
			)
			);

		return;
	}

	return $svg;

}

[Firestorm980]

@joesnellpdx @dainemawer @rdimascio So, here's an idea for use in all the contexts we want: what if we made a custom element to help handle this?

The downside, it would be dependent on JS to work. The upside, is it should work in all contexts (It should work in React already. Sounds like deeper compatibility is planned for the next major release, v19. See https://custom-elements-everywhere.com/ and https://reactjs.org/docs/web-components.html). We still use the helper that @dainemawer has in the previous comment, but call our custom element instead, which internally uses svg and use the same way.

See https://dev.to/taybenlor/neater-icons-with-web-components-5af9 for how this might be implemented.

Thoughts? Concerns? Maybe this belongs as a UI helper or in our Baseline library?

[dainemawer]

I'd love to see some web-component work creeping into our tools and processes.
My only concern would be some kind of progressive enhancement - maybe we render a fall back in a <noscript> tag?

Sounds like we can retain accessibility features as well.

Otherwise Im aboard with that solution!

[joesnellpdx]

@Firestorm980 @dainemawer @ryanwelcher

I don't have any issue with going with web components or reliance on JS at this point in time in web development (please push back if you disagree).

My main concern is more the block editor than anything else (admin).

If we feel we can prototype this in our scaffold (and use it with the icon picker) - then I think this makes a lot of sense.

We should have our solution in the scaffold as we need to solve for it every time.

Ideally (in my mind) we wold use inline svgs that are optimized rather than a sprite, but I'm open to consider either or both in that regard.
What if we enabled both in the scaffold? What if we have solutions and guidance for both methods (spriting and inline) in the scaffold? Thoughts?

[darylldoyle]

@joesnellpdx @dainemawer I know this is fairly old, but I think this helper would be a great addition to https://github.com/10up/wp-framework, that way we can iterate on it and release enhancements/fixes to all projects at the same time. If this is something we're still interested in shipping, should we move the conversation to there?

[fabiankaegy]

@darylldoyle For this one I think the framework works 👍

In a perfect world I would have wanted a composer package for the 10up/block-components because that is where this helper is kind of coming from. Today we also already ship this in UI Kit. So that we can leverage that utility function from there...

[fabiankaegy]

@dainemawer here are the icon classes: https://github.com/10up/ui-kit-monorepo/tree/develop/plugins/ui-kit-core/includes/classes

The best case would be if we share the code here in the framework that even when you use UI Kit you can technically still use the framework to register your icons and they get added to the same instance.

On top of the classes here is the logic code to register the icons:

https://github.com/10up/ui-kit-monorepo/blob/2982333ca6f891369fdf246d0b2ad604f7cf723a/plugins/ui-kit-core/includes/core.php#L181-L237