Mosaico.io News and Blog

Samsung Email Autowidth feature breaks responsivity. Here is a workaround!

Mon, 03 Jul 2023 01:00:00 +0000

Have you ever created a responsive email using media queries to optimize it for smartphones, only to find that Samsung Email breaks the layout by using an excessively wide viewport? Even if your media queries are correctly interpreted and applied, texts become unreadable due to the wide rendering. We reported it as versafix template issue #37.

The bug was initially reported four years ago to the HTeuMeuLeu repository by Mark Robbins. Several workarounds were proposed, but none of them resolved the issue with our template.

In an attempt to address the problem, we ~~reverse engineered~~ made a lot of guessing about Samsung Email “Autofit” feature to understand why it was causing our autofitting email to display improperly.

Through testing, we discovered that the issue arose when the email’s HTML contained large elements with extensive “width” attributes or width properties in element styles. Notably, elements hidden with “display: none” did not trigger the issue. What occurred was that Samsung Email identified the largest width in the HTML code and adjusted the viewport width accordingly, resulting in a zoomed-out version of the email. Most responsive emails use desktop widths in their HTML code, making only mobile-first templates immune to this Samsung bug. It’s surprising that no effective workaround has been proposed in four years and that Samsung has yet to address the issue.

Upon examining the JavaScript code used in the WebView for rendering emails, we encountered something peculiar in the Autofit.js file:

AutoFit.onLoad = function(loadCallback, removeHeight100InStyleCallback, getViewportCallback, IsPLMContent, fontSize) {

  [...]
  
  baseViewportWidth = getViewportCallback();

  var children = orignalDiv.children;
  removeHeight100InStyle(removeHeight100InStyleCallback);
  var originMaxWidth = removeHeight100InNode(children);

  [...]
  
	var orignalWidth = orignalDiv.style.width;
	if (orignalDiv.getAttribute(SET_WIDTH_ATTR)) {
		newWidth = orignalDiv.style.width;
		width = secDivWidth = parseInt(newWidth);
	} else {
      MAX_WIDTH = Math.max(orignalBody.offsetWidth,orignalDiv.scrollWidth);
	    if (MAX_WIDTH <= baseViewportWidth) {
	        //checkMaxWidth(orignalDiv.children);
	        MAX_WIDTH = Math.max(MAX_WIDTH,originMaxWidth);
	    }

		newWidth = Math.max(MAX_WIDTH, baseViewportWidth) + "px";
		orignalDiv.style.width = orignalDiv.scrollWidth = newWidth;
		width = secDivWidth = parseInt(newWidth);

		orignalDiv.setAttribute(SET_WIDTH_ATTR, 1);
	}
 
  [...]

The function removeHeight100InNode returns the largest element width, and this value is stored in “originMaxWidth.” Later in the code, “originMaxWidth” is used as the new viewport width before the final rendering.

Based on the conditions, it seems that Samsung Email initially renders the email using a narrow viewport. If the rendered email does not overflow, it then applies the aforementioned logic. This behavior is contrary to expectations, as one would assume that if the email does not fit the mobile viewport, it should be left as is, while only those that fit would be autofitted. This sounds like the opposite of what some autofit code should do.

However, armed with this knowledge, we were able to identify a potential workaround. We discovered that adding a fixed-width element with a width of 430px to our email improved the rendering. This adjustment caused the email to be displayed as mobile on a 450px viewport, rather than the default 600px viewport used without the fixed element.

After extensive trial and error, we arrived at a generic solution specifically targeting Samsung Email:

  @media screen and (max-width: 384px) {
    .mail-message-content {
      width: 414px !important;
    }
  }

Interestingly, this media query only matches during the initial rendering evaluation by the app. Subsequently, the email is rendered in a viewport of approximately 420px (estimated) because it doesn’t fit the mobile viewport. With the new viewport size, the media query no longer matches.

We tested this fix on several Samsung devices, including the S8, S10e, S22, S20 Plus, S23 Ultra, and a few Notes. The solution appeared to work consistently across devices, regardless of their native virtual viewport sizes. Please let us know if this workaround resolves the issue for you as well!

Mosaico 0.17.3 release

Mon, 26 Mar 2018 14:00:00 +0000

It’s been a while since our previous release but it turned out Mosaico is pretty stable/solid and easy to extend via plugins!

On the other side it took 4 iterations to have our first 0.17.x stable release, namely the 0.17.3, because of unexpected issues with the newer version of our dependency TinyMCE and because of bugs in Safari rendering engine (WebKit).

Let’s see the changes…

Final User changes/improvements

Updated versafix-1 to 1.1.16 with new blocks and new formatting options: see release notes
Added image tool on “editable images” that by default opens the gallery (overridable via viewModel plugin)
New outline on editable elements when hovering a block
Prevent editing contents while tinymce is being loaded (fading effect)
Use inline-block with a min-width for inline editables + hacks to prevent element collapsing

Developers/Integrators changes:

Added Russian, Serbian and Portuguese language packs
Added decodeURI, encodeURI, decodeURIComponent and encodeURIComponent to functions available to template authors.
Compatibility with jQuery up to latest 3.3 (using jQuery-Migrate), we suggest upgrading to jQuery 3.3, Knockout 3.4.2, TinyMCE 4.5.x (MAY work with 4.6.x, still have ISSUES with 4.7.x)
Major build refactoring to remove bower and improve build reproducibility over time when using npm v5 (previous releases are not anymore buildable because of bower and no package.lock mechanisms in older npm).
A bunch of minor bug fixes

Go, check out Mosaico 0.17.3 and join the community!

Yandex.com removes full style attribute on unexpected contents

Mon, 19 Mar 2018 14:00:00 +0000

We’ve had reports that our latest versafix-1 template (1.1.16) shows its mobile version on Yandex webmail even on desktop.

After some investigation we found that Yandex is stripping whole style attributes when the style contains something unexpected.

We did some search to find existing informations about Yandex issues, but found nothing relevant, so we decided to dig into it and document the behaviour.

What we found

Yandex.com webmail usually removes a properties if it doesn’t know it or doesn’t understand the property value, but it sometimes remove the whole style! We found that the full style attribute removal happens in a couple of cases:

When there are round brackets in a property value and you have some symbols in the content, like ‘_’, ‘-‘, ‘+’, ‘*’, ‘&’
On every property value if a sequence “- “ is found or a “NUMBER-“ or “-NUMBER” is found.

An example

Let’s see an example code:

<div style="color: red; -unknown-prop: value">A</div>
<div style="color: red; -unknown-prop: value - 2">B</div>
<div style="color: red; -unknown-prop: -5something">C</div>
<div style="color: red; -unknown-prop: something(in brackets)">D</div>
<div style="color: red; -unknown-prop: something(in - brackets)">E</div>

is cleaned up by Yandex to this:

<div style="color:red;">A</div>
<div>B</div>
<div>C</div>
<div style="color:red;">D</div>
<div>E</div>

Yandex is removing also the properties he understands like “color: red” when the style contains something he doesn’t like.

No Fab4, then?

So, this issue makes the Fab4 technique ineffective without additional hacks.

We documented the bug in the versafix-1 repository. We’ll try some additional hack to see if we can get the desktop version on Yandex even if partially using the Fab4 approach.

Unfortunately we’re not aware of known hacks to target Yandex.com webmail so to put some specific workaround in place, so we’ll need a generic solution and something that doesn’t break any other email client.

Did you experience this bug? How did you fix it? Do you have more details about the issue? Get in touch with us!

Introducing HTMML and icon generation tool to improve master templates maintenance

Fri, 02 Mar 2018 18:00:00 +0000

One of the strengths of Mosaico is its template-based approach. Most options Mosaico gives you when you edit a template are not hardcoded in the Mosaico Library. Instead, they are defined in the “master template”, by the template author.

A major design choice in the “template language” was that the template language is simply an extension to HTML, so that you can open a master template in your browser and see how it looks like, or you can edit it using your preferred html editor.

This is a major advantage when you have a master template with few options, but you’ll find repeating and copy and pasting a lot of html code if you want to create a full featured master template like our Versafix.

The repeating and copy and pasting tasks usually get you to more bugs, so while we updated our Versafix master template we decided to build a small generation tool to help with “deduplication” and maintenance.

HTMML, the Hyper Text META Markup Language

We tested a lot of existing templating tools, but in the end they were too complex or not flexible enough, so we ended up writing our own minimal markup language in only 300 lines of javascript code.

This allowed us to reduce our versafix HTML definition from 200KB to 50KB and use “cascading” to reduce code duplication. It’s like CSS but for HTML tags/attributes, instead of styles, plus the ability to define new tags.

The META Markup Language is very simple and fully documented in the project README

So HTMML let us generating the Mosaico template (including its own template language), but Mosaico will still use the same template language.

Versafix Template project

We prepared an upgrade from our hand-crafted Versafix 1.0.6 template to a new HTMML generated Versafix 1.1.16 and this also helped us identifying and fixing a few bugs in the versafix 1.0.6 template.

In a previous post we introduced the new Versafix master template and now we published the htmml sources we used to generate it

Automatically generating icons

We also found that generating multiple variations of multiple social icons by manually working with image editing tools and dozens of layers took a lot of time and was error prone, so we also created and opensourced a script that help us automatically generating all of the social icons (70!) that are used by the new Versafix template.

If you want to add new social networks you can simply create a 512px square Black on White icon, add its name and brand color inside the small generation script (iconsDef array) and it will automatically prepare all of the variants.
If you want to create new icon style variants then things get harder because you will have to deal with ImageMagick processing directives, but once you created your style you will be able to generate and maintain all of the social icons using that style in few seconds.

This script is not tied to Mosaico or the Versafix template: you can use wherever you need to maintain a lot of icons with a lot of variants. Fork it and improve it!

A due update to our "versafix" master template

Wed, 28 Feb 2018 18:00:00 +0000

Mosaico flagship master template is named Versafix-1 and the current version (1.0.6) is used by thousands of users around the world, every day, to create effective and responsive emails.

In the past 2 years we analized how people used Versafix, what were the most commonly altered styles and collected a lot of feedback and feature requests!

We followed the suggestions, but before we detail the improvements, we want to let you know the basics:

forward compatible: any email model saved against the versafix 1.0.x master template can been loaded by the new versafix 1.1.x master template and enhanced with the new options.
requires no changes to the library: we wanted the new template to be deployed also on older mosaico releases (0.14.0+ is known to handle the template correctly).

New & Noteworthy in 1.1.16

New alignment option for titles, paragraphs and buttons

New line-height option for paragraphs

Narrow vs Full width background option in the Logo and Separator blocks

Free height option for image sizing in blocks with images in multiple columns

New “Image size” variants for the “Image and Text” (hero) block

HTML output fully revamped

The improvements above were introduced in 1.1.0 release. Then it tooks 16 releases (to 1.1.16) to deal with email clients specific issues :-)

We introduced new “hybrid hacks” (responsive + spongy + calc) to improve compatibility with most email clients and to improve responsive behaviour on email clients not supporting CSS media queries.

This let us correctly switch the responsivity in Gmail desktop and in “MyMail” app for Android and iOS (Mobile apps from Mail.ru, Libero.it and maybe other big local providers are in fact MyMail “forks”).

Enjoy

The updated template is already included in the official mosaico distribution (0.17.0) and can be tested here on Mosaico.io live demo.

We also created a specific Github repository for the master template so to better deal with template releases that often don’t need a new library release and follow different release paths.

Full Mosaico-based email template authoring app from the community

Mon, 30 Oct 2017 12:00:00 +0000

A full web application

GoodEnough, a small web agency from Paris, just published a full web application built around Mosaico to let companies easily install a complete environment where multiple users can work on email templates using Mosaico.

The project repository started as a Mosaico fork, but in fact we now see it as an application that depends on Mosaico. We are working with GoodEnough so to let their customization being developed as plugins instead of altering the main code, so it will be easier to keep up with new Mosaico releases.

The App has a very good looking material design and is very easy to use and you can easily appreciate their UX skills!

Deploy to Heroku+AWS in minutes

Yannick and Antoine also published a Deploy to Heroku button to deploy the app to Heroku in minutes. You need an Heroku account, an Amazon AWS account and some Amazon S3 manual configurations to start it, but you will be ready to start your own deployment in the cloud in few steps.

Here you can see their screencast about the App.

Use it!

We are very happy to see the community is embracing our library and developing tools around it, so, if you want your own “standalone” Mosaico editing experience and environment, give a look to the GoodEnough tool!

That weird style issue in Outlook/Office365

Fri, 05 May 2017 11:20:21 +0000

When Outlook.com/Office365 find an A tag without the HREF or with an empty HREF or an HREF with the value “#” then it will get very upset and will remove the link tag.

This is a known bug documented by the great “email hacker” Rémi Parmentier*

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body style="font-size: 30px;">

<a style="color: red; background-color: yellow;"></a>
<p>A paragraph</p>
<p>Second paragraph with no style</p>
<p style="">Third paragraph with style</p>
<p style="">Fourth paragraph with style</p>

</body></html>

So we are not surprised our link is not red on yellow, but look at how Outlook.com renders the “Third paragraph” for the previous code:

It sounds like an almost “random” element in the page will get the styles once belonging to your “unlinked” link.

Our tests proved that the element is not “random” (of course) but it is the first following (in the DOM traversing) element with a “STYLE” attribute.

So, this is just another reason to stay away from empty links.

(*) We suggest you Rémi’s latest post about Outlook.com weird bugs

Double Head trick in Yahoo Mail App for Android

Thu, 20 Apr 2017 17:57:21 +0000

Do you style in the head or in the body?

If you want high compatibility you probably inline your main styles, otherwise Libero.it, Mail.ru, Naver, Telstra, T-Online, Terra, Yandex and many other won’t style anything.

But, you may also have other styles that are not inlined and you want them to be displayed by smart email clients.

In past the best solution was to put the style declaration inside the body, but you know that since Oct 2016 Gmail introduced partial styles support and they only use them if they are declared in the HEAD.

So, the “new” rule is to put them in the HEAD.

Then you find out that Yahoo App for Android doesn’t show your styles anymore because it will simply strip any style from the HEAD (why? who knows.) You won’t find many informations about Yahoo App rendering, the only reference I found is here:

FreshInbox(*) in that article documented that Yahoo Mail App for Android supports only styles declared in the BODY.

So, what to do? Insert the whole style declaration twice? Drop support for Yahoo Mail App for Android?

Now, here is a little trick

…enabling styles for Yahoo Mail App for Android and Gmail without the need to duplicate them (and doesn’t break other clients, AFAIK).

Simply use a “double head”, by addin an empty <head></head> before your real <head>. Yahoo App for Android will strip that first head and leave your second head in place.

From our tests, both manual and via Email On Acid, this works everywhere.

I tried adding styles to both “heads” and clients supporting non-inline styles will see both of them, but GMX.de and Web.de (and of course Yahoo App for Android) that will only see the second HEAD styles (the ones we care).

<html>
  <head><!-- Yahoo App Android will strip this --></head>
  <head>
    <meta ... >
    <style>
      your styles
    </style>
  </head>
  <body>
    your content
  </body>
</html>

Disclaimer: using 2 head tags makes your HTML “malformed”. Do you care? Also using the style tag in the body was invalid.

(*) Remember: the best single page resource for updated email rendering issues in 2017 is FreshInbox. Most of other pages around are simply outdated and keeps telling you to use uppercase Margin or [class] selectors. Don’t be confused by the “kinetic” titles, it is a great resource even if you don’t care about kinetic emails.

Mailtrain - self hosted newsletter app - now includes Mosaico Email Editor

Thu, 06 Apr 2017 12:00:00 +0000

Mailtrain defines itself as “Self Hosted Newsletter App Built on Top of Nodemailer”: it’s an open source project, born in 2016, meant to be an alternative to commercial ESP to who prefer a self hosted service, with complete control on the software beneath.

Mailtrain has grown a lot in the past year, and has a fairly huge fanbase (over 1.300 stars on GitHub): its ambitious roadmap includes not only the basic newsletter send features (list management, custom fields, list segmentation, bounce analysis…) but also a number of advanced tools, like RSS campaigns, GPG Encryption, Automation.

As soon as the project launched we suggested to Andris Reinman, the creator of Mailtrain, that Mosaico was a perfect match for MailTrain and Andris put Mosaico as possible integration in official Mailtrain roadmap published on 8 April 2016.

An year later Roger Witzig contributed the code to let Mailtrain support external email editing tools and added support for both Mosaico editor and the wonderful GrapesJS(*) editor inside Mailtrain.

A few days ago we received the Mailtrain Announcement newsletter and, guess what? it was beautiful, fully responsive, sent by Mailtrain itself and…. designed with Mosaico.

Mailtrain is a young project, but is growing fast so we are happy and proud to be part of this project. Starting from v1.23.0 release it includes Mosaico: test it and let us know what’s your opinion.

(*) before you get too excited for GrapesJS as an email editor we suggest to read a couple of comments on why we think GrapesJS is a great web editing tool but not yet ready for the real world email templates requiring dozens of html hacks

Fab4 responsive technique: stability and usefulness beyond Gmail

Fri, 21 Oct 2016 17:57:21 +0000

Responsive Emails has been a trending topic in Email Marketing since last five years. Today most emails are read on mobile devices, so responsiveness is a must, but many email clients and webmails have a really limited support of media query, the main css way to make responsive html layout.

Previously…

Until Sept 2016 (when Gmail started supporting non-inline styles and media queries), the most problematic clients were Outlook and Gmail (both web and app); to overcome these problems many techniques have been developed - mainly table based layouts with conditional comments to satisfy Outlook a lot of inlined CSS to make Gmail happy.

Someone started to use mobile-first templates, letting media queries manage the desktop version - where it was possible.

Then Hybrid Coding / Spongy technique emerged: a mix of well balanced inline styles, with min-width/max-with and width tricks, letting also Gmail have its proper adaptive version even if not fully responsive.

Hybrid coding has been adopted by many email templates (also Versafix-1 Mosaico Template use it) even if the rendering of responsive version in Gmail was not perfect.

A different approach

A new technique emerged early in 2016, called the Fab4, mixing the width, min-width, max-width (all already used in hybrid coding) with a CSS calc() trick.

Fab4 has a completely different approach: no table based layout - all inline-block divs - and a calc() based breakpoint, based on the parent width instead of media queries.

Fab4 code

The basic is (to be inlined):

.block {
    display:inline-block;
    min-width:50%;
    max-width:100%;
    width:calc((480px — 100%) * 480);
}

In this brief example 480px is the brackpoint: if parent width is under 480px the calc-computed .block width will be over the max-with of 100%, so the div will limit its width to the max-width value, occupying the whole space, making multiple .block stack in a single column.

If the parent width is over 480px, then the calculated width will be a negative number, so the box will shrink to the min-width of 50%, and the .block will be arranged into a two columns layout.

The method is really smart but has 2 big limits:

calc is not supported by all clients
many webmails may strip down parenthesis or the whole calc property value

For the record the final version proposed in the original article is:

.block {
    display:inline-block;
    min-width:240px;
    width:50%;
    max-width:100%;
    min-width:-webkit-calc(50%);
    min-width:calc(50%);
    width:-webkit-calc(230400px — 48000%);
    width:calc(230400px — 48000%);
}

This simply introduces “-webkit-“ prefixed calc so to support older WebKits and does the math in the calc expression because some webmail removes styles with an asterisk or double brakets.

So, the method proved to be solid and Campaign Monitor has rewritten its responsive templates to use this technique - alongside a series of conditional comments table layout bit and other minor tricks to achieve complete Outlook compatibility.

But now Gmail supports media queries

So, is the Fab4 method still useful? Maybe.

If you look at global shares Gmail was the only email client having a need for the Fab4 method, but if you send to specific non-US markets or you also care for less used email clients then you may still need it.

Here is a list of local/regional providers that you don’t find in “global stats” but are big in specific countries:

Russia: Mail.ru, Yandex.ru, Rambler.ru
China: QQ.com, 163.com
India: Rediffmail.com, Sify.com
Germany: Web.de, T-online.de, GMX.de
France: Wanadoo.fr, Orange.fr, Free.fr, SFR.fr
Italy: Libero.it, Alice.it, Virgilio.it, Tiscali
Brazil: Terra, Uol, Bol
Spain: Terra, Teleline
Portugal: Sapo, Telepac

For example in Italy (we are italian so we prefer to talk about what we know well) the 4 “local” providers above generate more than 30% of total email opens and Libero.it alone is the first provider with more users than Gmail.

So, it worth testing each “method” also against webmails or mobile apps being relevants for your target and not only against the major global providers.

In our tests we found that QQ.com, Terra, GMX, Web.de and Yandex will show Fab4 mobile version, failing to use whole desktop space, when available. On the same webmail systems, spongy technique (tested with our Versafix-1 template) works well, showing full desktop version. Orange.fr has problem with both tecnique, but slightly minor with Versafix-1/hybrid/spongy; on Lotus Notes 8.5 Fab4 fails in bad ways, while Versafix-1 looks good.

By now we know that Gmail transition towards full media query support is not yet completed: IOS client seems to be stuck on “old” Gmail rendering system and also Gmail webmail mobile version is not accepting media query so far. On both Gmail version (IOS and Webmail mobile) Fab4 technique works well.

Results

As said before, Fab 4 technique is born mainly to go beyond “old” Gmail limits, and give a proper responsive email version also on non media query compatible webmail and clients.

With brand new Gmail media query support this need seems to be outdated, but so far transition is still uncomplete and there are also many local webmail that are incompatible with media query.

To sum up Fab4 could be a nice option if you are mostly mobile-oriented: this method renders slightly better in mobile versions than Spongy/Hybrid technique (not so much, by the way), anyways you have also to consider that Spongy/Hybrid technique seems to react in a more solid way with “problematic” clients and webmails.