DEV Community: Abi Raja

Inside the head of an HTML document

Abi Raja — Tue, 03 May 2022 01:13:06 +0000

In a HTML document, the <head> is the place where you put everything that's not content. This is where you tell the browser how to render your page and what other files like CSS or JS or fonts to download. It's also where you tell a search bot or a social media website like Facebook or Twitter about your website.

Let's walk through one by one all the things you should include in your <head>.

Browser Directives

First up is <meta charset="utf-8" /> . It directs the browser to treat all your HTML content as UTF-8 and not ASCII or some character encoding such as ISO-8859-1. I don't think this is strictly necessary if you already have <!DOCTYPE html> at the top of the file specifying that this document is an HTML5 document. HTML5 only supports UTF-8. And even if you remove the doctype and include <meta charset="ISO-8859-1" /> , Chrome still treats it as UTF-8 but other browsers might not leading to potentially unpredictable behavior. So, the consensus is that you should always include this tag.

A mobile-optimized website should include:

<meta name="viewport" content="width=device-width, initial-scale=1" />

Without this tag, the mobile browser might render the page at desktop width say 1200px and then, scale the page down to fit the actual width of the device likely something much smaller like 390px. It will end up looking super zoomed out. With this tag however, things work as expected. The media query breakpoints you've set for lower widths will return true and the page will render as you intend it to on a smaller device.

SEO

Then, we have <title> which controls the text in the tab bar of the browser. It's also very important for SEO. It ends up being the Google search result's title. For SEO reasons, it is recommended that it's as close to 60 characters as possible. It also ends up being the default name under which the bookmark gets saved as in a user's browser.

<meta name="description" content="..."> is important for SEO reasons as well. Recommend length is 155-160 characters.

I like to include <meta name="robots" content="follow, index" /> although the default behavior of most search engine bots is to follow links and index all pages so technically, it's optional but doesn't hurt to be explicit.

The canonical URL is really important for SEO reasons:

<link rel="canonical" href="https://yourwebsite.com/article-title" />

It lets the search engine know that canonical URL for the content on this page is the value specified using this tag. That way, I can syndicate this blogpost on dev.to and Medium but still have Google direct people to this page when my content ranks highly for a search keyword. So your actual website ends up getting the traffic rather than dev.to or Medium. Another reason this matters is that large-scale duplication can lower your search ranking. With canonical URLs, you are telling Google when something is a duplicate vs. not. Make sure you have consistent canonical URLs across your website: trailing slashes or not? www subdomain or not? HTTPS or not? (pick HTTPS).

What about the keywords tag, <meta name="keywords" content="seo, search engine optimization"/> ? I've seen a lot of websites use them but the consensus in the SEO community is:

For 99.9% of people, the meta keywords tag is useless, and filling it out is a waste of time. You should only use it if you have a particular reason to do so, like using it for an internal keyword tagging system or an internal site search.

Most search engines including the biggest one of them all, Google, disregard the tag.

For more SEO tweaks, I generate a free report here. It'll check many of the things described above. The Google Search Console is also very helpful.

Social Media

When a link gets shared on Twitter, this is how it looks:

The Open Graph meta tags are what the website uses to render this tile.

<meta property="og:title" content="Loops" />
<meta property="og:site_name" content="Loops" />
<meta property="og:url" content="https://loops.quest" />
<meta
  property="og:description"
  content="Analyze Solana transactions. Trace how NFTs and tokens move across multiple accounts."
/>
<meta property="og:type" content="website" />
<meta property="og:image" content="%PUBLIC_URL%/og-image.png" />

Title, site_name, URL and description pretty much just correspond to <title>, website domain or name, canonical URL, and <meta name="description">, respectively.

The type can be a few different types but typically it's either article for a blogpost or website for an app or an e-commerce website.

For the image, Facebook recommends: "1200x630 or larger is preferred (up to 5MB). Stay close to a 1.91:1 aspect ratio to avoid cropping.". But I've found that following the image guidelines is no substitute for actually testing the previews.

To test, I use ngrok to tunnel my local website to the public internet, and copy the URL into this tool to look at the previews across platforms.

Open Graph tags are used by most social platforms, including Twitter. However, for Twitter, you are able to specify Twitter-specific tags as well. Twitter will use title, description from the Open Graph tags so I don't bother re-specifying them. But there are some Twitter-specific tags worth including:

<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:site" content="@_abi_" />

Summary card with large image is likely what you want for articles and websites but if you have a video instead, you can specify player .

Twitter's image recommendation for the summary card with large image is slightly different from Facebook: "Images for this Card support an aspect ratio of 2:1 with minimum dimensions of 300x157 or maximum of 4096x4096 pixels. Images must be less than 5MB in size. JPG, PNG, WEBP and GIF formats are supported. Only the first frame of an animated GIF will be used. SVG is not supported."

However, since the aspect ratio is only slightly from Facebook, you can probably skip using a different image.

Besides the testing tool linked earlier, Facebook and Twitter offer their own tools as well: Facebook
and Twitter.

Others

The only remaining thing we must include is a bevy of favicons. Here's a great article by the author of PostCSS on what we need and why.

<link rel="icon" href="/favicon.ico" sizes="any" /><!-- 32×32 -->
<link rel="icon" href="/icon.svg" type="image/svg+xml" />
<link rel="apple-touch-icon" href="/apple-touch-icon.png" /><!-- 180×180 -->
<link rel="manifest" href="/manifest.webmanifest" />

And then in the manifest.webmanifest file,

{
  "icons": [
    { "src": "/icon-192.png", "type": "image/png", "sizes": "192x192" },
    { "src": "/icon-512.png", "type": "image/png", "sizes": "512x512" }
  ]
}

If your app is a progressive web app i.e. a website that can be installed to the home screen without using an App Store, you should fill out the manifest file with more detail.

What is Tailwind? And how to set it up properly.

Abi Raja — Wed, 02 Mar 2022 22:37:32 +0000

I've been using Tailwind for CSS in my projects lately. At first glance, Tailwind looks pretty ugly and hard to decipher. Just look at this.

It sure is ugly-looking but it works well! Drawing inspiration from Atomic CSS and utility classes (1 class = 1 style), Tailwind makes a few strong design decisions:

Markup and style should live next to each other (bye, bye stylesheets): This makes it easier to write and update components since you don't have to change two different files. Global CSS is also hard to maintain over time since a change in the global namespace could affect any number of things on your website.
Coming up with class names is a waste of time.
CSS is an expressive style language that maps directly to browser rendering models and so, there's no need to learn a new mental model for styling (which some other CSS frameworks force you to).

You might note that all of this is true for inline CSS as well! Why not just use regular CSS and just avoid using stylesheets?

<div style={{
   color: 'black',
   backgroundColor: 'white'
}}>

True. You do get these benefits with inline CSS. But Tailwind does better in a couple of ways:

With inline CSS, you can't have media queries or hover states. In Tailwind, you can do this via modifiers which you can add to any utility class: bg-sky-600 hover:bg-sky-700
Tailwind comes with a design system (colors, fonts, spacing, etc.). You can write stuff like m-2 (margin of 2 units) rather than specify exact pixels. As a result, across your website, spacing will be uniform, colors will come up from your theme and so on.

That's the essence of Tailwind. It's a very low-level CSS framework composed of a bunch of utility classes and a customizable design system.

How does Tailwind work?

Tailwind processes all of your code, looking at className properties in React components but not just that. In case you have some dynamically generated classes (const classes = disabled ? "color-gray-100" : "color-indigo-100" ), Tailwind will also look for utility classes in your JS. Once it parses all utility classes in the code, it generates the corresponding CSS and writes them to a file. I use it with React and it's supported with Create React App v5 and above.

If your framework doesn't support it (I had a hard time getting it working in CRA v4), you can always use the CLI to watch and generate the CSS file. You'll specify the directory to be watched. And you'll have to load the output CSS file in your HTML. Good setup and troubleshooting tips here.

Editor Setup

VS code support via the official Tailwind plugin makes Tailwind very pleasant to write and less ugly to read. The plugin offers autocomplete so you don't need to remember every utility class. It also lets you hover over utility classes to see the CSS they will generate.

You should definitely add the following to your VS Code settings for your Tailwind project:

"css.validate": false
"editor.quickSuggestions": {
   "strings": true
}

The second setting tells VS Code to autocomplete not just at the start of a string but also in the middle. Without this, you'll only get autocomplete for utility classes when your cursor is at the end of className=" but not when it's at the end of className="mx-4. That is, without this setting, you only get autocomplete for the first class in a list.

Now that we finally don't have to worry about naming classes, what else can we bike shed about? Well, the order of utility classes, of course. Fret not. The Tailwind just released a Prettier plugin last month to end these pointless debates. The Prettier plugin automatically sorts classes. And it's not configurable.

One annoyance with the plugin is that the features only work for values of className attributes.

My only other gripe is that the linting seems finicky.

Gotchas

From the docs, "the most important implication of how Tailwind extracts class names is that it will only find classes that exist as complete unbroken strings in your source files." If you have code like error ? 'text-red-600' : 'text-green-600', CSS will be generated for text-red-600 and text-green-600. But if you have text-{{ error ? 'red' : 'green' }}-600", your Tailwind-generated CSS file will in fact not contain any classes text-red-600 and text-green-600.

This stumped me for a bit. I didn't know this and I went about creating an invisible <div> that had all the classes that were being used with conditional logic. But if you use unbroken strings for all class names, that solves it.