imedo Development Blog

As requested here is the presentation for our awesome email plugin:

Slides

Popularity: 2% [?]

For the impatient

Check out the demo application:
http://opensource.imedo.de/htmlmail

Install the plugin:
script/plugin install git://github.com/imedo/awesome_email.git

Learn how to use it below.

Introduction

Have you ever tried sending HTML emails to your users? If you did, you know for sure that it sucks big time: none of the usual ActionView helpers want to work, URL routing is disabled, layouts don’t work, and last but not least, the CSS you wrote for your email simply won’t work in any e-mail client except maybe Apple Mail. To solve all of the above problems, the awesome_email plugin comes to the rescue. Just install it into your vendor/plugins folder, and the rest comes by itself.
If you are interested in what works in which Email client check this link: A guide to css support in Email

What does it do?

There are a few interesting components in awesome_email:

• awesome_email adds layout support to emails. That means that you can use templates for e-mails just like you would with normal Rails Views.
• The HTML Mail’s CSS is automatcally inlined. That means that your designer and/or CSS guy can design the email in a web browser without worrying about how it might look like in excotic email clients. Yes, it works in Outlook, too, and no, it doesn’t work in Outlook 2007 without tweaking. The reason is a “stupid decision from Microsoft about Outlook 2007”, but we’re working on that one.
• ConvertEntities replaces Umlauts and other crazy symbols like ä, Ö etc. with their HTML Entitiy counterparts e.g. ä and so on.
• HelperMethods allow you to dump the content of the CSS file right into a style tag inside the header of your HTML mail.

How to use it

In your Mailer.delivery_xxx methods you can use

1
2

layout    "template_filename"
css       "css_filename"

to define which layout should be used and which css file should be used to create inline styles

CSS inlining

The cummulated style of each DOM element will be set as an style attribute when using css inlining.

Example:

your css file:

1
2
3

#some-id { font-size:2em; }
.some-class { color:red; }

your template:

1
2

<p id="some-id" class="some-class">Hello World!</p>

will result in the following code:

1
2

<p id="some-id" class="some-class" style="color:red; font-size:2em;">Hello World!</p>

Important!

Be sure to follow these simple conventions or otherwise awesome_emails’s magic will fail:

• The layout must be located inside app/views/layouts/{mailer_name}
• If you send mutlipart mails, check out the conventions on how to name your files: http://rails.rubyonrails.com/classes/ActionMailer/Base.html
  • So if you have these files inside of /app/views/{mailer_name}: signup_notification.text.plain.erb, signup_notification.text.html.erb ActionMailer will send a multipart mail with two parts: text/plain and text/html
• Your CSS file must be inside of /public/stylesheets

Dependencies

gems: rails 2.0.2, hpricot, csspool

Getting it, License and Patches

Get the complete source code through http://github.com/imedo/awesome_email. License is MIT. That means that you can do whatever you want with the software, as long as the copyright statement stays intact. Please be a kind open source citizen, and give back your patches and extensions. Just fork the code on Github, and after you’re done, send us a pull request. Thanks for your help!

ToDo

• More test coverage (as usual)
• make it more flexible with view paths
• rails 2.1 compatibility

Popularity: 100% [?]

There’s an ongoing debate on whether or not your website has to be html valid or not. Some people follow the html validation ruls religiously others just don’t care. Here are a few thoughts which you might want to consider when answering this question.

1. Getting the same rendering result in different browsers is hard enough. Does invalid HTML make it easier to get the same result?
2. There are different kinds of validation errors. A wrong/invalid attribute is not as bad as a missing closing tag. But how do you know that you only have the “not so bad” errors in your page if it is invalid?
3. Related to 1 and 2: How do you know that this little error is still a little error and doesn’t mess up all the markup tomorrow because a much worse error sneaked inside your markup? (see: Fixing broken windows)
4. SEO. I recently saw a presentation by Rand Fishkin of SEOmoz and he (as well as other SEO experts) said that HTML validation is not important for SEO. I think the correct answer is (as always): It depends. The Google bot, or Yahoo slurp! might not care about validation and are fine with crappy HTML. But: If you produce invalid HTML that gets interpreted wrong by the bots or some parts of your page aren’t even parsed, well then congratulations for spending so much time on optimizing your site when it all was in vain. And again: If you have invalid code you never now HOW invalid it is (see 3.)
5. Valid HTML isn’t that hard. Really. The fact that browsers are sloppy and try to interpret invalid HTML (sometimes in creative ways and every browser differently) is not an excuse do not produce valid HTML output. There are a few rules to follow (mostly block/inline element alignment) and you’re ok.

So how do we handle this? We agreed to produce valid HTML code. Always. And we validate the whole site at least once a day. Automatically of course. We use the assert valid asset plugin to check the output of our functional Rails tests (which pretty much cover every page on our site). This helps us to find errors in the markup early and fix it before the new version goes online.

We do not believe that every single page is html valid at this point but that’s our goal. If you find any invalid page, feel free to e-mail us the URL (e.g. use entwickler [at] imedo.de) and we’ll look into it.

Popularity: 1% [?]