My name is Joel
I work on the web making stuff I like. I live in Boston(-ish) with my wife and our English Bulldog.
From the Ruby Noob Dept: Issue(s) with accepts_nested_attributes_for
Finally took some time to jump in and refactor some nested forms at Thredded using Rails 2.3’s accepts_nested_attributes_for. Thanks to Ryan Bates’ screencasts on the topic it was fairly easy. A little code cleanup and everything worked as it should … other than one thing.
Can’t mass-assign these protected attributes
Noticed that error in my development logfiles after a particular form wasn’t being saved. A User class had some protected, and some not, attributes and until I added the Profile attributes to it, the nested form submitting a User and it’s associated Profile record would not save.
class User < ActiveRecord::Base has_one :profile accepts_nested_attributes_for :profile attr_accessible :login, :email, :password, :password_confirmation # ... end
Needed just the Profile attributes set as accessible and ready for mass assignment
class User < ActiveRecord::Base has_one :profile accepts_nested_attributes_for :profile attr_accessible :login, :email, :password, :password_confirmation, :profile_attributes # ... end
Another case where you need to know at all times where and if properties of your classes are locked down or not.
Sassy-pants
I’m pretty set in my ways professionally these days, so it’s hard sometimes to make a shift from what I’m comfortable with to a methodology that’s contrary to something that still works.
Like CSS – what the what needs to change in my work-flow regarding CSS at this point? I’m more than comfortable with box-models, browser hacks, sprites, peek-a-boo and double-float margin bugs. Waking up one day and thinking – “I could be better” was the kick in the pants to try something new. Enter Sass.
Sass is a meta-language on top of CSS that’s used to describe the style of a document cleanly and structurally, with more power than flat CSS allows. Sass both provides a simpler, more elegant syntax for CSS and implements various features that are useful for creating manageable stylesheets.
I won’t go into the syntactic sugar that makes Sass so much fun – John Long [1] [2] and Adam Darowski have already done excellent jobs rounding up the high, and lower, level concepts and tricks. I highly recommend visiting and bookmarking those links for future reference.
A few things I’ve bumped into, however, that bear mentioning here involve a few tools and code snippets that I went looking for as I went down that sassy path. The first being a Textmate bundle for sass I found to help out during rapid and uninterrupted development. The syntax highlights are, of course, fantastic, but the killer feature is easily the quick CSS generation keyboard shortcut. Command-R will parse and generate your CSS file right there from inside Textmate. If there are any issues a tool-tip will pop up with the error. If you switch over and reload your browser too fast to see the tool-tip you’ll see an unstyled page – a big honking notice that you were doin’ it wrong.
The few bits of code, of many, that I needed to find, or create, quickly before getting down to business – Eric Meyer’s reset stylesheet, and maybe a mixin or two that I’m quick to use in a pinch – like .clearfix.
// Reset
html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, font, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td
:margin 0
:padding 0
:border 0
:outline 0
:font-size 100%
:vertical-align baseline
:background transparent
body
:line-height 1
ol, ul
:list-style none
blockquote, q
:quotes none
// remember to define focus styles!
\:focus
:outline 0
ins
:text-decoration none
// remember to highlight inserts somehow!
del
:text-decoration line-through
table
:border-collapse collapse
:border-spacing 0
// ----------- Clearfix ---------------
.clearfix
*display: inline-block
&:after
content: " "
display: block
height: 0
clear: both
visibility: hidden
// ----------- Clearfix as mixin ---------------
=clearfix
*display: inline-block
&:after
content: " "
display: block
height: 0
clear: both
visibility: hiddenThose are two solid examples of how easy it is to just jump right in. So give it a shot – `sudo gem install haml` to install what you need, and get to work playing.
Tips for developing HTML emails
Option 1 – Don’t do it.
And if that’s not on the table (haha – get it?), I present to you …
Option 2 – With a few things in mind when you approach the assignment you’ll get through it. It might not be the most fun, but it’s all doable.
My first suggestion would be to take whatever time you estimated, and double it. Maybe triple it. If you’re reading this post in its entirety then I’m guessing it’s safe to assume these HTML emails aren’t a daily routine for you. If such is the case, the time it’ll take between your first <table> tag, and the moment the email is spammed sent out will not be insignificant – 2-3 times the markup, 2-3 times the complexity in testing esoteric email clients. Your mileage may vary, depending on what the targeted visual design is. It’s always up to your discretion – but the one thing I didn’t anticipate, that I know is a rule, not an exception, is the time you spend on the testing process.
Before starting – these are the things you should have up front to make your life semi-easier.
- Create test accounts at gmail, hotmail, yahoo mail, and AOL. Except you can probably ignore AOL out of principle. I felt dirty just typing that. As with most things related to this practice – having to maintain test accounts at these email services is usually more trouble than it’s worth, but save yourself time and pain by using some sort of password database, such as 1password. Remembering passwords isn’t the hassle here – it’s the random usernames you’re going have to pull out of thin air, which you’ll end up using very infrequently. Trust me.
- An account at an email campaign website like CampaignMonitor or MailChimp. I’m a big fan of, and more prone to recommend, MailChimp not only for their pricing and offerings but the user experience throughout. It’s on my short list of sites that are actually fun to use – as silly as that may sound. Why Mailchimp? You can set up a sample campaign, point to your code on your webhost of choice, and send emails using the code hosted out there in the wild.
- A virtual machine with Windows, and the latest version of Office. This one’s a given as most emails sent for B2B purposes will end up in MS Outlook. As of right now the latest is Office 2007, whose changes to how html emails are rendered are the single reason to pack up and go home if you can. Want more info? Here you go. Office costs money, obviously, but if you don’t plan on doing too many of these html emails, there’s a free download at Microsoft’s that you can use as a trial for 90 days or so. Otherwise, purchase your copy legit … or find somewhere that will assist you in a … *cough* … longer “trial period“.
- If it’s in the budget – sign up for a screenshot generator. If you’re tasked with testing your table-bloated masterpiece in more obscure email clients – Lotus, or Lotus Notes – whatever it’s called. Outlook 2003. The aforementioned AOL. You might want to invest in an account at one of the screenshot generator testing sites like BrowserCam, Litmus or CampaignMonitor. Of those three I only plunked money down to try CampaignMonitor – which worked, but the screenshots were of varying quality. Some were half-generated. One looked like someone hit “ctrl-A” before the screenshot was taken. Very odd, but it did the trick to somewhat guess how things were looking. If I were to try any of those others instead I would probably go with Litmus. Again – ymmv.
The following are the gotchas and tips I’ve become familiar with recently through the course of developing a handful of these emails. These somewhat defy the logic you might be used to when developing for the regular web – a medium that’s already tricky and nuanced. Coding for email clients is downright dumb in comparison.
- Plan and internally conceptualize your tables. Lots and lots of tables, obviously. Look at the PSD handed off to you and, in your head, plan ahead of time how you’re going to tackle the layout. Don’t try and get cute with an overabundance of col and rowspans. It will only make things more difficult over time. I found myself starting with a main outer table shell consisting of a few rows and cells to get the content justified.
- Table cells that consist of just an image – make sure those images are all aligned left (or right, if you are so inclined). Some current generation browsers will leave a gap after the bottom of the image for some reason, regardless of white-space in your markup. Sure, <td><img /></td> might look great, but it will still jack up your already delicate table layout. So remember, aligning the image will fix this.
- Background images. Completely forget about them. They are dead to you. If you want this email to look flawless in Outlook 2007, there are no such thing as background images – either via inline CSS or the background property for TD’s. I hope you enjoy the slicing tool in Photoshop because you’re going to end up rather proficient in it by the time you’re done. Because of this I suggest you become friendly with whoever is designing the comp you’ll be developing. Possibly send them flowers or take them out to a nice lunch. Otherwise the possibility is quite real that you’ll receive a comp with copy floating all over and on top of arbitrary visual elements.
- On a similar note – familiarize yourself with what is supported in the various email clients. Campaign Monitor has put together a rather handy matrix of email clients versus the CSS that is and is not supported. Read through this as a primer and have it tucked away for future use – you’ll probably need it. Also at Campaign Monitor – a collection of free email templates you may download as reference, or possibly (if you bribe them), a basis for your designer to use as “inspiration”.
- Don’t expect an inline style at the outermost TD declaring the font information to cascade into your inner table soup. Somewhere in your code I suggest wrapping some comments around a collection of what you anticipate being a common set of inline style attributes. This will allow quick access to copy and paste into your <td>’s, <p>’s, <span>’s, etc.
- And finally – Comments. Be kind with your use of comments for the express purpose of landmarking where things are in your markup. Front-end development in 2010 is a beautiful thing and we forget how miserable it used to be 6+ years ago. Over 25k in html alone is a hard thing to imagine these days, but when you get up to that you’ll thank yourself if you’ve placed gigantic honkin’ comments telling yourself where the left and right content starts and ends.
Final thoughts – You will no longer take for granted the wonder and beauty that is good, clean, lovely, semantic markup. It absolutely boggles the mind that corporate IT managers will fall over themselves getting new versions of Office rolled out to their IT infrastructure, but OMG A POX ON NEW VERSIONS OF INTERNET EXPLORER (OH THE HORROR!).
Last but not least – know where the closest liquor/booze/package store is. You’ll need a drink or two by the time this is over.
(hat tip to @bmenoza for the nudge in getting this post up)