Articles by

Chris Coyier

We don't generally think of CSS animations or transitions inside of email, or really any movement at all outside of an awkward occasional GIF. But there is really no reason you can't use them inside HTML emails, particularly if you do it in a progressive enhancement-friendly way. Like, you could style a link with a hover state and a shaking animation, but if the animation (or even the hover) doesn't work, it's still a functional link. Heck, you can use CSS grid in email, believe it or not.

Jason Rodriguez just wrote Understanding CSS Animations in Email: Transitions and Keyframe Animations that covers some of the possibilities. On the supported list of email clients that support CSS transitions and keyframe animations is Apple Mail, Outlook, and AOL mail, among others.

Other things to look at:

• Email on Acid: The Ultimate Email CSS Animation Guide
• FreshInbox: Kinetic Email CSS Support
• Campaign Monitor: The Ultimate Guide to CSS (animation)
• The incredible trickery of camiah

The subject of scaling CSS came up a lot in a recent ShopTalk Show with Ben Frain. Ben has put a lot of thought into the subject, even writing a complete book on it, Enduring CSS, which is centered around a whole ECSS methodology.

He talked about how there are essentially two solutions for styling at scale:

1. Total isolation
2. Total abstraction

(more…)

Like Eric Bailey says, if it's interactive, it needs a focus style. Perhaps your best bet? Don't remove the dang outlines that focusable elements have by default. If you're going to rock a button { outline: 0; }, for example, then you'd better do a button:focus { /* something else very obvious visually */ }. I handled a ticket just today where a missing focus style was harming a user who relies on visual focus styles to navigate the web.

But those focus styles are most useful when tabbing or otherwise navigating with a keyboard, and less so when they are triggered by a mouse click. Now we've got :focus-visible! Nelo writes:

TLDR; :focus-visible is the keyboard-only version of :focus.

Also, the W3C proposal mentions that :focus-visible should be preferred over :focus except on elements that expect a keyboard input (e.g. text field, contenteditable).

(more…)

A common need when writing vanilla JavaScript is to find a selection of elements in the DOM and loop over them. For example, finding instances of a button and attaching a click handler to them.

const buttons = document.querySelectorAll(".js-do-thing");
// There could be any number of these! 
// I need to loop over them and attach a click handler.

There are SO MANY ways to go about it. Let's go through them.

(more…)

This resonated with me:

It’s ironic to me that the numeronym “a11y” lacks accessibility: it’s not immediately decipherable by humans who aren’t “in the club”; and, in some fonts, it’s visually indistinguishable from the word “ally” (with lowercase L’s), which can foil searches for clarity.

— Eric Meyer (@meyerweb) November 5, 2018

Because I bet it took me a year after seeing that acronym ("numeronym", I guess) for the first time to know that was just a stand-in for the word "accessibility". I'm only now just understanding that "i18n" means "Internationalization" and "l10n" means "Localization". I wonder how many conversations or articles I've missed because I just assumed the weird moniker was referring to something that had nothing to do with me. On the flip side, I wonder what good has come from having these cool words form a banner to rally under.

Lots of good conversation in that thread. I don't know enough to have an opinion about whether anyone else should or shouldn't use it, but remembering my own confusion, I think I'll avoid it around here.

In the grand tradition of every single poll question I've ever posted, the poll below has a has a fundamental flaw. In this case, there is no option between "In the last month" and "Never" but, alas, the results are interesting:

When's the last time you SFTP'd (or the equiv) into a server and changed a file directly?

— Chris Coyier (@chriscoyier) October 9, 2018

(more…)

One thing JavaScript template literals are great at is little blocks of HTML. Like:

// Probably from some API or whatever
const data = {
  title: "Title",
  content: "Content"
};

const some_html = `
  <div class="module">
    <h2>${data.title}</h2>
    <p>${data.content}</p>
  </div>
`;

But that's still just a string. It's not ready to append to the DOM just yet. And what if we need references to those elements inside somehow?

(more…)