Using Tomorrow's CSS Today - TEDC15
•Download as PPTX, PDF•
1 like•628 views
CSS4 may only be in the working draft stage, but that doesn't mean we can't begin to use some of it's capabilities in our current email designs. Variables, color manipulation, custom media queries, and custom selectors are just a few of the powerful new features that can be utilized to take email design to the next level.
Recommended
Recommended
More Related Content
More from Brian Graves
Recently uploaded
Recently uploaded (20)
Using Tomorrow's CSS Today - TEDC15
Editor's Notes
- Throughout 2012 there was a hoax taking place on Facebook and Twitter. Someone had Photoshopped the display of the Delorian from Back to the Future II to read June 27th, 2012. Everyone, well everyone that didn’t know the movie well, posted away. All, wanting to know where there hover boards were.
- it’s 2015
- We may not have flying cars
- but we do have hover boards. just ask justin bieber or wiz.
- But we do have slightly better 3d graphics
- and thankfully we’ve all but killed off fax machines.
- and…
- except in email
- What makes people say css in email isn’t amazing?
- for a long time this was the message. code like it’s 1999. ignore stuff you can do on the web. but a lot of people have been starting to ignore this lately. brought on by the rise of iOS and Android…
- they’ve used progressive enhancement to do a lot of new, cool, and modern things. progressive enhancement - setting a baseline and then building on top of that base for more advanced clients.
- things like the very announcement email for this conference - the golden ticket email - used a linked stylesheet to update content live. including a live twitter feed and a golden ticket updates. - not like 1999
- or the one from last year, which used video as a background image.
- and some people, like RebelMail & Mark Robbins are taking this even farther. they’re using these techniques to do once unthinkable things like purchasing directly from your inbox.
- But progressive enhancement is just one aspect. Sure, it’s probably one of the most important aspects. After all, it helps us move email design and the front end forward. The part our users and customers see. But there are also parts of css geared towards making our code smaller, more modular, and easier to work with.
- a lot of these things are new even for css on the web. but if we combine these authoring tools with progressive enhancement, we can stop coding like it’s 1999 and start coding like it really is 2015, and even beyond.
- so, where are we going?
- Despite what you’ve been told - there is no CSS3 “Despite the popularity of the “CSS3” buzzword, there is actually no specification defining such a thing, like there was for CSS 2.1 or its predecessors. Instead, what most authors are referring to is an arbitrary set of Level 3 specs, plus some Level 1 specs. Although there is some good degree of consensus among authors on which specs are included in “CSS3,” as CSS modules evolve at different rates over the years, it will become more and more difficult to refer to things like CSS3, CSS4, and so on and be universally understood.”
- While trying to finish CSS 2.1, we (the CSSWG) realized that big monolithic "versions" weren't any good. They were difficult to maintain, and slow to develop. Instead, we decided to split up the CSS language into a bunch of independent modules. Each module can level up independently, and contains only a smallish set of features, so it's harder for a large set of features to be slowed down by a single stubborn feature. Some of our modules start out at level 3, if they extend something from CSS2.1. Others start out at level 1, if they're something new (for example, Flexbox). However, the level that a module is at has no correlation with what version of CSS it's in. They're all CSS3 (or just CSS), regardless of what level they're at.
- most of these updated specs focused on the visual aspects of css
- things like animation - transitions, transforms & keyframes
- typography - web fonts, hyphenation, etc
- new layout techniques like flexbox, columns, grids a lot of this stuff is hard or impossible to use in email. the client support just isn’t there.
- But beyond these things people wanted more. More than just spec updates that represented the visual front end. They wanted better authoring tools. Enter preprocessors! - browser vendors had been paying attention to the front end stuff. meanwhile, people have been building out tools to enhance things in their workflows and design systems.
- to help them do this they created preprossesors like sass sass is probably the most popular of the bunch but there’s also
- stylus preprocessors gave people the author enhancements they craved- things like variables, nesting, color functions, custom media queries
- As this was all taking place, the w3c began to take notice. But they haven’t just adopted everything from Sass et al. They’ve taken more of an in with the good out with the bad type approach.
- And now we’re at a point where many of these authoring tools are in proposed or working draft stages. Some have even made their way into browsers. That means that we’re at the beginning stages of being able to use these things in native css. Free from sass, less, or stylus
- One of thing that’s already being implemented is variables. they’ve already hit Firefox.
- if you’re used to sass variables, the syntax here may look a little different. but the basic concept is the same. if you’re not familiar, it works like this… a variable can be basically anything, but one common thing it’s used for is defining colors. So, —color-white is mapped to #fff. or in a more useful example, your brand color blue can be mapped to a specific shade of blue. that variable can then be called in your classes. if you then want to modify your color palette, you can do so all in one place.
- I would warn, however, that it’s good to have some constraint. this is a real life example of variable usage gone wrong. for one, if you have a need for that many different shades of gray, you probably have other problems with your design. but also, this example uses some pretty bad naming conventions. what is the difference between, gray 1 and gray 2? will someone picking up this project be able to tell?
- basically the general rule is this - you should know just from looking at your variable, what it represents. otherwise they lose most of their value.
- Color Module Level 4 - allow you to modify colors You may have done similar things in sass with saturation or lighten and darken functions. Essentially, color functions work like this:
- using tint as an example - what tint does is mix your base color with white. so if you have an element, say a link that’s blue like this and then you want to set a modifier of some sort. Say, a hover state or a special instance of some sort, and you want to set that modifier off of your base color, you can do so right in your css. call the color in your color function, and tint() plus the percentage of white you want to mix it with. so, essentially the amount you want to lighten it by and the result is what you see here.
- shade is more or less works the same as tint, only instead of mixing the base color with white it mixes it with black, darkening it.
- tint and shade aren’t the only things you can do, in fact this isn't even a comprehensive list, but as an example of some of the things you can do, adjust alpha channels (transparency), hsl/hwb adjustment (which i admittedly have no idea what that even means), color blending (blending two colors together, similar to shade/tint but with colors of your choosing instead of just black/white), and other newer proposals like guarantee contrast, which could come in very useful when doing things such as placing text over images where you may not know what colors are in that background image.
- color functions also become extremely powerful if you mix them with variables. you can see in the example above, we’re using tint and shade and passing them to color variables to being to create a color palette
- taking it one step further - map variables to variables
- change one value and that cascades down across your palette all in native css
- another thing that’s in a proposed state in native css that comes directly from preprocessors is the concept of nesting.
- i’ve long been a proponent of the use of nesting in email if for no other reason than this. it’s probably saved me from typing thousands of attribute selectors.
- how this works in native css more or less hinges on this use of the second set of brackets in red here. anything inside of that is “nested”. so, this…
- results in an equivalent of this. this becomes extremely powerful and useful when coding responsive emails.
- you can load modules or even just nest a flat css file with a td[class=body] and have everything play nicely without having to prepend the attribute selector to everything.
- again, like with variables, and any other authoring tool, this can be overdone. nesting too deep can result in over specified css and larger than necessary files. A good rule of thumb i’ve heard people follow when it comes to nesting is to not nest deeper than 2-3 levels. At DEG, we more or less try to follow a modular methodology. Writing modular css, among other benefits, is one of the best ways we’ve found to avoid the pitfalls of overnesting. but done correctly. also hugely powerful.
- smacss, bem slide
- useful for hover and sibling selectors
- custom media queries example easier to reference works well with “resize until it looks like shit - add a media query approach” estimate media queries and then adjust as you go also good for not having to remember the exact pixel dimensions you set your breakpoints at
- equivalent of doing…
- more real world examples of usage gone wrong - like with variables, which custom media queries basically are, they can be both overused and named poorly, making them tough to reference and understand.
- so the same concept applies to custom media queries as it does to variables
- if you look at this media query, you’re probably thinking…that doesn’t look correct. and that’s because it’s using the new >, <, and = syntax that’s available.
- mix with custom media queries
- and now for some pseudo classes
- :matches example
- :not example
- So, this is all coming to native css. And these are all intended to work at run time. Meaning they’re all intended to be understood by a browser or an email client. And we all know what that means. Lack of support.
- We all know the state of Outlook
- and Gmail
- even everyone’s favorite fanboy client has issues. - video
- and i’m sure everyone who’s coded a responsive email knows the joys of android and samsung hell
- the good news is things on that front do seem to be improving somewhat the outlook team has reached out
- gmail has talked about finally bring media queries to their apps
- and in Apple Mail, things like srcset are finally landing, making responsive images available so email clients, much like browsers in the past, seem to be starting to sit up and take notice to the changing needs of the community.
- but here’s the great thing. because a lot of these new advances are geared towards authoring, we don’t need to wait on browsers or email clients to catch up. unlike media queries, we don’t need gmail to implement variables to start using them today. would it be nice if they did and we could get them to run natively in the gmail app? sure, but it’s not necessarily a requirement for most of these things.
- Post processors make all of that future css work today. plus they give you extra super powers. I’m not going to go too in depth on this, as Aaron Ladage will have a talk on postprocessors tomorrow, but the basics are:
- animation + keyframes, transitions, perspective, etc important for email this is a real example - from an email i worked on with jim welty
- animation + keyframes, transitions, perspective, etc important for email
- • expanding your knowledge of what’s coming and what’s possible beyond email is important for being innovative in the field and the advances in authoring abilities are all part of that • it’s how you do things like litmus and carousels and kinetic email
- it’s what will help you free up your time to work on this kind of stuff. kinetic email - the new be all end all of the email world. the client side part of this is becoming supported in more and more places. i never thought i’d live to see that much green on an email support chart.
- authoring tools that make all of our lives easier and better on the development side are what will allow everyone to focus on doing golden ticket emails
- or something new that everyone loves. even a year later.
- and it’s what will allow us to create more complex and interactive emails. email can’t afford to ignore this new future and you can’t afford to not pick up these new skills. so, go out, experiment and get ahead of the game now.