Outlook ignores query strings on image src

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

Email On Acid test: Outlook 2010 displays images from URL sources that don’t depend on a query string

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.

Update, 29 Sept. 2016: Email On Acid has confirmed on their forum that “Outlook doesn’t accept media query strings” on any version of the Windows client.

Update, 25 Oct. 2016: If a source URL has two slash characters in a row, Outlook will remove one of them. So for example,

https://example.com/foo/https://myredirect.com?bar=baz

will become

https://example.com/foo/https:/myredirect.com

Look out for this if you’re trying to write a proxy service to get around the limitations on query strings!

Advertisements

Outlook.com and Office 365 now support the TD background attribute

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.

1. 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.)
2. 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.
3. OWA clients do not use VML for image or gradient backgrounds, although desktop Outlook clients do (Outlook 2007/2010/2013).
4. OWA clients do not respond to conditional comments like <!--[if gte mso 9]> , although desktop Outlook clients do (Outlook 2007/2010/2013).
5. 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.

RVM and “[gem] not found” errors

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:

bundle exec cap staging patch:apply FILE=patch.diff
zsh: command not found: cap

I checked that I had Capistrano installed by running gem list, and I had it. So I tried
bundle exec cap staging patch:apply FILE=patch.diff
zsh: command not found: bundle

I thought it was related to my terminal, maybe a bad path, some kind of RVM issue. I Googled around for RVM path issues with ZSH, and couldn’t find any places my configurations differed.

Eventually, I went to double-check which Ruby RVM was using, and got this:

$ rvm list

rvm rubies

* ruby-1.9.3-p448 [ x86_64 ]

# => - current
# =* - current && default
# * - default

Well, that’s interesting! I didn’t have a current Ruby! So I ran rvm use default, and lo and behold, my cap commands worked again.

New vim line numbering options

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 line
relativenumber only: only relative numbers, 0 in current line
number only: only absolute numbers
neither set: no line numbering

—vim_dev Google Group thread, message on 25 June 2013 sent by Ben Fritz

Result: for totally sweet line numbers, just update your Vim and put set relativenumber in your .vimrc file!

Edit: To clarify a bit, the old behavior for relativenumber was to show 0 for the current line number, and that wasn’t modifiable. Setting number just switched you back to absolute line numbers.

IE9, JQuery/JavaScript, and broken select boxes

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!

Berlin Geekettes: Women in Tech panel, part 2

Oops! I was in such a hurry to post the video yesterday that I didn’t realize it was only the first half of the talk! Here’s part two.

Berlin Geekettes: Women in Tech panel from Campus Party Europe

Here’s the video for the Berlin Geekettes panel I spoke on last Thursday at Campus Party. I hope the sound is ok; the acoustics of the space left something to be desired.

Topics of discussion include stereotype threat, “having it all” and what success means, and how to get more women involved in tech.

EDIT: There’s a second part to this video, which can be seen in my next post.