Intermediate Articles

A Comparison of Animation Technologies

The question I am asked most frequently: what animation tool do you recommend?

Having worked with a slew of them, I can tell you there is no right answer. It's a complicated question and complicated answer. This post serves to clarify what to use, and when, to get you working with the right tool for the job.

If you’re here for React, we’ve got you covered! Jump down to the React section below and we’ll break down what to use and how to use it.

(more…)

I Learned How to be Productive in React in a Week and You Can, Too

This article is not intended for seasoned React pros, but rather, those of us who make websites for a living and are curious how React can help us reason about updating user interfaces. I’ve been intrigued by React for some time, and now that it has gained some standing in the community as well as good reviews, the time to learn it seemed justified. There are so many new technologies constantly emerging in front end development that it’s sometimes hard to know if effort into learning something new will pay off. I’ll spend this article going over what I think some of the most valuable practical takeaways are so that you can get started.

(more…)

A Guide for SVG Support in Email

We’ve talked about SVG quite a bit here on CSS-Tricks, but one area we haven’t quite touched on is email. Now that browser support for SVG is all in the green, it would be easy to assume that we can start using SVG everywhere. However, if you’ve worked with email before, you may know that it often follows way behind the web as far as feature support. You know, kinda the way California looks at North Dakota with trends: just a few years behind. :)

This article takes a deep dive into four different ways SVG can be used, and compares support for those methods across several of the most popular email applications. Let’s see where we get the most support.

(more…)

The Importance of Context-Shifting in UX Patterns

Have you ever had a day at work where you were constantly put towards a new task as you were ramping up on the current one? It feels jarring at best, and completely frustrating and time-wasting at worst. In recent years, employers at big companies have begun to consider the cost of context-shifting—the time spent re-adjusting your brain to a different task adds up, causes frustration in employees, and thus: loses money. It follows that User Experience on a website works the same way.

(more…)

Debugging CSS Keyframe Animations

Creating CSS animations may be about learning the syntax, but mastering a beautiful and intuitive-feeling animation requires a bit more nuance. Since animations command so much attention, it's important to refine our code to get the timing right and debug things when they go wrong. After tackling this problem myself, I thought I'd collect some of the tools that exist to aid in this process.

(more…)

Exposing Additional Form Fields via Checked Radio Buttons

There is a :checked pseudo class in CSS. I often think of it in connection with the "checkbox hack", in which you use it on a hidden checkbox with the ~ general sibling combinator to simulate toggling behavior without any JavaScript. It's a hack because now you have these stray form elements on the page that really aren't for a form. Not a huge deal, as I'm sure you can work around it accessibility wise, but there is a way to use this same concept in a totally non-hacky way, on an actual form!

I used this technique on the CodePen job posting form to only reveal additional form fields as needed.

(more…)

CSS Gradients

This article was originally published on March 2, 2010. It was updated April 1, 2011, July 20, 2011, and again March 3, 2014, each time to clarify and correct browser prefixes and best practices.

Just as you can declare the background of an element to be a solid color in CSS, you can also declare that background to be a gradient. Using gradients declared in CSS, rather using an actual image file, is better for control and performance.

Gradients are typically one color that fades into another, but in CSS you can control every aspect of how that happens, from the direction to the colors (as many as you want) to where those color changes happen. Let's go through it all.

(more…)

How To Deal With Vendor Prefixes

If you write CSS you almost surely need to be using vendor prefixes on some parts of the code you write in order to ensure the best browser support. Whether that is prefixed properties like -prefix-transform, prefixed at-rules like @-prefix-keyframes, or prefixes values like -prefix-linear-gradient, it's a daily chore of CSS authors.

Not only is it part of our jobs, it's an easy thing to screw up. I recently looked around at a bunch of big websites specifically looking for little nitpicky CSS3 errors and I was able to find one on any site I looked at.

So how do we author CSS so that we always are using the correct prefixes all the time?

Hand Author - Refer to CSS3Please

Hand authoring means the CSS that your sites uses in production ("live") is the CSS file that you edit yourself in a text editor. Going this route means you'll need to be including all the right vendor prefixes right in that authored file yourself. A bit tedious and error-prone for me liking, but likely scenario for most websites in the world.

If this is the case for you, your best bet is referencing an up-to-date resource like CSS3 please!. You can edit the values right on that site and copy-and-paste right into your own stylesheets.

If you do this, it means the onus is on you to keep things up to date. Prefixes aren't as volatile they once were, but a look every few months is certainly warranted.

Hand Author - Don't Prefix - Let -prefix-free do it client side

You still hand-author the CSS, but you only use the un-prefixed properties/values/at-rules. -prefix-free is a bit of JavaScript that runs, looks through all your CSS, and appends to the page new styles with the proper prefixes needed to make those styles work, if necessary.

This is holy war territory. It makes CSS files smaller! Yeah but it runs the risk of flashes of un-CSS3'd elements! It requires JavaScript for styles, crossing the streams! Yeah but it's only 2k! It's progressive enhancement at its finest since it will stop prefixing when browsers stop needing it!

You decide.

It's also worth noting that jQuery's .css() method will do some prefixing for you.

$("body").css({
  
  // Will NOT prefix
  "background": "linear-gradient(#ccc, #666)",

  // Doesn't need to, so won't
  "box-shadow": "inset 0 0 5px black",

  // WILL prefix
  "transform" : "rotate(5deg)"

});

I'm not a fan of applying CSS through JavaScript usually, but good to know as there are always exceptions to rules.

Hand Author - Fix up with Prefixr

If you prefer not hand authoring the prefixes but ultimately your workflow deploys hand-authored CSS, you could run your CSS through Prefixr before deploying. It essentially parses your CSS, finds things that need prefixing, and does it for you.

It's very smart in that you don't have to have CSS that is specifically void of prefixes (like -prefix-free requires). For example if you just happen to be missing one of the required three prefixes, it will see that and only add the missing one.

It also has ways to be added to workflows via the command line or popular text areas.

Preprocess - Use mixins

One of the big reasons to use CSS preprocessors at all is because of the help with vendor prefixing.

If you use Sass, Compass or Bourbon have robust sets of CSS3 mixins for you.

If you use LESS, I have a set of them or you could look at this roundup comparing some others.

Hand Author - Don't Prefix - Post Process with Autoprefixer

This is a really great way to do it. It's all laid out in this article. Essentially you just forget about prefixing and this build step will add the prefixes for you according to the lastest and greatest information from CanIUse.

"Don'ts"

One mistake I sometimes see is that people just use all the major prefixes on every CSS3 property. It appears they have a generic mixin that they just put everything through that slaps on the prefixes. If you've seen something like -o-border-radius, that's what I mean. That has never existed and never needs to go into your CSS.

Another mistake is letting CSS get stale. As I mentioned earlier, it's worth a look at CSS older than a couple of months to make sure it's up to snuff. If you see anything outdated on this site, please let me know and I'll update it right away.

Receding Background Modal Boxes

You all know Hakim El Hattab right? He creates some super crazy progressive demos over on his blog. His CodePen profile is full of amazing too.

One recent creation of his is Avgrund. It's a design pattern for dialog boxes in which the main page fades away and the modal box flies down from above (or up from below). The main page becomes smaller and blurry, making it seem further away ala depth of field in photography. The modal box sits on top, making it seem closer to you and clearly demand your attention. That's good, because the very purpose of modal boxes is to require a user to give you some input before they can do anything else.

avgrund

It feels pretty magical when you see and use it. Kinda makes you want to right-click and see if it's Flash. But it's not, and like many things on the web when you start digging in, the magic is just a nice combination of simple effects.

Let's look at them in order. Note: this isn't exactly how Avgrund works, it's just me reverse engineering it.

Step 1) Separate Page Markup and Modal Markup

All the content on the entire page should be contained within a wrapper div. The modal is outside of that wrapper.

<body>

  <div id="page-wrap">
    <!-- all page content -->
  </div>

  <div id="modal">
    <!-- modal box content -->
  </div>

</body>

How that markup gets there is up to you. If I was using this for real, I'd probably inject it dynamically when needed through a JavaScript thingy I create just for handling dialogs.

Step 2) State Based CSS

No need to get too fancy with JavaScript. If we think "state based", all we need is a class name on the body element and we can adjust all visual design as needed with that class. This is a larger concept that is useful in big ways and warrants further discussion (like how/where/why to trigger states), but let's just keep it simple here with a bit of jQuery:

// Something happens
$("button").on("click", function() {

  // State changes
  $("body").toggleClass("dialogIsOpen");

});

Step 3) Default State for Modal

The modal will be a fixed position box right in the middle of the screen. By default, it will be hidden (zero opacity) and unclickable (pointer-events). Let's just ignore browser support on that. If it's a big deal to you, you can hide it in any number of different other ways like positioning it off screen.

#modal {
  background: white;

  position: fixed;
  width: 50%;
  top: 50%;
  left: 50%;
  margin: -25% 0 0 -25%;

  /* Embiggen */
  transform: scale(1.5); /* prefix me */

  /* Hidden */
  opacity: 0;
  pointer-events: none;
}

Step 4) Active Modal State (The Magic!)

Now we have all we need to "recede" the page when the modal is open. Let's target the #page-wrap when the state is active and do the magic.

The magic is simply: transform scale the #page-wrap to make it smaller and filter the #page-wrap to make it blurry and less colorful.

.dialogIsOpen #page-wrap {

  /* Blur and de-color */
  -webkit-filter: blur(5px) grayscale(50%);

  /* Recede */
  -webkit-transform: scale(0.9);

}

WebKit only? Well... the filters are only in WebKit for the time being. Your call if you want to load up the vendor prefixes or not. If I was going to use this for real on a site, I'd spend a little time making sure this effect had a fallback, which shouldn't be too hard. Perhaps just an emphatic box-shadow would do.

Then: Make the dialog appear from above, enforcing the depth of field effect. Opacity makes it appear; transform scale makes it appear from above.

.dialogIsOpen #modal {
  
  /* Regular size and visible */
  transform: scale(1); /* prefix me */
  opacity: 1;

  /* Clickable */
  pointer-events: auto;

}

Step 5) Transitions

To make it feel natural and magical, toss in some transitions on both of the players involved.

#page-wrap, #modal {
  
  transition: all 0.4s ease; /* prefix me */

}

Of course Sass/Compass makes all this a bunch easier since it has @mixins for all this stuff. e.g.

@include transition(all 0.4s ease);
@include filter(blur(5px) grayscale(50%));
@include transform(scale(0.9));

Fair warning, this stuff is fairly memory/processing intensive. Sometimes little hacks like triggering 3D transforms helps in WebKit, at the risk of nasty looking text.

body {
  /* Use at your own discretion */
  -webkit-transform: translateZ(0);
}

Wrapup

A video, if you don't have access to a supported browser or whatever:

I put my reverse engineered demo from this article on CodePen, but you should really just go look at Hakim's demo, which also on CodePen.

We have a pretty good* newsletter.