DEV Community: Ovi Demetrian Jr

Barebones metadata for page sharing

Ovi Demetrian Jr — Tue, 14 Oct 2025 00:56:09 +0000

Metadata for when a page is shared has become the most relevant when it comes to setting up meta tags for your page as it allows controlling how social media platforms output a link to your page. Along with texting and chat apps, project management tools, and more. Here are the basics that should apply for all of them.

Let’s start with the classic page tags that are used:

title tag - page title, used as a default for any platform/app
description - as part of default preview text
canonical - full URL with no extra variables like campaign referrer info

Open graph tags have become the standard for sharing links. These are the tags mainly used:

og:title - if you want to show as an override for your title tag
og:description - an override for your description tag
og:url - override for canonical tag
og:image - the preview thumbnail image

Note that you don't need to include og:title, og:description, or og:url tags if you want to just use the content from the classic page tags.

And these are the guidelines for the preview thumbnail:

1200x630 pixels is the standard image size
Images can get scaled and cropped depending on the platform/app
JPEG, GIF, or PNG formats, with WEBP starting to get supported
Image file size shouldn’t exceed 5MB

Here's a working example along with additional options of what you can do.

Modern form validation

Ovi Demetrian Jr — Mon, 12 May 2025 19:16:00 +0000

Now that browsers have form validation built-in, we can better use related form field CSS properties to improve the user experience. Add the more modern has() CSS property to the mix and you can replace techniques that previously required Javascript with just a few lines of CSS code.

Add an asterisk to required fields

Using an asterisk next to a form field label is a common way to indicate that the field is required. But instead of adding it manually, it would make more sense to show the asterisk automatically based on whether the field itself is actually required. Here's how to do just that:

form div:has(label + *:required) label::after, form fieldset:has(*:required + label) legend::after {
  content: "*";
}

A container is needed for each field and its corresponding label. For radio buttons and checkboxes, using fieldset acts as the container, and the field legend is used instead of label.

Highlight invalid fields

While the browser will prompt users if a required field is not filled out, or is filled out incorrectly, it does this only after the form is submitted. With the CSS below, this can be done on each text field, as the user is entering in their details.

form input:focus:invalid, form textarea:focus:invalid, form select:focus:invalid {
  border-color: #b91616;
  background-color: #f1e5e5;
}

The field textbox or dropdown is shown with a dark red border and light red background when the user clicks into a field and the field doesn't meet the required criteria. It also works for field types like email that need a specific format for its contents. You can go further and use :focus:valid to indicate when a field does meet its requirements.

Change submit button state
As further indication of the state of form fields, you can change the submit button to make it look like it's disabled until all required fields are filled out, and are valid:

form:has(*:invalid) input[type="submit"] {
  background-color: #aaa;

  &:hover {
    background-color: #aaa;
  }
}

This does not actually disable the button, it only changes its appearance. It still functions as a way to notify the user of which fields are missing information.

To see working examples of these techniques, along with other form field formatting options, check out our free Starter theme.

Modern email design for web designers

Ovi Demetrian Jr — Tue, 02 Apr 2024 18:43:03 +0000

Looking at most email code, you’ll find that it’s difficult to read at first glance. CSS is used primarily inline. And the worst part of it, tables are used for layout. This is because of Outlook for Windows, the Microsoft Internet Explorer of the email world. It also makes other things difficult, like using background images.

A more modern approach

However, Microsoft has announced this past year that it is finally replacing its Outlook for Windows rendering engine. Even though the transition may take a while, the percentage of Outlook for Windows users is already pretty low. It's only Outlook specifically on Windows that's the issue, on other platforms it uses newer rendering engines.

So at this point, it’s pretty safe to move away from supporting it. Plus you can do what people did during the Internet Explorer days: put up a note that’s only shown in Outlook for Windows to let your readers know to upgrade their email client. You can even include a link to a hosted version of your email that your readers can go to for proper rendering.

<!--[if mso]>
  <p style="text-align: center;">Email may not look quite right in Outlook for Windows. <a href="#" style="text-decoration: underline; color: #1467ac;">View it in your browser.</a></p>
<![endif]-->

Coding and testing

With Outlook for Windows set aside, you can use div’s for layout the way you would for a website. And you can put all your CSS in the header of your HTML instead of inline within your HTML elements. You still can't use external CSS though. And no Javascript either.

Testing the rendering of your email also gets easier. Before, you would have to use specialized tools to test for various old versions of Outlook for Windows. Now, you can just sign up for an Outlook.com account since it's eventually what will be used across the board for all Outlook apps.

Another client to test for is Google Mail, which can be done with a Gmail.com account. And Apple Mail, on any Apple device. Apple Mail provides the best email rendering so you don't even really need to worry about it much if you're covering the other two. But these three make up the main ones you should test for. And for checking compatibility of specific code, caniemail.com is an essential tool to use.

If you'd like to see some example code that shows the difference between code that supports Outlook for Windows and more modern code, I use a boilerplate email template that comes in different versions. And the latest email template I worked on for Indie Aisle, is a fully modern example.

How I organize my CSS

Ovi Demetrian Jr — Mon, 19 Feb 2024 01:24:00 +0000

There is now browser support across the board (for more recent versions), for both CSS nesting, and using variables. Both of these allow for a better way to structure your CSS and keep it more manageable while making changes to it.

Excited about the nesting support, I decided to refactor the CSS for a couple of the sites I make updates to regularly: the one you're reading this from, and the promo site for Blocks Edit.

Breaking things down and categorizing

I use a global CSS file for a website with separate files for website sections that have considerable additions, like a blog. Those added CSS files are called in only on those sections. I often consider the homepage as its own section, along with certain landing pages that have a good amount of design elements that are specific to it.

These are the general categories I break my CSS code down in:

Global - variables, any needed resets, and body options
Text formatting - including for titles, and link properties
Layout - container and CSS grid layout setup for columns
Utilities - design patterns, like image and video formatting, buttons, forms, notices, share links, code example formatting, etc
Header and footer - along with their navigation I will also have an area in the global CSS file that has the styling for secondary pages that its used on a lot.

Additional details

One thing to consider with nested CSS is not overusing it, leaning towards a flatter structure, allowing elements to be more modular on their own.

Besides nesting my elements and classes, the biggest noticeable change I made along the way was putting @media declarations for both mobile and dark mode within individual elements instead of separating them into their own mobile and dark mode categories (which is why they're not on the list above).

Global variables I mainly use for the site's standard colors and fonts. If I need to use them at any point, referencing the variables makes it easier than searching for the correct values every time.

Keeping track of what CSS is being used (and where) and what isn’t can be tricky but I’ve found that the above format helps with this. When I make an update to a page, if I end up changing its design considerably, I end up first going to its section CSS where I can either modify currently used CSS, or remove it if I’m no longer using it.

For examples of this approach, here is the global CSS for this site. And the global CSS for the Blocks Edit website.

I've also been working on a boilerplate template that's on GitHub that you can refer to which follows the methods above as well.

Sharing options without platforms

Ovi Demetrian Jr — Thu, 16 Nov 2023 18:24:00 +0000

Instead of trying to account for all available options, we should now go with two universal sharing options: “Copy link” and “Send email”.

“Copy link”, would work as a convenient way to copy the current page URL to the visitor’s clipboard. Here is Javascript code that will do that:

async function copyShareLink() {
  let text = window.location.href;

  await navigator.clipboard.writeText(text);
  document.querySelector('#share-link').innerText = "Copied";

  setTimeout(() => {
    document.querySelector('#share-link').innerText = "Copy Link";
  }, 1000);
}

With the HTML that triggers it:

<a onclick="copyShareLink();" id="share-link">Copy Link</a>

And the CSS to make it feel like a link:

#share-link:hover {
  cursor: pointer;
}

“Send email”, uses the oldest standard for sharing a web page, email, which is still commonly used today, and is guaranteed to still be used in the future! You can set it up to launch the visitor’s email app with a new email draft.

Here's HTML + Javascript code that fills out the subject line with the page's title, and in the message includes the URL and the page's meta description, if available:

<a href="javascript:window.open('mailto:?subject='+document.title+'&body='+encodeURIComponent(document.querySelector('meta[name=description]').content)+'%20'+encodeURIComponent(window.location.href));">Send Email</a>

You can see an example of the working code for both of these options at the end of this article's page.

Levels of email dark mode

Ovi Demetrian Jr — Wed, 24 May 2023 21:17:36 +0000

Setting up your email’s design for dark mode isn’t really a choice since some email clients will do it anyway. This includes Gmail and Outlook which will invert background colors and text. This leads to potential accessibility issues that make your designs hard to read, or in some cases, completely unreadable.

Forced dark mode

So you’ll have to adapt to the way email clients treat your design for dark mode. The way to do this is to first test your email template in the email clients that will force color changes for your design. The email clients to look out for are:

Outlook 2021, Office 365, and Windows Mail, on Windows - all do a full invert of colors across the board
Outlook.com, on Windows (across all browsers) - will invert some colors, but doesn’t always invert all background colors or text of certain elements, like buttons
Gmail app, on iOS - also does a full color invert
Gmail app, Android - partially inverts colors, similar to Outlook.com

Use Email on Acid or Litmus to get a range of test environments to look at.

Making adjustments

You can adjust some aspects of your design where necessary to account for the changes. Make sure your logo and transparent graphics look good on a darker background. Consider adding an outline around your logo to ensure it’s readable. Avoid text over background images since images don’t get inverted, but the text will.

For Outlook.com, attributes are added to elements that change colors. So you can refer to those attributes and overwrite their changes by including classes in your HTML and then targeting them in your <style>:

For text color:

[data-ogsc] .classname { }

For background color:

[data-ogsb] .classname { }

Unfortunately, there are no other standard methods for adjusting colors for the rest of email clients that force dark mode.

Optional dark mode

Email clients that don’t force dark mode will allow you to set your own dark mode color scheme by having you use a media query in your <style> to specify what you want elements to look like:

@media (prefers-color-scheme: dark) { }

A meta tag is required for some email clients:

meta name="color-scheme" content="light dark">

Along with CSS definitions as well:

:root {
  color-scheme: light dark;
}

For an example of a full template using dark mode, take a look at the Starter template.

Getting your email layout to automatically adjust for mobile screen sizes

Ovi Demetrian Jr — Wed, 17 May 2023 20:01:43 +0000

Adjusting your email for mobile doesn't have to be difficult. It comes down to using columns as a standard layout practice. The columns can then be resized and stacked for mobile screen sizes.

Here's an example of what to add to your columns to do this, with CSS code that acts globally across your template.

View HTML/CSS code

No more tables for email

Ovi Demetrian Jr — Thu, 17 Nov 2022 18:51:35 +0000

Table layouts in email lead to a number of rendering and accessibility issues, so the less we use them the better. Outlook for Windows is the only reason we even need to use tables anymore and it's now at just around five percent of email clients used.

So here’s an approach to not having to use tables for structure that's worth considering: use divs for structure only, and don’t do anything for Outlook, letting multi-column div layouts turn into single-column layouts in Outlook. Essentially making the Outlook version look similar to what you might do for a mobile version of a design.

More details on the approach

Coding your emails for Outlook

Ovi Demetrian Jr — Thu, 23 Jun 2022 19:27:28 +0000

Making your email design work for Microsoft Outlook can be a challenge. Here's an approach to take to still support unfortunate email users that use it while keeping your sanity!

Use clean, accessible code first, Outlook code second
Avoid tables and use ghost tables only when needed for Outlook
Use both image width and height properties for Outlook
Use VML method for background images

View code examples

The modular design method

Ovi Demetrian Jr — Tue, 11 Jan 2022 19:43:46 +0000

Modular design is a method for improving design and production workflows by using components-based design and layout patterns that overlap structural coding practices. This design approach breaks apart content and design elements and puts them back together based on these guidelines:

Content - text pieces and images
Components - reusable, standalone elements like buttons and titles, the building blocks of your content
Regions - groups of content content pieces and components, arranged in a very specific way
Sections - stackable containers of regions between the header and footer to create an overall layout

View the paper on GitHub

Simple guide to accessibility in email design

Ovi Demetrian Jr — Wed, 30 Sep 2020 18:14:03 +0000

The basics:

Make your design easy to read
Use alt tags and descriptions for images
Set a presentation role on tables used for design
Use headers for titles
Use p tag for paragraph text
Make sure the lang attribute is set
Encode any special characters

Read the short design and coding guide

A template for building a design system for your email's content production

Ovi Demetrian Jr — Wed, 19 Aug 2020 17:28:30 +0000

Using a design system helps your team follow branding and design guidelines and more efficiently produce emails. The Starter Email Design System is a template you can use as a starting point for your organization's email design system.