Just Because You Can...

Vendor Prefixes, WODs and the Uncaring Class

Art Thompson, Jr. — Wed, 02 May 2012 21:54:12 +0000

First, let me state that I semi-agree with the sentiment that “vendor prefixes are hurting the web” though I’ve yet to form a more solid opinion—a situation that’s recently been made worse in the wake of news that Opera will introduce support for WebKit CSS prefixes. The argument for this support is that, allegedly, several “lazy” web developers are rampantly using only WebKit CSS prefixes (minus even unprefixed versions!), which renders some content ugly and/or unreadable on non-WebKit browsers, which could in turn make it seem like those browsers don’t work as well as WebKit browsers.

So, let me get this straight, the lazy practices of what are essentially sloppy coders are determining browser feature development? Bring on the zombie apocalypse.

I would like to thank Ian Devlin for coining the term WOD or WebKit Only Developer. I didn’t have a simple means of referring to these folks prior to reading his blog post and he’s encapsulated the defining phrase and off-sounding anagram (nickname) beautifully, IMHO.

All humor aside, I wonder if the apparent issue of WODs isn’t more of a “class” issue, for lack of a better term. As someone who used to be a devout Apple enthusiast (more like separatist), I rarely cared what happened outside of that sphere since I knew in my heart that I was on the “right” side of any platform debate. Fortunately, that was back before Apple was a significant player in the browser space, so my superior attitude was a non-issue with regards to web development.

Nowadays, a web designer/developer who is also a Mac OS—and likely iOS—user can conceivably live in a purely Apple environment without even realizing (or caring) that there are other desktop browsers much less mobile ones than what come pre-installed on their aluminum devices. Devlin’s characterization of WODs as lazy is rather polite, but I’d say that both the spirit of what they do and the effect they have on the web is plain uncaring.

Again, my use of the term “class” in this case is iffy since it implies some form of economic disparity between one group and another. Perhaps it’s debatable whether Apple users have a higher standard of living than non-Apple users, but that’s mostly beside my point.

Consider the reality that Apple is the new 400lb. gorilla. Its growing market share on desktop and dominance on mobile has allowed it to throw its weight around a bit and web standards have not been immune to this behavior. Combine that with the superiority complex that often accompanies ones acquisition of a Mac OS or iOS device and it’s less of a stretch to apply the term “class” to this scenario.

So then what’s my point about a so-called “uncaring class” that uses only WebKit CSS prefixes? Oh, right. My point is that some developers who work within a highly popular and seemingly ubiquitous ecosystem could be at risk of forgetting the “other half” exists or even matters, especially when that ecosystem is unilaterally churning out marketer-approved bells and whistles that are being applied willy-nilly to sites all over the web (this one notwithstanding).

I routinely receive pre-coded files from clients (who are apparently WODs) that either don’t validate or simply look like do-do on any other browser because they have only been “tested” on Mac OS Safari 5. You tell me, is this behavior lazy or uncaring? I literally had a designer client of mine once ask me, incredulously, after I suggested he do browser testing “does anyone still use Internet Explorer anymore?!?” Literally.

And I must wonder, if WODs are ignoring other browser vendors, does that include JAWS screen readers, too? Again, lazy or uncaring?

Well, thanks to Opera’s recent cave-in, history may or may not prove whether vendor prefixes—specifically those of the WebKit variety—ultimately hurt the web. What is certain is that users of WebKit browsers won’t likely have noticed.

Remove CSS Comments – Automagically!

Art Thompson, Jr. — Mon, 05 Mar 2012 19:54:45 +0000

I’ve shared this info via email and Twitter, but have yet to blog about it, so here goes:

First, I LOVE using and finding comments in HTML and CSS markup. Since 1993, I’ve learned almost all that I know about web development by viewing source and then later inspecting elements of other peoples pages. While the detective work required by uncommented code proved a great teacher, those comments proved a great time-saver. Not to mention the fact that they’re critical in a multi-user work environment. Nevertheless, there can definitely be too much of a good thing.

Anyone who’s used Adobe Dreamweaver’s built-in boilerplate New Document templates has surely found the HTML and CSS comments—especially in their CSS files—to be rather, um, verbose. I once posted my opinion on an Adobe user forum and suggested that there needed to be a simple Preferences checkbox to turn these on and off. I actually received a reply by a forum ‘superuser’ who insisted that this was merely Adobe’s way of “introducing DW users to HTML markup” (and presumably the code view in as well?) to make us feel more comfortable with hand coding. I kid you not. I most certainly replied with a completely sarcastic response and probably hurt his feelings a bit in the process, but it needed to be done.

To this day, no matter how well you understand CSS, you cannot suppress those helpful /*comments*/ from appearing within your DW files—and chewing up bandwidth and increasing your page weight in the process. The obvious solution here would be to create my own boilerplate templates for various layouts and simply use those as starting points. Well, that’s a lot of work once you think about the various permutations of column layouts, headers, footers, etc. and I’m always way busy with work-work to even begin such a project. Enter stored queries.

Several hours of Googling various keyword variations and scouring the resulting sites eventually led me to David Powers’ Foundation PHP website and in particular to his blog post Stored Query to Remove CSS Comments. Bingo. Complete usage instructions are in his blog post, but the gist is this: Download and save his css_comment_remover_v3.dwr file to your desktop (for easy access). Then, with your heavily commented CSS file open, click CTRL-F/CMD-F, click the ‘Load Query’ button and select his stored query, then click ‘Replace All.’ Done.

Two things I should note:

This stored query works with any CSS file using the standard /*comment*/ tags.
THIS WILL REMOVE ALL OF YOUR CSS COMMENTS.

So, obviously, do this once at the beginning and then go back and add your own comments where necessary and continue to do so along the way.

CSS comments are good.
CSS Comments are necessary.
CSS Comments are no place for entire HTML/CSS tutorials.

Thanks for listening.

HTML Email Presentation Slides

Art Thompson, Jr. — Wed, 01 Feb 2012 20:41:46 +0000

Below are my slides from the “HTML Email: Coding Like It’s 1999″ presentation I gave at Refresh Austin in February of 2011:

HTML Email: Coding Like It’s 1999

View more presentations from Art Thompson Jr.

5 Free Web-Based Design and Development Tools I Actually Use

Art Thompson, Jr. — Fri, 19 Aug 2011 01:07:40 +0000

We web folks are using web-based design and development tools within our workflow more and more each day. Working in this often challenging and dynamic environment is frequently made easier by the kindness of strangers in the form of freely-available tools and resources. Well, as a small way of saying “thanks for making today easier,” I’d personally like to tout some extremely helpful web-based tools I use on a weekly, if not daily, basis. Below are my current top 5—in no particular order (since they’re all #1).

Note: I’ve decided to let these apps speak for themselves by including descriptions that I pulled directly from their respective websites.

FFFFALLBACK

“Web fonts are here, sparking an exciting new era in web design. FFFFALLBACK makes it easy to find the perfect fallback fonts, so that your designs degrade gracefully.” — www.ffffallback.com

Fractal

“See exactly which lines of code are not supported in over 24 email clients. Email designers that are tired of trawling through check lists, this is for you.” — www.getfractal.com

MIN

“MIN is a bookmarklet that will strip any decoration from a site. All color, borders and backgrounds are removed instantly, helping you identify the successful and unsuccessful uses of typography and layout.” — min.artequalswork.com

QuirksMode

“QuirksMode.org is the home of the Browser Compatibility Tables, where you’ll find hype-free assessments of the major browsers’ CSS and JavaScript capabilities, as well as their adherence to the W3C standards.” — www.quirksmode.org

Smush.it

“Smush.it uses optimization techniques specific to image format to remove unnecessary bytes from image files. It is a “lossless” tool, which means it optimizes the images without changing their look or visual quality.” — www.smushit.com/ysmush.it

Of course there are other superb (and also free) web-based design and development tools out there with many more being created every day. Lucky us. I will certainly share more of my favorites with you in future posts. But, if you use web-based tools to help solve your development and design mysteries, please let others know by Tweeting or blogging about them and thanking their authors publicly. After all, no one’s getting monetarily rich by making all that ingenuity and hard work available for free. But a little gratitude can be worth ten times its weight in gold.

Gotham-Light Ain’t a Web Font

Art Thompson, Jr. — Wed, 25 May 2011 04:01:00 +0000

Here’s something peculiar I came across recently:

On the left is what I saw in Chrome and on the right is what I saw in Chrome after I’d deleted ‘Gotham-Light’ from the beginning of that page’s font stack within the Chrome Web Inspector. Actually, there were a couple of linked CSS files on this page competing for control over which font the browser should use to display text. Here’s what I saw:

body {
     color: #999999;
     font-family: 'Gotham-Light', Helvetica, Verdana, sans-serif;
     font-size: 10pt;
}

followed by:

body {
     font: 13px/1.231 arial,helvetica,clean,sans-serif;
}

Now, I won’t even comment on what’s wrong with that second body style—just don’t meditate on it too long or your brain will come pouring out your nose.

The first one, however, I will go off on. First, who would think that a good fall-back font for Helvetica is Verdana but someone who couldn’t tell the two apart? I submit that such a person should not be specifying typefaces—anywhere. Second, if you’re going to use standard OS fonts (meaning you’re not using a webfont technology like TypeKit, FontDeck or the Google Font API), why not ensure that everyone is seeing the same one by specifying a good ol’ Core Font for the Web first such as Verdana, Arial, Georgia, etc? These come installed on both Mac and Win PCs by default, right? Well, I’ll tell you which font doesn’t come installed by default on any PC running any OS: Gotham-Light.

I happen to be one of the random individuals this web developer was fishing for when he/she specified Gotham-Light as the primary font-family for this website. The particular version I have installed on my Win 7 PC is an old postscript font I purchased eons ago from Hoefler Frere-Jones (along with a few other of their exquisitely designed typefaces) back when I was an active print designer. The Gotham family is permanently activated as I often find use for it when no other sans-serif font seems to do the trick.

In any case, the font’s postscript code used to create the character shapes and spacing was never intended for entirely accurate (much less beautiful) representation on computer displays and the screenshot on the left shows why. Actually, on my Win 7 PC, only Chrome and Safari displayed the text in Gotham-Light, albeit poorly. IE 9 and Firefox 4 simply ignored it.

Mind you, this is no ~~amature~~ amateur website. It is for a major consumer brand with an extensive online presence. We’ve all got dirty laundry, I guess. But, I come across font-failures like this one fairly often and I just have to question the initial logic that created them.

And there I went.

More Notes on Coding HTML for Email

Art Thompson, Jr. — Thu, 14 Apr 2011 23:46:01 +0000

[First, don't yell at me—I know HTML is a markup language. But, until a better term/phrase comes along than "marking-up" this is what you're getting. Anyway, on to the topic at hand...]

Since publishing my tome, HTML Email: Coding Like It’s 1999, and subsequently presenting the same topic at Refresh Austin I’ve been jotting down notes and tips about specific issues that I encounter daily while working on eblasts and newsletters. I thought I’d post them here in no particular order and keep doing so over time as a sort of repository. Since the best way to find anything on the web these days is search, I thought merely posting them was enough. Everyone knows how to ctrl-F or cmd-F, right? Well, if this list gets too long, perhaps then I’ll address its structure and order. In the meantime, here we go!

Line-Height

Avoid using em as a unit of measure here. A few tests on Outlook 2007 and certain Hotmail clients revealed that these were largely ignored thus collapsing or expanding the line-heights to the clients’/browsers’ defaults. Fugly to say the least. Instead, use the less-accessible but universally-reliable px value and everything will look the same across all platforms.

TD Background Colors

Double-up on these as a fall-back, meaning use both the td‘s bgcolor attribute as well as an inline style tag with a background-color attribute within your td tag. One of these is bound to work in every possible platform.

Zap Gremlins

No, not the wet, overfed Mogwai you’re thinking of. I’m talking about those mis-encoded characters you get from copying and pasting text out of PDF and PSD files that make bizarre characters show up in your eblast copy. Since losing use of my favorite text editor, BBEdit, after parting ways with Apple back in 1997 and switching to the now-debatable “dark side,” I haven’t found a better way of dealing with these other than doing a Dreamweaver find/replace on the usual suspects: curly quotes (”), apostrophes (’), hard returns in PSDs, registration marks (®), copyright symbols (©) and trademarks (™) just to name a few. Unfortunately the “paste from Word” feature in your favorite editor doesn’t always do the trick and often makes things worse if your text isn’t coming from Word. There’s also the trick of copying from a PDF/PSD file, pasting into a blank Word doc, copying that and then trying “paste from Word,” but that might screw up some other things that were displaying/encoding fine. Just be diligent and test on the worst possible scenarios (Outlook 2003 or Lotus Notes 7 on Win XP?) where these badboys are likely to all be lurking.

Centering

Centering your document has one major benefit in that it gets your beautifully designed eblast or newsletter away from the ugly crap that’s in the left and/or right sidebars of webmail clients like Hotmail, Yahoo! Mail, AOL Mail and Gmail, surrounding it with white space or that of your specified background color (I’ll post something about that at a later date). AOL, for example has left and right sidebars turned on by default. Do you really want your handiwork pressed up against those beauties? Center your layout’s main table using these two seemingly redundant methods:

Set your table tag’s align value to “center”
Wrap your main table in a container div—old school—style, like div align=”center”

Doubling-up will ensure your main table will be centered across all platforms. And what’s the harm in centering something that’s already centered?

Width < 700px

As I mentioned before, AOL has left and right sidebars turned on by default that take up around 400px of screen real estate. On a 1024×768 display, provided the browser is full-screen, you’re left with 624px–not including the browsers edges & scroll bar or any padding/margins that webmail clients add to the main email content area. As of March 2011, Adobe SiteCatalyst Netaverages shows around 21% of their captured web users’ data have display resolutions of 1024px or less. StatCounter reports 26% of worldwide users. That ain’t no IE6 brush-off number. That’s one in four users. In my daily workflow, I shoot for 700px-wide maximum, keeping the important content well away from the edges.

Cellpadding vs Padding

Let’s say you have a block of text with white type knocked out of a blue background like this:

this is some text.

You might be inclined to simply apply 15px of padding to your paragraph tag along with the appropriate font and background colors like so:

this is some text.

Well, when your boss gets your beautifully-coded newsletter in his/her inbox using either Outlook 2007 or 2010 it will look like this:

Padding and margins are some of the least predictable CSS attributes when dealing with Outlook from any era. Instead of taking the easy way, wrap your text in a table—yes, a table—and let the table’s tried and true cellpadding attribute do the magic like so:



this is some text.

It will look the same in practically every email client/browser and in the end that’s all that matters.

Overriding Minimum Font Sizes in iOS devices

If you’ve ever tested your copy-heavy newsletters on an iPhone or iPad then you’ve surely seen your layout and proportions go down the toilet. Problem, the default minimum font size on an iOS device is 13px and you’ve likely got fonts sized smaller than that (likely for good reason). One possible solution: target those devices using this technique described by Ros Hodgekiss on Campaign Monitor’s blog. Keep in mind that this could affect other webkit-based browsers such as Safari on the desktop (as pointed out by Johnathan Snook in the comments). It’s probably a good idea to use these along with an @media query to target only those devices with minimum font size issues. Another solution: Simply design your email in a way that your minimum font size is 13px. ‘Nuff said.

SXSW 2011 Wrap-Up

Art Thompson, Jr. — Fri, 18 Mar 2011 00:09:54 +0000

SXSW Interactive 2011 is finally over and I’m once again sifting through a stack of biz cards, stickers and miscellaneous scraps of paper with email addresses and twitter handles scribbled on them. Once again I’m weighing the cost of entrance, the interruption of several days of work and the physical toll of all-day conferences followed by all-night schmoozing. My overall gut reaction is that SXSW 2011 felt like a much better organized experience than last year’s conference. Perhaps it’s because the organizers managed to keep related panels and speakers closer to one another to minimize the amount of walking one had to do. Perhaps it’s because I was more diligent in planning my days. Either way, this year was MUCH more “worth it” than last.

One caveat here is that I’m not going to mention the panels that I missed because there were easily twice the number of folks wishing to hear them than could fit into the tiny rooms in which they were held. SXSW conference organizers need to do a better job of anticipating what we attendees want to know. Too many interesting topics overflowed while other, less exciting ones looked silly in those cavernous halls only a quarter-full.

Highlights

The conference officially kicked off for me on Friday night with the dual-boot event at the Austin Music Hall featuring Dorkbot and Ignite SXSW – 2021 Vision of the Future. I’m a fan of the hit-or-miss, Pecha Kucha-style micro-presentation format and Ignite Austin has consistently done a great job of sifting through and finding interesting topics & presenters. For me, the most notable speakers on this night were Nick Pinkston (2021: Hardware is the New Software) and Brandon Wiley (The State of Free Speech Online in 2021). Pinkston’s 2021 was wrought with open source hardware and digital manufacturing where “makers” build physical hardware as agile as software. Wiley’s 2021 still had us raging against totalitarian regimes, but this time with such high-tech tools of democratic communication as laser modems and non-networked WiFi sync stations for “bike-net” couriers. I feel better already.

As for the official SXSW panels and speakers I heard:

Khoi Vinh‘s ”Ordering Disorder: Grid Design for the New World” was a nice refresher course on the importance of grids and proportion in web design. As the former Design Director for NYTimes.com he knows a thing or two about grid layouts. The presentation mostly contained content and visuals from his excellent New Riders book Ordering Disorder: Grid Principles for Web Design, which is in my Nook eBook wishlist.

“It’s Nature’s Way: Innovative Tech Design Through Biomimicry” was an informative panel discussion on the ongoing pursuit of studying patterns in nature and how we can design better products and systems based on millions of years of evolutionary “design.”

Drawing Back the Curtains on CSS Implementation painted a frustratingly hopeful vision of the current and near-future state of CSS browser implementation from some of the top folks literally wrestling with submissions and standards—namely Opera’s Molly Holzschlag, W3C/Mozilla’s Elika Etemad, Microsoft’s Sylvain Galineau and Google’s Tab Atkins.

Keynote interview with The Guild creator and star, Felicia Day, provided some valuable insight and advice for anyone who is thinking of producing content and one day turning pro. Her no-compromise approach has yielded innovative content, satisfied sponsors, obsessed fans and ultimately the freedom that every creative individual desires.

Joshua Porter‘s “Metrics-Driven Design” didn’t have a sexy title, but delivered intelligent, usable action items that designers can use to deal with research-driven cultures’ (both marketing- and engineering-based) demands for quantifying and qualifying otherwise aesthetic design choices. Did Google really bucket test their blue link color 41 times before settling on #2200c1? You bet your hex values they did. Did it really make that big of a difference? Bing’s UX Manager Paul Ray allegedly claimed their blue (#0044cc) was worth some $80 Million per year in additional clicks. Some of that better have trickled down to the design department. His preso has been uploaded to Slideshare here.

I DON’T think I’ll be standing in such a ridiculously long line for another “Interactive Opening Party presented by frog design.”

The panel “No Excuse: Web Designers Who Can’t Code” promised to be a heated and insightful debate, but instead dragged on and never fully hit its stride primarily due, in my opinion, to the panel moderator—Rdio’s Wilson Miner—and his “I really need some coffee or a bloody mary to get through this day” demeanor. Not to mention his Ira Glass homage which sort of fell flat. Additionally, the panelists’ intros went on a bit longer than necessary. None of this contributed to the panel’s promising title. Oh, well.

“Jeffrey Zeldman’s Awesome Internet Design Panel” was as much a discussion on the state of publishing as the state of website design. Zeldman asked “How many of you work in publishing?” then “How many of you make websites?” followed by the remark “You’re all publishers.” It seemed an apt bend to the conversation given that seated to his left was publication design veteran Roger Black who currently has his hands full with the HTML5 publishing platform Treesaver among other things. Also on the panel were the well-known designer/author Dan Mall as well as TypeKit’s Mandy Brown, whose A Working Library is as desirable a reading list as you’re likely to come across.

Carlo Longino‘s “User Experience and Cross Platform App Development” was one of those presentations that I wish I had the Slideshare link to. The info was fast and relevant and I wish I’d taken more notes!

whurley‘s blandly titled “Designing for iPhone” presentation was an entertaining and informative Q&A from the get-go. What more apt format would fit a solo presentation given by one of the more successful iOS app developers around? “Design for the intended device” was more or less the takeaway. People pay a lot for a particular device and app developers should give them an appropriate experience. I was hoping for an HTML5 “write once, run anywhere” answer to be perfectly honest.

The debate-style panel “Real Tech Rockstars: Engineers or Designers?” was often in danger of becoming an infomercial for the Mint app. But moderator and Fortune senior writer, Jessi Hempel, managed to keep Mint founder and developer, Aaron Patzer, and former Mint lead designer, Jason Putorti, on point as they argued the virtues of user-centered design versus problem-based development. The outcome was—no big surprise here—that there needs to be a good balance of the two with an eye on the prize of developing a useful and usable product that customers love. Amen, brothers and sisters.

And, finally, there was the conference-closing “Steve Krug Explains It All for You” where the title pretty much said it all. Mr. Krug is one of the most respected usability nerds and has been championing the cause with such must-read books as Don’t Make Me Think and the more recent Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems. No matter what it is you “make” you can always learn something from hearing Krug speak about the cyclical process of usability testing.

Unofficially…

One of the greatest benefits of SXSW Interactive is the access it provides to all of the folks who make the tools and cull the information I rely on on a daily basis to get my work done. Where/when else would I be able to—on the same day—pick Paul Irish‘s brain about Chrome’s dev tools, ask Barry Abrahamson why you can’t preview pages with alternate templates in WordPress, find out why Outlook 2010 email images are frequently blocked from Matthew Brindley of Litmus and thank Chris Coiyer and Dan Oliver for all of that useful info that’s helped me out of numerous jams?

Maybe I’ll be back next year.

HTML Email: Coding Like It’s 1999

Art Thompson, Jr. — Thu, 06 Jan 2011 07:10:08 +0000

Okay, why HTML Email?

Doesn’t it seem you’re constantly having to design and/or code more and more eblasts and newsletters?
Didn’t you, at first, agree with the marketing folks that it’s a total no-brainer and that you could knock it out after lunch?
Didn’t you once hastily “yes” the salesperson who asked if they could just send out your coded eblast to their list through Outlook?
Didn’t that beautifully designed eblast consisting of a single, embedded JPEG yield the lowest clicks and the highest unsubscribe numbers to date?
Doesn’t it seem way more complicated than it need be?

Welcome to the wonderfully frustrating world of HTML Email. And welcome to 1999.

The Good News

The good news is that EMAIL IS KING. It is nearly ubiquitous among US adults with adoption somewhere around 98% (source: www.pewinternet.org). It’s also free with no barrier of entry thanks to popular web-based email services such as Windows Live Hotmail, Yahoo Mail and Gmail. The corporate king is still Microsoft Outlook in all its various, aged incarnations. And on the consumer desktop, Apple Mail seems to be leading this antiquated model, though Thunderbird still has several fans. And then there’s mobile. But forget I mentioned that. For now.

The Bad News

The bad news is that EMAIL IS KING. And if having to deal with the numerous versions of Outlook wasn’t bad enough there are a seemingly infinite number of combinations of webmail services + browsers + browser versions + OSs.

The problem is that there are no email standards to speak of. Each email client supports an incomplete set of either HTML and/or CSS making it nearly impossible to determine anything more than a baseline feature set. Woo-hoo!

The Bottom Line

E-marketers wait for no one and this eblast has gotta get out to the list tomorrow AM.

So, what’s the takeaway here?

This is not intended to be a course on email marketing nor is it a full-fledged tutorial. Instead I want it to serve as a primer plus a list of resources for those needing or wanting to code HTML Emails.

Just a few words on MOBILE…

I recently read that more folks were checking their email on mobile devices than on computers. This would make sense with the gazillions of iOS and Android devices being activated every day. For the sake of space and my own sanity, the information in this article pertains mostly to the desktop/laptop variety of HTML Email, though most modern mobile clients tend to do a much better job rendering HTML Emails that their landlocked counterparts.

HTML and CSS within the Email Client

Contrary to your sales/marketing person’s intimate knowledge of the medium, HTML Email cannot be sent out by copying and pasting your code into a new Outlook message. In order for the HTML to render correctly, your code needs to be assembled at the server level where it is adorned with all the appropriate headers and such and shot out to your recipients.

The easiest way to do this, by far, is by using an EMAIL MARKETING SERVICE (EMS) such as Emma, Constant Contact, Campaign Monitor, MailChimp, etc. I won’t go into which is better, just know that they exist for a host of reasons. On the corporate side, many IT departments host their own bulk mailing services in-house. Either way, Outlook is NOT the way.

Ready to Code Like it’s 1999?

Beyond being an cheap catchphrase, my reference to 20th century markup refers to the dumbed-down subset of HTML & CSS that’s currently available to developers working on HTML Emails. For reasons I shall soon explain, you will need to go back in time, so to speak, and pick up coding and layout techniques that would make any web standards nerd spit up all over his/her WaSP t-shirt. If you thought the phrase “slice and code” raised some eyebrows, just wait ’til you drop “nested table layout” at your next Refresh meetup.

Speaking of slicing and coding, this article presumes that you, the reader, has a working knowledge of HTML/CSS in their currently recognized state. The code examples herein are shown with regard to the topics being covered rather than in a tutorial setting where each tag is explained. If you want to learn about HTML & CSS and how to use them, I highly recommend you checkout HTML Dog.

Step 1. Manage Lower everyone’s expectations (aka: time to break some hearts).

There’s a lot you can do in an HTML Email, but there’s even more that you can’t. If you’re not also the designer, make sure you clue he or she in on the limitations of the medium. And make sure to do the same with the client or marketing person. No sense in having to explain why the coded version in her inbox doesn’t even come close to matching the designer’s PDF file she approved.

So then, why not just export that PDF as a single JPEG image and embed that in an email message and send it out through your email client? Simple answer: SPAM. And by that I mean your email will likely be marked as SPAM by most of its recipients since it contains no discernible information beyond the embedded image (which could contain malware). Also, your ISP will likely lock down your email account suspecting that it is being used for sending SPAM or malware. Need I continue?

Step 2. Determine your Target Email Clients – Pick your battles!

You can’t please all of the email clients all of the time so pick your battles and make sure you have a strong business case for when you inevitably get that Outlook ’97 on Win XP screenshot from your client/boss that’s all awry. The good news is that there’s some reliable data out there to help you determine what your targets should be in order to create a baseline. Here are a few snapshots of the email client landscape:

Campaign Monitor’s Numbers from ~~Dec 2009~~ June 2011

(Revised 2011/07/18—Source: www.campaignmonitor.com/stats/email-clients/)

Litmus’ Numbers from ~~Feb 2010~~ July 2011

(Revised 2012/04/05—Source: litmus.com/blog/email-client-market-share-infograph/email-client-market-stats-1000)

First let’s just get it out in the open and admit that all such statistics are skewed and affected by numerous factors. Please read the fine print on both of these sites, which explain how they arrived at their respective numbers.

Nevertheless, what can we learn from a quick glance at these two charts? That OUTLOOK IS STILL KING. Seriously, when one antiquated platform commands such a lead, it’s hard not to consider this your baseline. Set the controls for 1999!

Step 3. CSS layouts? Never use ‘em..

First things first, in HTML Email there’s only inline CSS. Some EMSs allow some styles such as background colors to be specified in a STYLE tag inserted just after the opening TABLE tag, but these can be hit or miss depending on the recipient. You also can’t rely on a CSS reset to zero out all of your margins and padding. Don’t think that some email clients won’t add their own default values and ruin your layout.

The CSS allowed in the majority of email clients is a lot closer to CSS 1 than anything we use on websites today. It’s also longhand. There’s none of this funny business going on:

hello world

In HTML Email, we need to use something like this instead:

hello world

I know it seems like more than twice the code, but that’s the deal. Just do it. A good way to make sure no shorthand is included automatically is to set your prefs in Dreamweaver (or tool of choice) to something like this:

Now, for page structure, you’ll want to get to know this snippet of code:




 This is my first table!

In HTML Email, it’s table-based layouts or nothing. You will use table cells for every block of content. You will nest tables to position items in various locations on the page. You will travel back in time to 1999!

There are no DIVs per se in HTML Email. Okay, maybe there’s one—just one—that wraps your entire page like so:





 This is my first table!

That’s kickin’ it old school, right? It’s a good idea to center your entire email and to add a redundant centering table attribute as above, if just as a fall-back. Try to keep your code away from the browsers’/clients’ edges where they can mess with it and skew and hide pixels and such. It happens!

Next, burn this into your memory:

Some clients may treat images as inline elements, others as block elements. The display attribute here just cements this and allows you to code accordingly. Also, it’s very important to zero your margins as some email clients will add some by default like in this Gmail screenshot:

This is perfect example of how you can spend so much time designing something and so little time coding and testing it to make sure it renders correctly. This same lesson was not learned here either:

Unfortunately, you can’t really know unless you test, which I’ll cover below. You also can’t check your email’s source since many email clients rewrite your code to suit their needs. Just take a gander at your Gmail source code and try to figure out what’s what.

Step 4. Dig around and get your hands dirty with other peoples’ code

Remember the good ol’ days when there weren’t a complete library of O’Reilly books on every subject and you had to scour around the web viewing other peoples’ source to figure things out? Wait, these still are the good ol’ days! Search around and you will discover some great design & code examples created by folks who’ve figured a lot of this stuff out. EmailCraft gladly airs their laundry in this gallery of examples.

Campaign Monitor has made available these free, ready-made HTML templates designed and coded by some of the web’s rock stars.

Step 5. Create a baseline HTML Email Checklist

Coding requirements vary from EMS platform to platform so be sure to check what’s required for yours. Below is a general HTML Email checklist that should serve as a good starting point. Some things to consider:

Width – Try to keep things within 800 pixels max. You never know what someone is viewing your work on and how many stupid sidebars, menus and ads are creeping in from either side.
Fonts – Stick to the fab five: Arial, Verdana, Georgia, Times New Roman (Times) and Courier (Courier New) in all their variants (normal, normal+italic, bold, bold+italic) and colors (go hog wild here!)
Absolute URLs – You cannot display images in your emails any other way than to host them on a server and point to their absolute URLs.
Image file formats - Stick with JPG & GIF. Remember, it’s 1999.
Markup – Use HTML4 or XHTML Trans/Strict and collapse your indents and remove all spaces between tags in your markup. Code for email is not poetry.
CSS – Use minimally, inline only and NO SHORTHAND. The most common support for inline CSS is with text styling, padding, margins and borders. Remember that CSS will always fall-back to your HTML markup.
Global Styles – There are none reliable enough to use across all email clients. Instead, every HTML tag (P, A, TD, etc) requires its own “style” tag.
Margins and Padding – Each element needs to have its own margin and padding values. You might think to apply these to a TD and that every P tag within will inherit. You might be in for a surprise!
Text-Align – Like many style attributes, double duty is required here. Both your TD horizontal alignment and your P inline style text-align values should match.

…and some things to avoid:

Animated GIFs – While these may display in some web-based email clients, only the first frame will load in most. Why put that much work into something that will only be seen by a few?
JavaScript – You’re kidding, right?
Flash Animations – If it were possible, wouldn’t you have been inundated with these by now?
Background Images - Best to avoid them. While support is growing and hacks exist, stick with what you know, which is that unlike background images, solid colors display correctly EVERYWHERE.
Forms – For a host of reasons, this is just naga, naga, nagonnaworkhereanyway.
Tag Content – TITLE and META tags and the like have no place in your HTML Emails. Most EMSs allow you to put this info in your campaign interface on a per email basis.

Step 6. Setup your EMS account

This is not necessarily an endorsement, but I highly recommend you hurry over to MailChimp and sign up for their Forever Free Plan to use as your test EMS account. It’s a full-featured account limited only by the size of your list (up to 2,000) and the number of emails you can send out per month (12,000). More than adequate for a test account!

Step 7a. Test your work: The Free – Setup multiple test accounts

Get a copy of Outlook and install it on a PC/partitioned Mac/wherever you feel comfortable. Create a test list in MailChimp with addresses for your Outlook/Apple Mail clients and each of these webmail services to send your test emails to:

Don’t forget to test your webmail accounts in different browsers to see if things are shifting around.

Step 7b. Test your work: The Paid – Use an email preview service [REVISED April 5, 2012]

While it’s hard to beat FREE with a stick, you eventually have to consider what your own time and energy is worth. Litmus and Email on Acid are services worth every penny of the fees they charge when you consider what they give you access to. For example, below are the results of an email that was tested using Litmus on 16 different email & webmail client configurations. It took only 8 minutes:

I shouldn’t even have to make a comparison between free and paid as this group of thumbnails (each clickable to reveal an actual size screenshot) should explain the benefits well enough.

Another service [currently in beta as of April 5, 2012] is Fractal, which claims to “Fix your HTML email code in under a minute.” Apparently you just code your email like a web page, upload it and their app will automatically convert it to email-compatible markup. Voilà.

The choice is yours to test with free or paid resources. Just do the math and find what works best for you.

Step 8. Test Early and Test Often

In time you may find that some inline styles appear to render predictable results. Don’t take anything for granted. Use your various test accounts or your email preview service to make sure that your emails display correctly in all target clients.

Step 9. DIY HTML Email articles and resources [REVISED April 5, 2012]

Finally, here are some resources for designing and coding HTML email templates. This is by no means a definitive list, but a real good starting point:

HTML Email Boilerplate - Conceptually similar to an HTML framework such as the HTML5 Boilerplate with the added zeroing-out of a CSS Reset—but for HTML Email—this heavily commented HTML template attempts to both inform you of the various email client pitfalls and help you avoid them. It’s a great starting point for anyone brave enough to enter the dense thicket that is HTML email.

Email Standards Project - Includes an email client rap sheet (somewhat dated, but still good info on baseline CSS support) and a now-historical saga of trying to get Microsoft to fix Outlook.

HTML eMail Troubleshooter via SitePoint is self-explanatory and useful.

Premailer – A CSS to inline-style converter for the masses.

Getting Started with HTML Emails via tutsplus is another excellent primer on the subject with beau coup resources.

6 Easy Ways to Improve Your HTML Emails via tutsplus has even more helpful tips.

Add a background image to your email in two simple steps via Campaign Monitor—I know I said not to, but what the heck. Experiment!

Step 10. Let someone else do all this for you

EmailCraft, [NOT AN ENDORSEMENT—I have no experience using this service] from the PSD2HTML folks, offers relatively inexpensive e-newsletter design & coding (or just slicing and coding your PSD) with a whole slew of output options.

Again, it’s your time and your money and you’ve either got enough of one or the other. Check out your options and your tolerance for this stuff and create a solution that fits your budget and your workflow. In the meantime, I’ll still be here coding like it’s 1999.

Art Thompson, Jr. — Mon, 03 Jan 2011 21:00:59 +0000

January 1st comes around every year at the same time, but it used to always catch me off guard with respect to updating my websites’ copyright notices. That is until I found this handy little code snippet. First, let me say that I am NOT the original author of this code snippet. I would love to know who wrote it so that I can finally thank them for relieving me of this yearly task. I’m sure I stumbled upon this in a sea of search results, likely several replies down into a JavaScript forum posting. Regardless, here is the simplest, JavaScript-based way I’ve found to always be displaying the current year in your websites’s copyright notice:

There might even be a leaner way to do it, but this has always worked perfectly well for me. Have an even easier way? Let me know!

Embedding Video with HTML5 for iOS Compatibility

Art Thompson, Jr. — Mon, 29 Nov 2010 05:59:14 +0000

Update March 27, 2012: I penned this article waaay back in 2010, before I’d discovered John Dyer’s excellent MediaElements.js script, which renders my blog post moot. Please consider this information ephemeral and possibly a PHP user-agent sniffer tutorial at best.

I never dreamed that I’d be writing an article with a title like this. Well, I recently worked on a project where I had to embed a locally-hosted video onto a web page that the client wanted to be able play on “any” PC as well as on an iPad or iPhone. Easy enough, right? My first thought was to Dive into HTML5, but, with limited current browser support, HTML5 alone wasn’t going to be an option for PC users. My favorite container for embedding video has always been the Flash-based Flowplayer, which does actually provide a fall-back option for users on iOS devices by allowing you to display a splash image that links to your MP4 (required format) video file.

I won’t go into too many specifics about installing or configuring Flowplayer here, but below is the basic markup for embedding the player, which is accomplished by attaching an ID or class name to an href (which the Flowplayer JS uses to identify the embed location) as so:

id="player">

As you can see, the HTML is pretty straightforward. On an iOS device this markup would predictably display the splash image as a link to the video file. An iPad or iPhone user could touch the image which would cause QuickTime to launch and play the video.

I wanted to find a solution that would allow me to try out some HTML5 while also maintaining the highest level of compatibility—albeit using Flash. In the end I decided to create two different pages: one with the Flash-based Flowplayer that I would serve up to PCs (and Android devices) and one using the HTML5 tag that I would serve up to iOS devices.

I first created a PHP page called index.php and included a script at the top to determine the USER_AGENT. I found a simple PHP script to do just this on David Walsh’s Blog, which is shown below:

A similar redirect could also be achieved using an .htaccess method, but David’s PHP solution suited me fine. Oh, and I chose to sniff out the iOS devices since they represented the minority of possible USER_AGENTs and thus required less code.

For the rest of the page, I included all of the basic XHTML elements, the necessary jQuery and Flowplayer JS links, the Flowplayer embed code and finally some JS to configure the player. Here’s the rest of the markup:

iPad HTML5 Video Test - Flash Player

I specified the dimensions of the embedded player (id=”player“) as well as the page background color in my stylesheet (style.css):

body {
	background: #000;
	margin: 0;
	padding: 0;
}
/* the video block */
#player {
	display: block;
	height: 480px;
	width: 640px;
	margin: 0px auto;
}

The next thing I did was create the page for the redirected iOS devices, which I called index-ipad.html. This would be the easiest part of the project and would basically come down to the tag and a couple of attributes. Notice I reused the same ID of “player” to specify the dimensions of the video player and to center it on the page:

iPad HTML5 Video Test - HTML5 Player

Not to take anything away from Flowplayer, but clearly this is the more elegant solution. I probably learned more than I wanted to about video on the web from the Dive Into HTML5 page of the same name. But Dev.Opera’s Everything you need to know about HTML5 video and audio page proved the most helpful and is now my go-to reference on the subject.

Now I just needed to test it out to make sure the correct page was being displayed to the user. Here’s a link to my test page, having swapped out the client’s video with one I shot in New Orleans a while back:

www.logicalthings.com/ipad-test/

Oh wait, I don’t own an iPad nor did the project’s budget provide for my purchasing one. Enter YouTube user, Sean, who shows off the most useful feature of Safari I’ve seen to date: Switching the USER_AGENT to emulate an iPad or other browser/device. To do this you first have to enable the Developer menu in Safari’s Advanced Preferences. Then, it’s just a click away:

Now, while this “hack” definitely fooled my USER_AGENT php sniffer, it’s not exactly what I would call an iPad emulator. For starters, the tag’s autoplay attribute worked for me in Safari in iPad USER_AGENT mode, but not always on an actual iPad. How do I know this? Because several members of the WordPress-Austin list who own iPads were kind enough to do some user testing for me. Their reports indicated that autoplay was hit or miss–likely due to variations in iOS versions. Ultimately, the client was happy enough to see the poster frame of the video superimposed with the default Play button on their iPad and for the video to actually play when touched. So I stuck a fork in it.

I didn’t do a whole lot else in terms of testing since there wasn’t a whole lot else going on with this simple, embedded video. But, the exercise proved to be a great learning experience and left me excited to take on some more HTML5 in my upcoming projects, which will likely begin with HTML5 Reset.

Thanks to Paul, Jim, Jenaro and Ike for their help with the testing. I welcome any constructive comments, questions or suggestions.