Conditionally Conjoined Media Queries for Sass (just a proposal, and quite possibly a bad one)

_respond-to-ccmq.md

Conditionally Conjoined Media Queries (just a proposal, and quite possibly a bad one)

Sass 3.2 makes working with media queries a lot easier, mostly by clearing the way for mix-ins going by the name of "breakpoint" or "respond-to".

The basic pattern of defining queries and assigning them aliases that can be passed with includes that trigger full-blown rules is great, but it would also be nice if we could select/combine and otherwise extend control over these disparate rules with a little more flexibility.

Using the example respond-to below, I would love it if @include respond-to(large-screen && retina) would have the same effect as nesting these individual respond-to()'s within each other, and the rule(s) contained within would be applied when both queries matched (the screen is both large and retina).

The ability to conjoin a min and max width range of individual queries with something like respond-to(small-screen || medium-screen) would also be welcome. Or maybe even more useful, the ability to exclude a single query with something like respond-to(!mobile) ...which could generate a staggering amount of css, at the same time streamlining and simplifying the scss behind it.

But questions remain, is this a good idea, or even possible...or possibly possible in a future release of Sass. So many questions.

_respond-to.scss

$break-small: 320px;
$break-medium: 580px;
$break-large: 1234px;

@mixin respond-to($media) {
    @if $media == mobile {
        @media only screen and (max-width: $break-small) { @content; }
    }
    @else if $media == small-screen {
        @media only screen and (min-width: $break-small + 1) and (max-width: $break-medium - 1) { @content; }
    }
    @else if $media == medium-screen {
        @media only screen and (min-width: $break-medium + 1) and (max-width: $break-large - 1) { @content; }
    }
    @else if $media == large-screen {
        @media only screen and (min-width: $break-large) { @content; }
    }
    @else if $media == retina {
        @media only screen and (-webkit-min-device-pixel-ratio: 2) { @content; }
    }
}

@canarymason Your Sass is simpler and reads better... and it does exactly what my example does. But unless I am mistaken it also completely overlooks the proposal of conjoined/conditional queries as I tried to present it.

The point was not setting up breakpoints as variables, rather being able create (conjoin) different breakpoints on the fly using conditionals. So referring to my original examples ...and where I am just sketching outlines, not writing workable Sass logic... something like this:

$small = 320px
$medium = 580px
$large = 1234px
$extra-large = 1450px


---

@include breakpoint(medium && large)

Would output something like...

@media screen and (min-width: 321px) and (max-width: 1449px) { ... }

and something like...

@include breakpoint(!retina)

would ouput...

@media not screen and (-webkit-min-device-pixel-ratio: 2) {...}

...where the application of not was never set up explicity in the mixin, but generated by the Sass function or mixin on-the-fly, as instructed by the !

Still not clear if it could happen, or if it would even be a good idea...but I just want the proposal to be clear. So bear with me, and please say so if I still have not explained it, or if I have misunderstood your response.

After a second look I thought @Snugug's respond-to might cover this, but it does not.

Breakpoint and @Snugug's respond-to can handle the joining with 'and'. (They both use the Breakpoint engine.) I've updated my gist to show an example, starting at line 73. https://gist.github.com/3952907

I may be misunderstanding your intention with not (!retina), but that's also possible with breakpoint. Just with a different syntax. That syntax is interesting, but it's not possible with current Sass script. My example is on the other gist, on line 106.

There is one feature of css media queries that I know Breakpoint can't do yet, and that's chain together tests with OR, rather than AND. I don't see that expressed much in the wild tho. Still it would be nice to figure out a graceful way to incorporate that.