Sharing / Theme Tools: update social icons to use single SVGs instead of icon font or SVG sprite

[jeherve]

The Jetpack plugin currently ships with 3 versions of elements of https://github.com/Automattic/social-logos :

• One is added as a npm dependency: it is used in our React-powered interfaces (Jetpack Dashboard > SEO Tools / the post editor)

  jetpack/projects/plugins/jetpack/package.json

  Line 103 in eb5dc63

  "social-logos": "2.5.2",

• The other is a direct copy of the icon font only:
  • https://github.com/Automattic/jetpack/tree/eb5dc637d0bec1cd195ea99171e309de2d6398a5/projects/plugins/jetpack/_inc/social-logos
  • https://github.com/Automattic/jetpack/blob/eb5dc637d0bec1cd195ea99171e309de2d6398a5/projects/plugins/jetpack/_inc/social-logos.php
• The third one is a copy of the SVG sprite, used for both the Social Icons Widget and the Social Menus theme tool: https://github.com/Automattic/jetpack/blob/eb5dc637d0bec1cd195ea99171e309de2d6398a5/projects/plugins/jetpack/modules/theme-tools/social-menu/social-menu.svg

While this works today, it has a few inconvenients:

1. This complexity makes adding a new logo a multi-step process: add the logo in the source repo, release a new version of the package, start using the package in the Jetpack plugin, update the SVG sprite in the Jetpack plugin, update the icon font in the Jetpack plugin. This, of course, assuming the source repo tooling works in our favor (right now it doesn't, due to https://github.com/Automattic/social-logos/issues/116 )
2. The icon font is problematic for display, and can cause issues in some scenarios: Shorten font url for "social-logos" font family. Causes 414 errors on some hosts. #6076, Social Logos CSS Not Optimized #13201, and Sharing: issues decoding Social Logos font on pages including sharing buttons #7148 are good examples.
3. Relying on the SVG sprite in the Social Menu outputs all the SVGs on sites that may only need to display a few: Social Icons Widget / Social Menu Theme Tool: include only SVGs needed #16673

As part of #27817, maybe we could switch all our implementations to one single npm dependency and single SVGs that would be used when necessary. cc @davemart-in

---

Issues that could be closed if this were addressed:

• Shorten font url for "social-logos" font family. Causes 414 errors on some hosts. #6076
• Social Logos: Track upstream library #13708
• Social Logos CSS Not Optimized #13201

[davemart-in]

@jeherve what are you thinking would be the most efficient way to do this?

Let's label these for easy reference:

A) NPM dependency
B) Icon font
C) SVG sprite

Editing SVGs

As you know SVG code needs to be inlayed directly in the Jetpack's code if we want to be able to edit the colors dynamically (we can't just store the .svg files and call them directly). Using an icon font is another way around this, but similar to you, I've found them to be tedious, troublesome, and somewhat unreliable over the years.

I'm guessing that A & B both dynamically edit SVGs (i.e. change colors in CSS).

SVG Sprite

This one is easy. Since it's pulling directly from an SVG file, we know that there are no dynamic styles being set, as this is simply disallowed.

SVGs in React

In wp-calypso we store each SVG as individual JSX files which we can then include in any file. But this only works for React-powered interfaces.

Another approach would be to use SVGR. I'm not sure what the appetite would be to make this a JP dependency though. It certainly keeps things clean though since you can pull SVGs directly from SVG files and it will render them inline for you.

Icon font

This is likely going to be the trickiest one to accommodate. I see three uses of this font:

1. admin-sharing.css
2. amp-sharing.css
3. sharing.css

Similar to SVGR, we can inline SVG's directly from an SVG file using PHP: <?php echo file_get_contents("{file}.svg"); ?>

But I'm not sure the best way for us to determine which icons would need to be loaded (to avoid having to load every icon on page load, whether they're used or not).

I'll stop here... :-) Curious to hear your thoughts.

[davemart-in]

Also, not sure where this comes into play, but I stumbled across it this morning, so I figured I'd call it out: https://github.com/Automattic/jetpack-social-icons

[jeherve]

I'm not sure the best way for us to determine which icons would need to be loaded (to avoid having to load every icon on page load, whether they're used or not).

I'm not 100% sure either to be honest. I don't have much experience with this.

avoid having to load every icon on page load, whether they're used or not

That, I think we should actively avoid.

Similar to SVGR, we can inline SVG's directly from an SVG file using PHP:

I'm thinking this may be our best bet.

Each button has its own class, e.g. Pocket:

jetpack/projects/plugins/jetpack/modules/sharedaddy/sharing-sources.php

Lines 2586 to 2602 in 5463f2e

	/**
	* Pocket sharing service.
	*/
	class Share_Pocket extends Sharing_Source {
	/**
	* Service short name.
	*
	* @var string
	*/
	public $shortname = 'pocket';
	/**
	* Service icon font code.
	*
	* @var string
	*/
	public $icon = '\f224';

I'm thinking we could fetch the right SVG in each class, and load it for each button.

I stumbled across it this morning, so I figured I'd call it out: Automattic/jetpack-social-icons

Yep, this ended up in Jetpack. It lives here:
https://github.com/Automattic/jetpack-social-icons/blob/92f1d6ed991ecafd1aed51adb8d338b260316284/jetpack-social-icons.php

It uses an SVG sprite, and thus suffers for that problem above:
https://github.com/Automattic/jetpack-social-icons/blob/92f1d6ed991ecafd1aed51adb8d338b260316284/jetpack-social-icons.php#L68-L73
It's tracked in #16673.