two days on CSS inside emails at Varia in rotterdam, bluring the line between conversation and publications
Declarations is an ongoing artistic research project into the poetic materiality of the CSS web-standard and its visual-political-cultural echoes on design-artistic practices and our daily lives. Declarations is a love letter to the crafts of designing with language.
two days on CSS inside emails at Varia in rotterdam, bluring the line between conversation and publications
We decided to focus two days on CSS inside emails. Emails are an ambiguous place for HTML/CSS, since it's not per se a browser but also not entangled to HTML/CSS (some of you may be reading this letter in plain text).
Through non-linear cascading email conversation exercises, we'll questions ourselves on mode of address, low-tech & high-tech dichotomy, nostalgia-induced technology, spam, newsletters and forms of forwarded declarations.
We will give forms to questions by writing our own CSS inside of email replies, making publication happen through conversations.
people
screens
A bit of history...
In 1971 the first network mail was sent, this is when the syntax with the '@' symbol designating the user's system address appeared. These first mails were sent using the Simple Mail Transfer Protocol (SMTP). The current Internet's standard email protocols is Post Office Protocol (POP3)and Internet Message Access Protocol (IMAP). Fast-forward to the 2010, where mobile apps strongly increased email accessibility and use.
It was found that US adults check their email more than they browse the web or check their Facebook accounts, making email the most popular activity for users to do on their smartphones.ref from 2013
Paradoxically for the following younger generations, instant messaging, texting and social media took over the use of email. For some of us email can be part of those nostalgia-induced technology, on the wikipedia page of email we can read that "the writer Matt Richtel said in The New York Times: that email was like the VCR, vinyl records and film cameras—no longer cool and something older people do".
HTML and plain text emails
Email was originally a text-only communications medium, now still existing in the form of plain text emails. After being extended by MIME (Multipurpose Internet Mail Extensions) to support larger character sets and multimedia, we saw the rise of HTML emails (they still often include an automatic-generated plain text copy for compatibility). One of the culturally impacting heritage of HTML email that we can observe as designer is the setting apart previous messages in block quotes, often styled (like Gmail) as colored border-left.
Now every client supports HTML emails but none render it consistently with W3C specifications, which may cause rendering or delivery problems.
Wikipedia lists as disadvantages of HTML emails: the increased size of the email, privacy concerns about web bugs, abuse of HTML email as a vector for phishing attacks and the spread of malicious software. This pushing for or against HTML emails also play with our perceptions and preferences of low-tech and high-tech dichotomies.
It can feel like lots of emails are bloated with non-semantical HTML tags for display purposes and external assets working half of the time. Plain text email assumes it is about the text, and not how it is presented, stripping out every tag and style. Most email clients support both plain text email and HTML email, and sometimes give the option to activate/deactivate one of the two.
CSS in emails
The more familiar form of HTML emails that use plenty of CSS are probably newsletter or notifications emails, that make uses of CSS to be catchy amongst other emails, or to reflect the visual identity of the brand or institution. In most cases the way people edit this HTML is through a GUI, allowing to use italic and bold formatted text, quotes or images from a menu.
In particular, the
headtag, which is used to house CSS style rules for an entire HTML document, is not well supported, sometimes stripped entirely, causing in-line style declarations to be the de facto standard, even though in-line style declarations are inefficient and fail to take good advantage of HTML's ability to separate style from content. Although workarounds have been developed, this has caused no shortage of frustration among newsletter developers, spawning the grassroots Email Standards Project, which grades email clients on their rendering of an Acid test, inspired by those of the Web Standards Project, and lobbies developers to improve their products.
To avoid total customization, clients have developed their own priority system. Some senders may excessively rely upon large, colorful, or distracting fonts, making messages more difficult to read. For those especially bothered by this formatting, some user agents make it possible for the reader to partially override the formatting (for instance, Mozilla Thunderbird allows specifying a minimum font size); however, these capabilities are not globally available. Further, the difference in optical appearance between the sender and the reader can help to differentiate the author of each section, improving readability.
"Netiquette"
There are some rules on the mode of address in emails and for online communication in general. They are largely inherited from letter writing, change depending on languages, some are also unspoken and we end up copying signatures we receive. Email etiquette apparently also changes through time and different generations.
Socio-technical aspects of email
Shape conversations through writing
However, from a designer-artist-writer perspective, being able to shape conversations through the act of writing is one of our interests. Because Declarations is a research about (web)-languages - thus about writing - emails are an interesting medium: They make use of specific cultural modes of address playing on formality or authenticity, we don't write an email the same way we write on messenger for example.
Non-linear cascading
A last but important point of interest for email(-threads) is their non-linearity. When an email is sent to a group it can be replied to individually, then sent back to the group at a later point, or forwarded to another group. Because the default behavior is to stack everybodies answer chronologicaly, an initial message can evolve into different conversations, like a fork.
Most of these art-publishing projects play with the fragment versus the continuum.
Mail art
Networked/email publishing
Non-linear literature
Most email clients support HTML email editing through a GUI, allowing to use italic, bold, quote or images from a menu. But when it comes to writing your own HTML/CSS by hand it can be more tricky.
As explained, lots of mail clients remove everything that is part of the ´head´ tag and also often ´style´ tags, as you can see here. One way to make more design-wise resilient HTML email is to write the CSS inline, inside of the ´style´ attribute. But that requires one to do it manually for every HTML element that constitutes the email... CSS inliners are tools that convert from a ´style´ tags to inline CSS. But by using such tools, you also freeze the styles: no cascading anymore - the styles won't propagate to email responses as they have to be explicit for each element.
Services such as Mailchimp feature automatic CSS inliner, as well as a lot of craft to try to solve specific compatibility issues.
CSS support for email is very low in comparison to current browser support. We have nothing like grid or flex, external resources in stylesheet (especially fonts) are blocked. This is why newsletter crafting has become this very crafty practice of making templates out of ´table´, most often with default ´font-familly´, and minimum external images or logo. However, it surprisingly well supports the graphic properties that CSS artisans cherish: border and border-radius, gradient bakgrounds and color, box-shadow or text-shadow, transform, text-decoration.
If you're using thunderbird this is easy.
For other clients such as outlook, or mail on mac os, it is possible but rather hacky. Here is a tutorial for mac os: https://stackoverflow.com/questions/48214386/insert-html-into-email-in-apple-mail#48215810