The HTML coding standards and dilemmas or why is this so complicated? Part 3

What you see isn't always what you will get, or more accurately, we will always reap what we sow in the realm of email rendering. Let's take for instance the very secretive and proprietary rendering that happens behind the scenes in older Blackberry's—they perform a kind of digital alchemy on email turning gold into lead. Yes you read that correctly, I didn't just have a moment of dyslexia, your beautiful golden emails are turned into textual lead on Blackberry 2.x hand held devices.

However, all is not lost, your consolation is that your links, if properly coded as fully qualified URLs in the HREF will appear miraculously after your hyperlinked text. Confused? Don't worry, most people are when they look at a Blackberry 2.x device and ask themselves, "what's actually happening here?"

How Blackberry renders your emails

You are not looking at the TEXT part of your multi-part MIME, no, that's not the case at all, Blackberry renders the text in the HTML part of a MIME by dropping every tag in the email and then displaying the untagged text. This means you can't format any part of your email or embellish the text by making words bold or italic etc. etc. There are several nuances to keep in mind when you try to achieve the maximum readability and cross-platform optimization for your emails on Blackberry devices:

• Always send a text part: Blackberry 1.x devices do not strip the HTML tags out of a multi-part's HTML part and will default to your TEXT part if you send it. This gives you the opportunity to put up a clean textual email with functioning URLS if they are fully qualified URLs. If you send only an HTML part Blackberry 1.x devices will display raw code making your emails virtually unreadable to the recipient.
• Use shorter links: Use the shortest links possible as long links can push your branding and calls-to-action down the page, this applies to both Blackberry 1.x and 2.x platforms and should be a general guiding principle whenever contemplating cross-platform optimization.
• Anchors will not render: If you use anchor tags in an email they will not render in Blackberry 2.x devices and will appear as simple text.
• Use fully qualified URLs: Always use fully qualified URLs in your HREFs because that is what will appear after a hyperlinked bit of text on a Blackberry 2.x device. If your URLs are not fully qualified, like an anchor tag, or a relative link, then the text will not be followed by a URL thus rendering that link dead.
• Validate your code for accuracy and tidyness: Blackberry's parser is a propreitary algorythm; how it actually goes about munging HTML code and rendering it on a Blackberry device isn't public knowledge but we have observed that non-W3C-compliant HTML Code will cause rendering problems and may make ALL of your links show up unrendered. In order to ensure your code's integrity you need to run it through a W3C parser and perform an HTML Tidy. Think of it this way, Tidy is like your proof reader, if you left a trailing bracket, or an unclosed tag, Tidy will catch it and clean it up. Both of these mission critical tools are built into Pivotal Veracity's eDesign Optimizer.

"The best defense against poor rendering is good code!"

This has been a mantra in our office since time immemorial. In today's multi-channel world where messages liberaly cross the borders between social networks, mobile devices, desktop email clients and web email accounts, it's more important than ever to insure your message integrity by validating and thoroughly testing your code using world class tools. As the old saying goes, the devil is in the details make sure your code is gremlin free—tidy up your code as the last thing you do before you hit send and the first thing you do when you attempt to diagnose your rendering challenges.

Cheers!
-Len Shneyder
Dir. of Partner Relations
& Industry Communications