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

  • By
    Interview with a Pornhub Web Developer

    Regardless of your stance on pornography, it would be impossible to deny the massive impact the adult website industry has had on pushing the web forward. From pushing the browser's video limits to pushing ads through WebSocket so ad blockers don't detect them, you have...

  • By
    CSS Animations Between Media Queries

    CSS animations are right up there with sliced bread. CSS animations are efficient because they can be hardware accelerated, they require no JavaScript overhead, and they are composed of very little CSS code. Quite often we add CSS transforms to elements via CSS during...

Incredible Demos

  • By
    Animated Progress Bars Using MooTools: dwProgressBar

    I love progress bars. It's important that I know roughly what percentage of a task is complete. I've created a highly customizable MooTools progress bar class that animates to the desired percentage. The Moo-Generated XHTML This DIV structure is extremely simple and can be controlled...

  • By
    MooTools ASCII Art

    I didn't realize that I truly was a nerd until I could admit to myself that ASCII art was better than the pieces Picasso, Monet, or Van Gogh could create.  ASCII art is unmatched in its beauty, simplicity, and ... OK, well, I'm being ridiculous;  ASCII...

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!