Menu icon Foundation
Architecting the Future of Foundation for Emails

Hey everyone,

We’re super excited about the reception that Foundation for Emails and Inky have gotten, and want to talk a little bit about where they are going. We see a future where Inky becomes the standard for how emails get written, anywhere and everywhere. One of the biggest pieces of this is making it easy to extend Inky so that everyone can build their own custom open source and proprietary email components.  While the current Inky language supports all of the core building blocks you need to create beautiful, responsive HTML emails, we have also heard many requests for additional components and the ability to extend Inky.

 

Where are we headed?

 

We believe that Email development should be just as simple as web development, where you can easily integrate open source components, extend those components with your own custom styles, and create your own custom pluggable elements. Just like a company builds up a library of custom, pluggable modules of code and components, they should be able to create a set of custom, pluggable inky tags that make generating brand-coherent, beautiful emails as easy as can be.

 

What Should Custom Inky Tags Look Like?

The question at hand is what those pluggable inky tags should look like.  We’d like them to be programming language agnostic, so that there can be native Inky implementations in languages like Ruby, Python, etc. We’d also like them to be flexible, capable of handling the multitudes of email components out in the world. Clearly there needs to be a template component, a SCSS styling component, but what else?

 

 

What are your thoughts?  What are they key components you would need? To what extent do you think they can be isolated and standalone vs needing knowledge of the rest of the structure of the email? Do you have example components you’d like to implement that we can play around with and see if this would work?

emailsfoundation for emailsinkyresponsive emailsrailsarchitecture

Hey everyone,

We’re super excited about the reception that Foundation for Emails and Inky have gotten, and want to talk a little bit about where they are going. We see a future where Inky becomes the standard for how emails get written, anywhere and everywhere. One of the biggest pieces of this is making it easy to extend Inky so that everyone can build their own custom open source and proprietary email components.  While the current Inky language supports all of the core building blocks you need to create beautiful, responsive HTML emails, we have also heard many requests for additional components and the ability to extend Inky.

 

Where are we headed?

 

We believe that Email development should be just as simple as web development, where you can easily integrate open source components, extend those components with your own custom styles, and create your own custom pluggable elements. Just like a company builds up a library of custom, pluggable modules of code and components, they should be able to create a set of custom, pluggable inky tags that make generating brand-coherent, beautiful emails as easy as can be.

 

What Should Custom Inky Tags Look Like?

The question at hand is what those pluggable inky tags should look like.  We’d like them to be programming language agnostic, so that there can be native Inky implementations in languages like Ruby, Python, etc. We’d also like them to be flexible, capable of handling the multitudes of email components out in the world. Clearly there needs to be a template component, a SCSS styling component, but what else?

 

 

What are your thoughts?  What are they key components you would need? To what extent do you think they can be isolated and standalone vs needing knowledge of the rest of the structure of the email? Do you have example components you’d like to implement that we can play around with and see if this would work?

Mark Johnston almost 2 years ago

I would suggest looking at PostCSS rather than CSS for the CSS side of things. An example of something that I really enjoy using PostCSS with is the Lost Grid system https://github.com/peterramsing/lost

Rafi Benkual almost 2 years ago

Is that because you'd use PostCSS to grab the variables from the SCSS?

COLABORATI almost 2 years ago

It would be great to see if you guys set your priorities like this:

  • fix foundation 6 for sites - there are so many issues with the F6 release, it is not funny
  • add a decent test suite for Foundation 6
  • then add some filtering to this forum software - the navigation is so limited, it is nearly impossible to find things, it is an information graveyard. One indicator for this is that people are asking the same things over and over again. Just copy and paste some old school forum board architecture and it will be much better to use. Also please add the possibility to search in posts filtered by tags, or even better add categories for F5, F6 etc, integrate the fact, that your products have versions.
  • then again go and fix F6 (all the new problems)
  • then you might slowly start think about doing something new.

On Inky: Please embrace existing standards and do not invent  "the very special zurb template language".

This comment stinks unfriendly, I know, but I write this because I totally like the core of your ideas - they are very good, indeed!

However, execution is too sloppy - you could make so much more out of it if you would try to work with more intensity, if you worked with real devotion and more seriousness on these things. This is something missing in all the Zurb products. You have good ideas, but why don't you try to get to 110%? Please, more real devotion! Again - I like your things, but I see that there is too much sloppiness. Please, try to lift yourself up to another level of production quality.

Elliott Regan over 1 year ago

Mark, a grid using calc() is too much for email clients to handle. 

Colaborati, this post is about Foundation for Emails, not Sites. Even so, I agree with everything you said. Foundation for Emails is full of show-stopping bugs that need to be fixed before any new features get implemented.

 

Kevin, just fix the bugs before adding new languages or whatever. Currently I can't use any special unicode characters (like apostrophes or ©), buttons don't always retain their shape, and there is no clear way to handle responsive images. 

Corey Schaaf over 1 year ago

"no clear way to handle responsive images"

What exactly do you mean by that? Are you saying images don't scale proportionately or are are you saying there's no way to swap an image for desktop vs small? I use retina images throughout my designs and have no problems whatsoever with responsive images. If you could clarify what you mean there, that would be helpful. 

Also, "buttons don't always retain their shape".  Are you referring to rounded corners? Which if you are, you are correct, but that's more of a progressive enhancement. While I understand your frustration, it's careless rhetoric to say that "foundation for emails is full of show-stopping bugs". 

In regards to there being lots of bugs, the company I work for has been using foundation for emails for about 2 months now. We have automated series that are running constantly and we're seeing a significant increase across the board sense we've switched. While bugs like the one you've mentioned (inlining bugs) are frustrating, they surely aren't show stoppers. 

For the record, I'm not on Foundation's payroll. I just enjoy using the framework and supporting it when I do find issues. The team at Zurb is very good about responding to issues when they come up and so is the community. 

Elliott Regan over 1 year ago

Corey, 

I'm using @2x sized images, and depending on the browser/email client, the images will either blow up to 100% width (thanks for _normalize.scss) or respect the width attribute that I need to manually add. Since I need to manually set the width attribute on images so they don't display at 2x their intended size, I can't change the size of the image at different breakpoints. I would love to see how you handle @2x images in your emails using Foundation, and hopefully I am just going about it all wrong.

 

As for the buttons, Outlook does all sorts of stuff with them. I'm OK with `border-radius` getting dropped on some clients, but the padding around the text gets dropped on Outlook.com.

 

Can you use special unicode characters? Apostrophes get converted to `'` which is just all sorts of wrong. Any other non-alphanumeric character gets the same treatment, so I need to manually replace every instance after building. 

Corey Schaaf over 1 year ago

There are currently bugs on github opened with the inlining issues your experiencing. You can follow those here: 
https://github.com/zurb/foundation-emails/issues?utf8=%E2%9C%93&q=apos

I'm not experiencing the same problems as you with buttons in emails. here is a test I ran with them: https://www.emailonacid.com/app/acidtest/display/summary/IkIShsfJzlzcWeFzRFezoqKh9l0JqgAreKMTvBXdTrR5K/shared

note that not all lotus clients are supported in Foundation for Emails. 

Here is an example of an email I recently put together where we are using retina images without any problems. 
http://links.tacticalgear.com/q/sNcO9bu_gqk8-ThAUc6JXBF_wWaqOYbMmkhsDR3nWMQsPheQt4Xg-hhSs

(note all images are twice the size of the container on desktop). On small devices they are 100% of the viewport. 

 

 

Mark Johnston over 1 year ago

Elliott I said Lost Grid was a PostCSS implementation I liked using, I didn't ask for it to be implemented in Zurb emails. The fact that it outputs as Calc is irrelevant. 

Ryan Moore 12 months ago

I would love to see Inky add a 'plugin' feature. The beauty of Inky for me is that I can easily revert to nested tables where Inky can't help me, but it would be great to be able to whip up a custom component for those I use regularly and thus save time.

Perhaps adopting a parent-child structure to the componentFactory to allow easy customisation that survives updates?