Scoping CSS Animations to Media Queries

By  on  

When coding my blog's redesigns, I think and design the site in device width stages, and in the following order:

  • Desktop:  all general styles, none wrapped in a media query
  • Tablet:  media query, roughly popular tablet widths
  • Phone:  media query, any width below tablet width
  • Print:  media query, mostly a bunch display: none

Since I focus on desktop and that platform is the most powerful, I generally end up adding CSS animation and transition properties to the global selectors.  While this works, a comment on CSS Animations Between Media Queries made me think otherwise:

For performance reasons, I often do exactly the opposite: scope animation css such that transitions only apply to wider widths...

He's right:  scoping your CSS animations and transitions to desktop, instead of removing those properties at smaller widths, is more maintainable and has to be more performant.  So here's how to do it:

.logo {
	width: 200px;
	height: 100px;
	display: block;
}

@media (min-width: 1024px) {
	/* Only do logo animation on desktop, otherwise don't bother */
	.logo {
		opacity: 0;
		transition: opacity 1s;
	}
	.logo.loaded {
		opacity: 1;
	}
}

The code isn't impressive but the idea is a great one, and not one I've used in the past.  We all think about making our sites look good on mobile but we need to consider another media query -- "desktop minimum".

I wouldn't consider this a case of "mobile first", which I don't subscribe to.  But specifying the scope of an animation or transition is a brilliant idea when it comes to performance!

Recent Features

Incredible Demos

  • By
    DWRequest: MooTools 1.2 AJAX Listener & Message Display

    Though MooTools 1.2 is in its second beta stage, its basic syntax and theory changes have been hashed out. The JavaScript library continues to improve and become more flexible. Fellow DZone Zone Leader Boyan Kostadinov wrote a very useful article detailing how you can add a...

  • By
    5 More HTML5 APIs You Didn’t Know Existed

    The HTML5 revolution has provided us some awesome JavaScript and HTML APIs.  Some are APIs we knew we've needed for years, others are cutting edge mobile and desktop helpers.  Regardless of API strength or purpose, anything to help us better do our job is a...

Discussion

  1. Great post! I’ve definitely limited complex animations to larger screens for performance’s sake more than once!

    It’s probably a good idea to note that limiting *all* transitions/animations to desktop only isn’t necessary: especially if you’re being careful to only transition/animate “safe” properties (color, opacity, transform). That said, any transition/animation attached to scroll should probably be limited to desktop only (since mobile browsers aren’t entirely consistent with firing scroll events in real time). I’d be more inclined to detect that with Modernizr’s touch event than with screen size, though.

  2. This is a great idea, and easy to pull off with a media query mixin in Sass, something i’ll have to start doing with my future projects that use any animation :)

  3. MaxArt

    Yep, that’s how I usually do – when I’m not lazy, that is… *cough*

  4. Why does the screen resolution define the device type? You can have pretty high resolution on tablets (if you think outside of Apple products.)

    • First, are you suggesting that Apple’s tablets have a lower resolution than competing options? Apple introduced the whole “retina” resolution that is just now becoming popular in competing options.

      Second, resolution and screen size are not necessarily the same thing. You can have a very large screen with a very low resolution, or a very small screen with a high resolution.

  5. Drew

    It’s sort of the best we have to go on atm (until we get media queries relating to performance and network, which are, in fact, on their way!).

    It’s certainly not a given that a wide device has a lot of CPU/GPU horsepower and a thin one doesn’t, but imo a) it’s “good enough for government work” and b) the other thing about thinner devices is that there’s just not as much room for users to appreciate big multi-property layout effects anyhow, so targeting a few neat effects that are going to be right in focus is probably a better bang for your buck.

  6. JackBlackCH

    I think that thinking in “devices” in general is wrong.

    What is “mobile” nowadays? How many devices we have? A MacBook Air? A Samsung Tablet? A Macbook Pro in train? MS Surface? An iPhone7s Plus?

    I’d rather think in ranges: “small”, “medium”, “large” and “x-large”.
    In the end your content and then the design decides how you should define your viewports.

  7. In your post you said you “don’t subscribe to” the mobile first approach which is interesting and not something many people would own up to. I have felt the same for the last 3 years. It is hard though to reconcile that with Bootstrap which every team seems to want to use nowadays.

    That said, I’ve been using a ton of stuff lately that all falls into a 1200px and above media query.

Wrap your code in <pre class="{language}"></pre> tags, link to a GitHub gist, JSFiddle fiddle, or CodePen pen to embed!