HTML table elements have been around for a long time and have universal support in web browsers, and in most email client rendering engines. These extremely old clients are often not updated to support recent properties and attributes. Do you have a customer running AOL mail or Yahoo mail? Well good luck attempting to make your email work on those clients without using this website. This is extremely useful for older clients. When working on email templates I often spend my time looking at which provides a good overview of whether an attribute or a CSS property is actually supported on specific email clients. `position: sticky` has to be `position: webkit-sticky`. Anyone who’s ever written any CSS can tell you that WebKit is even more of a pain, often requiring special CSS properties which only work on WebKit e.g. You want to add a border-radius, use a background image? Well you’d better check that it’s supported on the rendering engine for the clients your users are receiving their emails in.Īpple Mail on both mobile and desktop uses Safari’s WebKit engine. This presents you a problem as a developer. Outlook renders using the Microsoft Word templating engine whilst Gmail and Apple use their own.
You’d imagine that they’d all support the same attributes and CSS properties right? Well… no that’s far from the truth. The three most common email clients are Gmail, Outlook and Apple Mail. The fragmentation of rendering engines presents a massive challenge when attempting to make emails compatible with various email clients. Rendering engines are what take the HTML you’ve written and lay it out onto the screen for users to see. You may be thinking, why then do we use tables to construct emails when the rest of the web has moved on so much? The big issue here is that nearly every single email client uses a different rendering engine. Emails however are largely still stuck using HTML tables for their layout.
Bootstrap, which allow us more control over the layout of our pages. It used to be that all webpages were built in this way but web page layout has since moved on to Flexbox, CSS Grid and other layout libraries e.g. The default way of writing email templates is with HTML tables. In the post we’ll talk about the steps I took to understand the existing problems with how we built our email templates at WeGift, the issues behind email clients and how we eventually settled on a solution to improve the process of generating email templates. However, the more we have customised our emails, the more the engineering experience has become painful, especially as the number of emails we send has grown and they’ve needed to work on a wider range of devices. For example, your latest invoice has been generated or you’ve been granted access to a new product.Īll of these emails contain critical information and we’ve attempted to present them in a design which is in keeping with our brand. At WeGift we use emails to communicate with our customers about changes on our platform.
0 kommentar(er)
