Putting a (Link/Meta) Bow on It

Beyond rendering directly in browsers themselves, web pages also exist in the contexts of search engines, social media, messaging, and other sharing—and we should give attention to how they appear in these environments, too.

We’ve gathered a handful of practices here which adjust and optimize how your site appears through these lenses, via special <link> and <meta> elements that live in your page’s <head>. No site is truly complete without considering these!

Favicons and Touch Images #

Chrome.
i OS/Mobile Safari.

The first of these is the favicon (for favorite icon)—which appears in the browser’s tabs/address bar, bookmarks, history, and also on search engine entries. This is often a logo—though they don’t always translate down well in size. Sometimes it is its own thing! But it is always an important part of the initial impression of your site, and should be carefully considered and constructed.

The Humble favicon.ico (Safari) #

The base favicon format is .ico—from ancient, bitmapped Windows icons. It is a package/directory/container format, meaning it can contain several, discrete, raster icon sizes: 16×16px, 32×32px, 64×64px, etc. (We’ll use different elements for our other/larger needs.)

These are (unfortunately) still needed today because of several, long-standing browser quirks:

  • Browsers still look for a favicon.ico at the root of a domain.
  • These are used, as a default/fallback, if none are specified in your <head>.
  • Safari (so namely, your i OS visitor) needs them—it still doesn’t support SVG favicons (below).

Making It #

You should draw each size individually, when necessary—pixel-tuning each version to land nicely on the pixel grid, so it is legible and crisp at its dimension. You can use Figma’s pixel preview (set at 1x), toggled with ⌘ ~ Ctrl Shift P.

Note that these can have transparent backgrounds, and that HiDPI (2x/retina) displays will render their device-native size—so most folks are seeing your 32px version, these days. Export a PNG for each dimension, from Figma, into your project folder.

Draw an artboard/frame for each size.

These can be combined together in an .ico with ImageMagick—the appropriately named Dark Arts tool at the bottom of every imaging pipeline. (If you’re on a Mac, some version of this is likely already installed; PC s might need to download it). You’ll run this terminal command, in your project folder:

		convert 16.png 32.png 64.png -compress zip favicon.ico

You can open a terminal in VS Code (or separately, from GitHub Desktop) with ⌃ ~ Ctrl ` (control + backtick/tilde).

Linking It #

You should still specify/include the resulting favicon.ico in your <head>, allowing you to organize/move it out of the root:

		<head>
	<title>Typography and Interaction</title>
	<link href="assets/favicon.ico" rel="icon" sizes="any">
	<!-- The rest of your head… -->
</head>

We’ve omitting the responsive viewport element here, for clarity. But your <head> should have this along with all your stylesheets and JS. Just the metadata, here.

A few other (Safari) concerns:

  • Safari caches these dramatically—meaning any changes are not reflected/updated for a very long time. It’s extremely annoying.
  • Safari also doesn’t facilitate detecting light/dark mode, so your icon needs to be visible on both a light and dark toolbar/background.
  • Safari still occasionally decides to mat icons onto white that it doesn’t think have enough contrast. You can’t prevent or control this! Cool.
Safari adds this white!

Oh, Safari. I wish I knew how to quit you.

Modern SVG s (Chrome et al.) #

Chrome is decidedly better, here. It supports SVG s for favicons, which gives us the benefit of the vector format—resolution independence. One file, no intermediate/terminal steps, for different display sizes and densities. It is still a good practice to draw these at 16×16px—so you can pixel-tune them—then export from Figma, now as an SVG.

You should add them to your <head> as a progressive enhancement for Chrome, after the previous <link>; Safari will just ignore them:

		<head>
	<title>Typography and Interaction</title>
	<link href="assets/favicon.ico" rel="icon" sizes="any">
	<link href="assets/favicon.svg" rel="icon" type="image/svg+xml">
	<!-- The rest of your head… -->
</head>

Responsive Favicons #

SVG s have another benefit: since they can include self-contained, internal <style> elements—we can alter/adjust our favicon with prefers-color-scheme (light/dark mode) media queries!

		<svg viewBox="0 0 32 32" fill="none" xmlns="http://www.w3.org/2000/svg">
	<style>
		.foreground { fill: black; }
		.background { fill: white; }

		@media (prefers-color-scheme: dark) {
			.foreground { fill: white; }
			.background { fill: black; }
		}
	</style>
	<rect class="background" width="32" height="32" rx="2" />
	<rect class="foreground" x="4" y="8" width="24" height="2" />
	<path class="foreground" d="M10.4299 22.8988C9.98881 23.3297 9.5169 23.6529 9.01422 23.8683C8.5218 24.0837 7.96269 24.1914 7.3369 24.1914C6.84448 24.1914 6.37771 24.1196 5.93658 23.976C5.50571 23.8324 5.13126 23.6221 4.81324 23.3451C4.49521 23.0578 4.24387 22.7142 4.05921 22.3141C3.87456 21.9037 3.78223 21.437 3.78223 20.9138C3.78223 20.5239 3.84891 20.17 3.98227 19.852C4.11564 19.5237 4.29517 19.2313 4.52086 18.9748C4.75681 18.7081 5.02354 18.4722 5.32105 18.267C5.61855 18.0618 5.92632 17.8823 6.24434 17.7284C5.94684 17.3693 5.69549 17.0103 5.49032 16.6512C5.2954 16.2922 5.19794 15.8715 5.19794 15.3894C5.19794 15.0098 5.27488 14.6661 5.42877 14.3584C5.59291 14.0506 5.80834 13.789 6.07507 13.5736C6.3418 13.3479 6.64443 13.1786 6.98298 13.0658C7.33177 12.9427 7.69083 12.8811 8.06015 12.8811C8.48076 12.8811 8.8706 12.9375 9.22965 13.0504C9.59897 13.1632 9.917 13.3325 10.1837 13.5582C10.4607 13.7736 10.6761 14.0455 10.83 14.3738C10.9942 14.702 11.0762 15.0816 11.0762 15.5125C11.0762 16.1588 10.8865 16.7025 10.5069 17.1436C10.1376 17.5848 9.67591 17.9541 9.12194 18.2516L10.5377 19.9905C10.6505 19.7853 10.7377 19.575 10.7993 19.3595C10.8608 19.1338 10.907 18.9082 10.9377 18.6825H12.8305C12.7792 19.1749 12.6664 19.6519 12.492 20.1136C12.3176 20.5752 12.0765 21.001 11.7687 21.3908L14 23.9914H11.3225L10.4299 22.8988ZM7.39846 19.1441C7.20354 19.2262 7.01375 19.3236 6.82909 19.4365C6.64443 19.5493 6.48029 19.6827 6.33667 19.8366C6.19305 19.9905 6.07507 20.1597 5.98274 20.3444C5.90067 20.529 5.85964 20.7342 5.85964 20.9599C5.85964 21.1548 5.90067 21.3446 5.98274 21.5293C6.07507 21.7037 6.19305 21.8576 6.33667 21.9909C6.48029 22.114 6.64443 22.2166 6.82909 22.2987C7.02401 22.3705 7.22406 22.4064 7.42923 22.4064C7.81907 22.4064 8.15761 22.3192 8.44486 22.1448C8.74236 21.9602 9.01935 21.7242 9.27582 21.437L7.39846 19.1441ZM9.1681 15.3894C9.1681 15.1021 9.06551 14.8559 8.86034 14.6507C8.66542 14.4456 8.4346 14.343 8.16787 14.343C7.90114 14.343 7.67032 14.4353 7.4754 14.62C7.28048 14.7944 7.18302 15.0252 7.18302 15.3124C7.18302 15.6612 7.27535 15.9587 7.46001 16.205C7.64467 16.4512 7.83959 16.7025 8.04476 16.959C8.35253 16.7641 8.61413 16.5538 8.82956 16.3281C9.05525 16.1024 9.1681 15.7895 9.1681 15.3894Z" />
</svg>

You would export your SVG from Figma, then manually add the <style> and id, in VS Code.

Dark mode.
If we had a light mode.

And apple-touch-icon #

When the iPhone (with Mobile Safari) came on the scene in 2007, it added its own tag for webpage icons—now commonly known as touch or share icons—visible when adding pages to your home screen and in bookmarks, frequently-visited lists, and messages.

As everyone rushed to… respond to the iPhone, this syntax stuck and became the de facto standard—Android and Chrome use the same rel="apple-touch-icon" syntax, and for similar uses. In lieu of larger/specific images (more on that below), you should think of this as your default share image.

Safari bookmarks/favorites.

This should be an opaque (no transparency) PNG, at around 512×512px. Again, add it in your <head>, below the others:

		<head>
	<title>Typography and Interaction</title>
	<link href="assets/favicon.ico" rel="icon" sizes="any">
	<link href="assets/favicon.svg" rel="icon" type="image/svg+xml">
	<link href="assets/touch.png"  rel="apple-touch-icon">
	<!-- The rest of your head… -->
</head>

Open Graph, Structured Data, Metadata #

As sharing contexts became more and more prevalent, other approaches were developed to add additional information around pages in these scenarios—using special <meta> tags in the <head>.

Here, (ironically, pre-Meta) Facebook led the charge—what the iPhone was for the mobile web, Facebook was for sharing. They developed the Open Graph protocol, which became the standard and is used now in many (usually, non-Facebook) contexts. (Graph here is used with the maths meaning.)

This type of added info, broadly, can be referred to as structured data or metadata—hence Facebook’s name change!

Image #

So beyond your favicon and touch images, you can also specify an og:image (OG for… Open Graph) in your <head>. This is often used for more page-specific images: the main photo for a news article, the product shot in e-commerce, and so on. These are generally made visible when sharing a link on Facebook, LinkedIn, Slack, Messages, etc.—where these sites/apps generate a share card or preview (also sometimes called an unfurl) for the URL.

Slack shows the whole image.
LinkedIn crops in to ~16:9.

These can now be JPG s (for more photographic content), or PNGs (again, opaque). Tradition (inertia) suggests Facebook’s original 1200x630px dimension—but every context/app handles these differently. A better, modern rule-of-thumb is an image around 1200px on the long edge, at its original/best aspect-ratio. I might even do 2000px, these (HiDPI) days!

These are again specified in your <head>, now with <meta> elements—importantly, with the full, absolute URL for the file:

		<head>
	<title>Week 22</title>
	<link href="assets/favicon.ico" rel="icon" sizes="any">
	<link href="assets/favicon.svg" rel="icon" type="image/svg+xml">
	<link href="assets/touch.png"  rel="apple-touch-icon">
	<meta content="https://typography-interaction-2425.github.io/assets/meta.png" property="og:image">
	<meta content="Black background with white, modernist text of the site title." property="og:image:alt" >
	<!-- The rest of your head… -->
</head>

Note these allow an alt text for accessibility, in a separate tag.

Title and Description #

Open Graph also specifies og:title and og:description properties. However, we already have a <title> element—and there was an existing convention around descriptions—which browsers, apps, and search engines continue to use.

So we think including redundant og: versions for title/description is often unnecessary. (SEO/snake-oil folks might disagree.) If you are worried—or your boss tells you to—you could duplicate the tags. One reason might be to tailor different content (like your description length), for different platforms. But we don’t think it is worth it, most of the time.

Again, different apps are going to display and use this information in their own way—so there are no hard rules on length, and you’ll want to check the contexts you care about. Generally, tweet (toot?) length works well—so somewhere around 140 characters. And titles and descriptions should always be plain text—no HTML. You can usually use entities or encoded non-breaking spaces, though!

We’ll add in a description, to our <head> stack:

		<head>
	<title>Typography & Interaction</title>
	<meta property="description" content="Typography & Interaction is a year-long, two-semester course in the MPS Communication Design program at Parsons / The New School. The class will provide a rigorous foundation of typographic and interaction principles in the context of digital design.">
	<link href="assets/favicon.ico" rel="icon" sizes="any">
	<link href="assets/favicon.svg" rel="icon" type="image/svg+xml">
	<link href="assets/touch.png"  rel="apple-touch-icon">
	<!-- The rest of your head… -->
</head>

Audio and Video #

Some sharing contexts even let you play audio or video directly, in situ, from a share card. This might be useful for sites oriented around media, like Spotify or YouTube—but keep in mind the user is then not visiting the pages themselves, which you might prefer.

These are specified much like images, with the og:audio and og:video properties. There are extra metadata properties associated with the different types.

Conceptually, do you want your shared URL to function only as a link? Or somewhat as the thing itself?

Messages allows inline media.

Schema and Web App Manifests #

Beyond this, there is a (very, very) long tail of metadata/structured-data uses. Much of it will depend on the nature of your project/work, and there will be sub-conventions within conventions.

After Open Graph, the most common structures you might encounter next are probably Schema.org, oriented around search engine (Google) snippets—and Web app manifests (manifest.json), used by progressive web apps. Whether these are necessary will depend on your project!

Other Things for Your <head> #

charset #

This usually isn’t explicitly needed these days—because browsers assume/default to it—but you might have seen it in our examples and on other sites:

		<head>
	<meta charset="utf-8">
	<!-- The rest of your head… -->
</head>

This specifies your document’s character encoding as UTF-8, a superset of basic ASCII. Long story (very) short—this allows you to use encoded non-latin characters (and emoji 👋) directly in your HTML! To be thorough/explicit (or if you are seeing weird character junk), you can include this tag.

theme-color #

Finally, another recent <head> quirk: you can specify a theme-color, which is used by (some) browsers to tint/color their own UI around/outside of the page:

		<head>
	<meta content="#fcbf04" name="theme-color">
	<!-- The rest of your head… -->
</head>

This changes with pretty much every  OS release—but as of writing, usually only shows up on Mobile Safari and Mobile Chrome. (Desktop Safari default settings have it turned off; Desktop Chrome has never shown it.)

Safari tries to infer this color from your <body> background (and choses a contrasting UI text color)—but with complicated pages it might guess these wrong. You might also just want to adjust it, based on your design.

Safari correctly guessed black for us.
But maybe we want an accent color up there!