?

Log in

No account? Create an account
Previous Entry Share Next Entry
CSS in email: now *that* is annoying
querki
jducoeur
I just went to send a nicely-styled email through Querki, and was distressed to find that it *completely* failed. I had figured that email support wouldn't be complete CSS, but absolutely nothing stylistic happened.

A bit of research, and what do I find? It turns out that many mail readers (including, notably, Gmail) simply do not support modern CSS in the slightest. You can't do anything with real stylesheets -- you have to go back to 1990's styling, with explicit inline styles everywhere.

Of course, Querki was built to modern spec -- it *thinks* in terms of stylesheets, and exposes and uses styles that way. There is, quite deliberately, no support for old-fashioned inline styles, since they are deprecated by most good style guides these days.

*Sigh*. Pain in the tuchus. I've added style support in email to the to-do list, but folks should note that it'll be a fair while before it happens -- it's going to be a lot of work to make it work even minimally, and email is very much a "because we have to" feature. For now, Querki-sent email will necessarily be fairly plain...
Tags:

  • 1
Heh, with that subject line, I was expecting you were going to be complaining about modern email that can't be read in plain text clients. ^_^

I sorta wonder how you could support non-inline CSS in Gmail without security holes. iframes, I guess?

Hmm. Obviously you'd have to disallow the Javascript-y bits of CSS, but email already disallows Javascript. (The plan is to disallow those syntactic bits in Querki anyway.) Do you see other issues?

I mean, CSS doesn't have scoping. For a web client like gmail that inserts email content into a broader HTML page, you'd obviously not want email to be able to change the style of parts of the page external to the email. If you don't use an iframe, this means you probably have to rewrite the CSS classes and ids in the email by adding some particular prefix. Which wouldn't be that hard, I guess.

Ah, I hadn't gotten what you mean by the iframes. Yes, scoping is clearly essential. But I can't imagine that's rocket science. (Better not be, since I'm going to have to do it for Querki in the near future...)

I guess you'd also have to do something clever to disable any CSS that'd set something like a background image (or anything else that makes an external request) until the user chooses to allow background images, though I guess maybe the inline CSS support already deals with that.

Email, in retrospect, is such a poorly designed system for the modern era. No reliable formatting (I still actively prefer plaintext most of the time), no real security, the illusion of reliability, and even now there are struggles with manageability, and spam, no matter how good the Google (or other) tools are.

[joking] You could always have the system generate a PDF and send it as an attachment. Email has no interactivity beyond html links, and a PDF is just as good. [/joking]

Edited at 2013-09-17 05:37 pm (UTC)

... okay, glad you added the jokings there.

I expect that we'll get email formatting eventually, and I've planned out how it's likely to happen. But it requires me to write a proper CSS parser first (to transform CSS into style tags) -- probably useful in the long run for various reasons, but enough work that it'll be a while yet...

I had them there from the start, but with angle brackets. So LJ stripped out hte unknown 'tags' to sanitize the input.

In retrospect, I should have known that would happen.

  • 1