1. 5

  2. 4

    This article has some weird information. First this media query is given as an example:

    @media only screen and (-moz-min-device-pixel-ratio: 2),
           only screen and (-o-min-device-pixel-ratio:2/1),
           only screen and (-webkit-min-device-pixel-ratio:2),
           only screen and (min-device-pixel-ratio:2),
           only screen and (min-resolution:2dppx),
           only screen and (min-resolution:192dpi) {
      .social-icons {
        background-size: 165px 276px;
      .sprite.weather {
        background-image: url("data:image/png;base64,...");
        background-size: 260px 28px;
      .menu-icons {
        background-image: url("data:image/png;base64,...");
        background-size: 200px 276px;

    The reason this query is so wrong isn’t the Base64, but all those non-standard media features. We have a resolution feature for media queries.

    But that’s not why they consider this monstrosity of a query bad. Instead they say:

    All users, whether on retina devices or not (heck, even users with browsers that don’t even support media queries), will be forced to download that extra 18K of CSS before their browser can even begin putting a page together for them.

    Base64 encoded assets will always be downloaded, even if they’re never used. That’s wasteful at best, but when you consider that it’s waste that actually blocks rendering, it’s even worse.

    Well of course that’s what happens if you choose to inline your media queries inside your other CSS files perhaps! What about splitting the CSS that goes inside that media query into its own file, and putting the responsive condition in the media="" attribute of the <link> element linking to that CSS? Is the problem still present then?

    It seems like this really isn’t a problem if you read the media queries spec: https://drafts.csswg.org/mediaqueries/#media