Open Email Standards – HTML5, CSS3 & JavaScript Specification

Read the Docs

Introduction

To support enhanced and consistent email content, Open Email Standards introduce a new Content-Type: application/xhtml+xml. This content type leverages current web technologies like HTML5 and CSS3, complementing the currently used text/plain and text/html formats. It offers a pathway to enhanced functionality and helps bridge the gap between traditional email formats and modern web experiences.

Syntax and Declaration

The application/xhtml+xml content type supports both strict XHTML syntax for enhanced consistency and security, and a simplified HTML5 declaration for practical use. While the simplified approach is common, strict XHTML is recommended for maximum compatibility and reliability.

Example 1: Strict Mode Declaration

From: sender@example.com
To: recipient@example.com
Subject: Example XHTML Email
Date: Mon, 24 Jun 2024 12:34:56 -0400
Message-ID: <unique.message.id@example.com>
MIME-Version: 1.0
Content-Type: application/xhtml+xml; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Standard-Version: 1.0

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE email SYSTEM "https://openstandards.email/dtd/email.dtd">
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Example XHTML Email</title>
  </head>
  <body>
    <h1>Welcome to Our Newsletter</h1>
    <p>This email uses the application/xhtml+xml content type for a richer experience.</p>
  </body>
</html>

Example 2: Simplified HTML5 Declaration

From: sender@example.com
To: recipient@example.com
Subject: Example HTML5 Email
Date: Mon, 24 Jun 2024 12:34:56 -0400
Message-ID: <unique.message.id@example.com>
MIME-Version: 1.0
Content-Type: application/xhtml+xml; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Standard-Version: 1.0

<!doctype html>
<html>
  <head>
    <title>Example HTML5 Email</title>
  </head>
  <body>
    <p>This email uses a simplified declaration for broader compatibility.</p>
  </body>
</html>

Supporting Legacy Clients

The introduction of the Content-Type application/xhtml+xml does not deprecate text/plain or text/html. Legacy systems can continue to rely on these formats, ensuring backward compatibility. This three-tier strategy allows email clients to gradually adopt modern standards while still preserving functionality for older implementations.

Best Practice Guidelines for XHTML Emails

XML Declaration: Use <?xml version="1.0" encoding="UTF-8" ?> to ensure proper parsing of XHTML content in email.
DOCTYPE Declaration: Employ <!doctype html> for broader compatibility with modern HTML5-based clients.
HTML Namespace: Specify xmlns="http://www.w3.org/1999/xhtml" in the <html> tag to declare the document as XHTML.
Self-Closing Tags: All non-void elements such as <img />, <br />, and <input /> must be self-closed to comply with XHTML syntax rules.
Strict Syntax Validation: Adhere strictly to XHTML rules, including properly nested and closed tags, to ensure consistent rendering across compliant email clients.
Language Declaration: Include the lang and xml:lang attributes in the <html> tag to specify the primary language of the email. This enhances accessibility by allowing screen readers and related technologies to interpret content accurately, ensures proper language recognition by email clients, and aligns with best practices for semantics and internationalization.

Multipart Content Types in Open Email Standards

To fully leverage the benefits of HTML5 within emails, the recommended approach is to use the multipart/alternative content type. This ensures compatibility across email clients by providing fallback options like text/plain or text/html, while also enabling richer content and a clear distinction between HTML4 and HTML5 to render the most appropriate version.

For emails containing inline images, use the multipart/related content type along with application/xhtml+xml. These embed assets should be referenced via cid (Content-ID) for secure rendering. Only images should be allowed; other assets like stylesheets or scripts introduce security risks and must be blocked.

Example 1: Complete multipart/alternative Email

Content-Type: multipart/alternative; boundary="boundary42"

--boundary42
Content-Type: text/plain; charset="UTF-8"

This is the plain text version.

--boundary42
Content-Type: text/html; charset="UTF-8"

<html>
  <body>
    <p>This is the <strong>HTML4</strong> version.</p>
  </body>
</html>

--boundary42
Content-Type: application/xhtml+xml; charset="UTF-8"

<!doctype html>
<html>
  <body>
    <p>This is the <strong>HTML5</strong> version.</p>
  </body>
</html>

--boundary42--

Example 2: Inline Images with multipart/related

Content-Type: multipart/related; boundary="boundary42"

--boundary42
Content-Type: application/xhtml+xml; charset="UTF-8"

<!doctype html>
<html>
  <body>
    <p>This email includes an inline image:</p>
    <img src="cid:logo1" alt="Logo" />
  </body>
</html>

--boundary42
Content-Type: image/png
Content-ID: <logo1>
Content-Transfer-Encoding: base64

[Base64 image data]

--boundary42--

Example 3: Combining multipart/alternative and multipart/related

Content-Type: multipart/alternative; boundary="boundary1"

--boundary1
Content-Type: text/plain; charset="UTF-8"

Plain text version of the email.

--boundary1
Content-Type: text/html; charset="UTF-8"

<html>
  <body>
    <p>HTML4 version of the email.</p>
  </body>
</html>

--boundary1
Content-Type: multipart/related; boundary="boundary2"
Content-Disposition: inline

--boundary2
Content-Type: application/xhtml+xml; charset="UTF-8"

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE email SYSTEM "https://openstandards.email/dtd/email.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <body>
    <p>HTML5 version with inline image:</p>
    <img src="cid:logo1" alt="Logo" />
  </body>
</html>

--boundary2
Content-Type: image/png
Content-ID: <logo1>
Content-Transfer-Encoding: base64

[Base64 image data]

--boundary2--
--boundary1--

XML in Email Environments

XML (Extensible Markup Language) is a versatile format widely used for data exchange and storage, excelling at defining complex information relationships. In the email context, it can support automated workflows, unlocking new possibilities for enhanced email applications. However, its broader use remains outside the scope of current Open Email Standards, which prioritize application/xhtml+xml for visually rich, interactive, user-facing content.

Examples and Potential Use Cases

Although not the primary focus of this specification, particular environments may benefit from using XML messaging for structured, data-centric interoperability. The following examples illustrate how XML-based emails can significantly enhance functionality and expand their role in automated workflows, highlighting potential for specific use cases rather than serving as a general-purpose content type like application/xhtml+xml.

Data-Driven Automation: Systems receiving XML emails can parse structured data like invoices or order confirmations for automated integration into back-end processes without human intervention.
Secure Communications: Encrypted XML emails can transmit sensitive information, such as financial statements or medical records, decrypting and presenting it only after strict recipient verification for enhanced security.
Localized Content: XML enables dynamic rendering of multilingual content through <content> tags with lang attributes, allowing email clients to deliver personalized experiences based on the recipient's language preferences.

Example: Multilingual Content Representation in XML

<?xml version="1.0" encoding="UTF-8" ?>
<content>
  <text lang="en">Hello!</text>
  <text lang="es">¡Hola!</text>
  <text lang="ja">こんにちは！</text>
</content>

Content-Type