Allow nesting of media queries, magically. about breakpoint HOT 3 CLOSED

Isn't there already support for this?

Something along the lines of:

$small: 500px;
$large: 900px;
$medium: $small $large-1;


@include breakpoint($small) {
  -foo: bar;
}
@include breakpoint($medium) {
  -baz: stuff;
}

from breakpoint.

Wrote up a longer response to this, but it's gone missing. I'll give the long and short of it now:

Currently, you can nest breakpoint mixins to your heart's content and they'll work identically to how Sass nests media queries (although we have yet to write code to have breakpoint-get-context working under this scenario). I'm very concerned about magic destructive manipulation like what is proposed. This kind of thing becomes exceedingly hard to debug very quickly as the transformation is both a subtle one and a non-directed one (the conversion to ems, for instance, is both non-subtle and behind a flag, making it very easy to spot, done intentionally w/o the possibility that it was done by accident, and fairly easy to debug). This also changes how Sass natively handles nested media queries, and I'm not entirely sure I like that. I also do not like the idea that, as proposed, it seems to only work with width queries; it would need to work with all features that allow for min/max queries. One of the largest challenges one would have going to implement this is aspect-ratio both allows for min/max queries and must be written as strings and we don't want to add additional Ruby functions to accomplish new functionality.

@canarymason What are your thoughts?

from breakpoint.

This feels like it goes in the 'too clever by half' category. Since it disrupts the normal Sass nested MQ behavior I'd like it to solve a much larger problem than it does. It's currently pretty easy to write the MQ's you want Your proposal makes for some pretty code, but I don't think it makes writing the code much faster or very much easier to write. Once you add a few other tests to these nested queries I think it might even lose those benefits. I agree with all the points @Snugug raises. That said I'm not 100% opposed to it under some conditions:

• I'd like to see some examples of how this will work with more complex examples
• needs to be behind a very clear settings flag
• needs to support all (and complex) nested queries. I don't want this to only support the default test.
• I don't want the source code to get terribly complex to support this. I would have to be well compartmentalized.
• no new Ruby. we're trying to move away from the Compass dependency.

from breakpoint.