Every version of Outlook on Windows, from 2003 through to 2016, fails to render an image when the query string contains required information for accessing the URL. Key screenshots from a test on Email On Acid are below.

Email On Acid test: Apple Mail 8 displays images from URL sources, including when the query string is required

I can’t tell whether this issue is because Outlook ignores the query string or actually removes it entirely, but it doesn’t really matter; the result is broken images when a user opens their mail.

The issue arose for me when trying to send messages with images from Cloudfront that use query string params to pass an access key, a signature, and an expiration date. Without the query data, the image can’t render.

The solution for my case (since I can’t change Cloudfront) will have to be either attaching the images and using cid references, or base64 encoding the images and embedding them inline. (Check out Sendgrid’s post on strategies for images in email for more details.) Either way, this is one more obnoxious pain to add to the long list of obnoxious pains when working with Outlook.

After several days of fighting with email layouts for messages of varying content length, trying to find a solution for showing a gradient background (either as an image or as CSS) in the many mail clients out there, I learned a few things.

Outlook.com and Office 365, which both run code known as OWA, have added support for the background attribute on the td tag, which my email testing service hadn’t noticed yet. (They thanked me for pointing it out to them.)

The background attribute on the td tag only takes a string representing the path to an image. It always tiles that image, which means it repeats the image both horizontally and vertically to cover the entire table cell.

OWA clients do not use VML for image or gradient backgrounds, although desktop Outlook clients do (Outlook 2007/2010/2013).

All the advice out there about putting backgrounds on your emails is aimed at one-off mailings, generally marketing campaigns, where the height of the content is known and doesn’t vary.

As of right now, there is no way to safely display a gradient background on an email with variable or unknown height for clients running on OWA. But at least now I have a clear understanding of what’s happening in those mail clients.

tl,dr: If your gems aren’t being found, check that you’ve got a current Ruby in RVM.

I had some fun tracking down why my installed gems were not being found today. I do my dev work in a virtual machine (VM) that handles most of the work with gems, but there are some commands that are run only from a physical machine, such as Capistrano tasks for deployment to our various servers. I wanted to put a patch on the staging server, and ran into the following:

I was at the fantastic CSSconf.eu on Friday, and one of the presentations include code in Vim with a line numbering setup that blew my mind. It showed the current line number as an absolute number, but showed all other lines as relative numbers, making it super-duper easy to go up or down N lines in normal mode.

I asked the presenter how it was done, and was told it was “part of the SPF13 bundle.” So today I looked it up, but no luck. There was no plugin included to change the line numbers. Time to do a little more digging! In fact, there was a change made to Vim itself in version 7.3.1115 to allow more customization of line numbers. Here’s how it works now:

patch 7.3.1115 changes the ‘number’ and ‘relativenumber’ options so that instead of resetting each other, they interact with each other, so that 4 different displays can be achieved:

both set: relative numbers + absolute number in current linerelativenumber only: only relative numbers, 0 in current linenumber only: only absolute numbersneither set: no line numbering

I hope nobody else has this problem, but just in case, here’s the thing I had to diagnose this afternoon: a few select boxes (those things that drop down a list of options and you choose one) were immediately closing themselves in IE9, which prevented changing their options. It only happened in IE, but I noticed the same elements were causing strange behavior in the Chrome developer tools—computed styles couldn’t be expanded, the attribute checkboxes were flickering, and the JS console was slow and stuttery when opening it with ESC). That behavior tipped me off that there was probably something strange happening in our code, not just in IE. Turns out that to automatically check a text input for matching content in our database, someone had implemented a jQuery function to run every 250ms, and that’s somehow interfering with the select elements. It’s not solved yet, so look forward to an update after I find a solution that (hopefully!) keeps all the functionality intact.

Update: I was unable to find the real cause of this problem. I worked around it by checking for a text match only on blur (when the text input loses focus, i.e., you click or tab away from the input field). This solved the problem, and had the side benefit of reducing the calls to the server, particularly because using JavaScript’s setInterval meant the function kept being called, even after the modal dialog had closed!