From the blog

✻ Chris wrote about a tool designed to help write HTML emails. Inky is a templating language that cleans up the trouble of writing hand-coded emails:

I’m sure a lot of us have hand-coded HTML emails (I do it regularly) and know that it’s typically `table` soup. It’s not even just the tables that are annoying, but the fact that there are so many of them nested to do even fairly simple things it’s hard to keep straight.

Below you can see the Inky code we need to write and how that compiles into the HTML we need for an email:

Slinky is essentially a Pen on CodePen that allows you to use the Inky templating language and simply click a button to get the HTML source you can copy-and-paste to actually send.

✻ For the MediaTemple blog, Chris looks at publishing CSS-Tricks across platforms such as Apple News, Facebook’s Instant Articles and Google’s AMP.

✻ Guest writer Erez Elias describes how to move a WordPress site, along with its database and files:

One big source of frustration I’ve seen from WordPress users comes when they want to move their WordPress site. As in, move the entire website from one hosting company to another hosting company. In this article I will walk you through 4 simple steps of moving a WordPress website to a new hosting.

✻ Chris jotted down some of his thoughts about Reframe.js, a script that helps preserve intrinsic ratios for iframes, canvas and object elements, whilst comparing it to FitVids.js. Chris writes:

Reframe.js is kind of a modernized version of FitVids.
  • It's bower and npm friendly.
  • You can require it.
  • It doesn't need jQuery.


✻ Sarah Drasner and Val Head are starting an excellent two day workshop on web animation that starts this November in New York and Austin. Sarah describes the events like so:

Val and I both have been speaking and giving workshops around the world, and together we make a venn diagram of strength and knowledge about how to animate on the web. We’ll be covering everything from theory, to technique, to bug fixes and cross-browser stability

What have you learnt this week?
Chris Coyier: We have quite a bit of stuff on CSS-Tricks about SMIL.  It's a pretty neat declarative syntax for animations and interactivity built into SVG. Sara Soueidan even wrote a wonderful comprehensive guide to SMIL animation for us.

The refrain changed around SMIL when Blink decided to deprecate SMIL. They went as far as showing warning messages in the console and implementing features (like motion-path) intended to be native alternatives to SMIL features. Microsoft never supported SMIL and the word was they didn't intend to. The refrain became: "Don't use this. It's not universally supported and support is about to get much worse."

Then there were murmurs that Microsoft might start supporting SMIL, presumably for the interoperability good of the web. Then Blink slowed their roll on deprecating SMIL. They say they are going to hang onto it for a while, until replacement tech was more complete. I think the developers bemoaning its loss were loud enough. 

Now things are even more complicated.
  • As makers, should we count on being able to use SMIL or not? 
  • As teachers, should we teach SMIL or not?
  • Should Microsoft spend time on SMIL or not?
  • Should all browser makers prioritize other animation API work or not?
We should never take the deprecation of a web feature lightly. Whatever success the web may have, some of it is surely due to its forgiving nature. Very old websites still work largely as they were created. Yet, the deprecation of SMIL did make the future more clear, not to mention incentivize the pushing forward of more modern web animation API stuff.

If it became law that cars could not be sold that ran on 100% gasoline, you'd think car technology would be push forward much more quickly.


What we’ve been reading, listening and watching

53% of mobile users abandon sites that take longer than 3 seconds to load, according to Google.

✻ ✻ ✻

Jon Yablonski has made a handy tool for designers that helps them tick-off important performance tasks that need to be performed. It’s called the Designer’s Web Performance Checklist.

✻ ✻ ✻
A while ago, Digital Ocean was redesigned and now the team has written about how they made the site faster, more accessible and easier for designers to work with, too. 

People have been raving about the new look on as well!
✻ ✻ ✻
Alex Russell describes What, Exactly, Makes Something A Progressive Web App:

To be a Progressive Web App, a site must:

  • Originate from a Secure Origin. Served over TLS and green padlock displays (no active mixed content).
  • Load while offline (even if only a custom offline page). By implication, this means that Progressive Web Apps require Service Workers.
  • Reference a Web App Manifest with at least the following properties:
    • name
    • short_name
    • start_url
    • display with a value of standalone or fullscreen
✻ ✻ ✻
Nicolás Bevacqua in Template Literals are Strictly Better Strings:

The majority of the community has implicitly agreed on using const as the default over var. The const statement makes your code more clear, by describing a read-only value at declaration time. It also makes it clear that the variable isn’t meant to be used before its declaration, avoiding silly mistakes that could occur when using var. For these reasons, const also improves interaction with static analysis tools such as eslint.

This article explores how template literals are strictly better than strings, and how they too should become the new default of a post-ES6 era – over single and double quoted strings.

Until next time!
Team CSS-Tricks
Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list