Web Standards: a Must for HTML Email
Paper for the W3C HTML Mail Workshop, 24 May 2007, Paris, France. Originally published on the W3C website for the workshop.
Abstract
Browser support for web standards is finally becoming commonplace, as is authoring for standards compliance with accessibility front of mind. However, HTML rendering in email clients is sporadic at best, exhibiting a lack of CSS support reminiscent of (now-antiquated) 4.0/5.0 browsers. We must continue to embrace web standards and call for support in HTML email clients.
Brief history of web standards
It took many years for web standards to become an inherent part of website development, the major hurdle being the attempt to convince browser developers to comply with standards for rendering. While there is still varying support among browsing devices, we are finally seeing results (excluding mobile devices, which offer little to no support for CSS formatting).
The championing of accessibility has yielded an array of web browsers which support web standards, as well as a new breed of web designers who author content accordingly. Semantic markup and CSS presentational layers provides content which is accessible to everyone irrespective of their browsing device. On the web we are becoming accessible by default.
Web standards in the HTML email environment
The email arena, however, is currently facing the same lack of support for web standards in email clients once exhibited by browsers. We are merely on the horizon of support for CSS as we face an array of challenges, some familiar to the browser environment and others specific to the email environment. We can consider four primary factors contributing to this lack of support:
- An increasing showing of mobile devices (most of which offer little or no support for common presentational markup)
- A lack of support for consistent rendering of CSS by email-client developers
- Heightened awareness of security and privacy
- Webmail clients (rendering HTML documents within HTML documents)
Mobile devices
Current numbers indicate that worldwide there are 2.7 billion mobile subscribers and 1.1 billion internet subscribers, while there are merely 850 million desktop computers. Those numbers imply a significant number of people using mobile devices to access the internet. Given the colossal lack of support for presentational markup among mobile email-clients, it is apparent that accessibility is something of remarkable importance for the mobile-device internet audience.
CSS rendering in email clients
With the “browser wars” of years past, many web developers were forced to use non-standards markup or a collection of common hacks to ensure design integrity across the board. Many of today’s email clients show the same contempt for web standards with their gross lack of support for CSS, while others invest time and effort to ensure their compliance. This inconsistency forces many web designers to revisit the aforementioned hacks and non-standards techniques when authoring HTML emails.
Security and privacy
For many years the email environment has been conducive to scams, viruses and breaches of privacy. As a result, many email clients disable and/or strip presentational components from HTML markup to ensure privacy and security for email recipients. Some even eradicate presentational markup in its entirety. A common consequence of this action is that innocent markup is eliminated alongside the potentially harmful markup, leaving a mere skeleton of information.
Webmail clients
The primary challenge for webmail client developers is that the clients themselves are constructed with HTML. Thus their rendering of HTML documents requires a full HTML structure to reside within another full HTML structure. This parent/child relationship poses a broad array of hurdles, some related to rendering and others related to security.
Proposed solutions for current conditions
Ensuring visual integrity requires a compromise of accessibility and bloats file sizes, the latter resulting in exorbitant bandwidth usage for mobile recipients and slow load times for dial-up recipients. Thus the ensuing debate about use of web standards in emails pits the importance of accessibility versus design integrity.
While marketers and proprietors may favor with the latter, I believe we should correctly favor the former. We have come to this conclusion in great majority with our websites of today. Why, then, should this be an exception within the email environment?
A philosophy called “progressive enhancement” outlines a layering process which ensures accessibility of content for everyone, while providing strong visual enhancement for browsers/clients which can support it. It is possible to build/deploy HTML emails which retain design integrity in clients which offer support for CSS and render similar to rich-text formatting (RTF) in clients offering poor support for CSS. (More on this approach referenced below.)
The adverse effects of forcing design integrity for some people significantly outweigh the benefits of accessibility and low file sizes for everyone. Thus this approach yields benefits for all and a compromise for some.
Call for action for email-client developers
As we once called for browser developers to improve their support for web standards, we should now call upon email-client developers to reserve the same attention for accessibility. Their support for web standards will yield an increase in such authoring by web developers. And the benefits of accessibility in the email environment are parallel to those in the browser environment.
Email clients currently offering some/full support for web standards
- Apple Mail
- Mozilla Thunderbird
- Yahoo! Mail Beta
- Yahoo! Mail
- AOL
- Outlook 2003
- Outlook Express
- Entourage
Email clients currently lacking support for web standards
- Hotmail
- Outlook 2007
- Windows Live Mail
- Eudora
- Lotus Notes
- Gmail
The minutes from discussion about my paper at the workshop are published on the W3C workshop website.
#Accessibility #A11y #WebStandards #W3C #Email #HTMLEmail #EmailDesign #Code #HTML #CSS
Like this? Find out when I publish new work.