With Sass 3.1, you have to hard-code all of your media queries. You can't abstract any of the breakpoints into variables or anything. :-(

Canary Mason says:

You should note, however, that you can’t use variables in the [media] query declaration itself. It would be nice to write the following, but it won’t work.

$breakpoint: 1024px;
@media screen and (min-width: $breakpoint) {
  content: "this won't work :(";

But with Sass 3.2, you'll be able to use variables in media queries and we'll have the @content block feature of mixins.

Canary Mason has a good write up of all of this at http://thesassway.com/intermediate/responsive-web-design-in-sass-using-m...

I'd suggest we add the respond-to() mixin to the _custom partial.

$break-small: 480px;
$break-large: 800px;
@mixin respond-to($media) {
  @if $media == small {
    @media all and (max-width: $break-small) { @content; }
  @else if $media == medium {
    @media all and (min-width: $break-small + 1) and (max-width: $break-large - 1) { @content; }
  // etc.
.profile-pic {
  width: 250px;
  @include respond-to(small) { width: 100%; }
  @include respond-to(medium) { width: 125px; }


Title:Add respond-to() mixin after release of Sass 3.2Add breakpoint mixins after release of Sass 3.2

This looks way better then the bare-bones respond-to() mixin. https://github.com/canarymason/breakpoint

Sass 3.2 has been released :-) http://sass-lang.com/docs/yardoc/file.SASS_CHANGELOG.html
Also for placeholder selectors for #1713172: Add SMACSS-style classes to tabs

Status:Postponed» Active


To be honest, I haven't had time to play with breakpoint since I was waiting for Sass 3.2. But the syntax looked exactly like what I would want in a breakpoint-management mixin.

Would love to see some people test it out and report back. :-D I'd really like this in Zen 7.x-5.2 if possible.

I use these mixins, they are awesome. I am using one stylesheet for my responsive designs now instead of multiple because I can neatly stack css for all displays in one area. I think that they should be included in zen.

We should consider what options we want to take for IE8 conditional layouts before either adopting breakpoint, or creating our own solution related to #1539682: Turn off Respond.js by default, use .lt-ie9 rules for IE8 layouts

Considering the goal of #1540948: Catch up with the Panels Everywhere integration

Keep in mind that Panels module doesn't yet provide a way to have conditional css files added to panels layouts. See #1184698: Custom layout with conditional stylesheets

So it might be better to go the route of using the .lt-ie9 classes unless someone wants to patch panels?

new0 bytes

I have added the barebone respond-to() mixins. It shouldn't change the CSS that compiled. I also added some breakpoint variables. These aren't 100% necessary, but I figured Why not? Would love some feedback. I will evaluate that breakpoint if anyone has tried it out and likes it and can submit a patch. Let me know.

patch is 0 bytes?

new1.66 KB

oops, here is the patch

@rcaracaus: your patch looks fine but why are you doing this:

@if $media == handhelds {
    @media only screen and (max-width: $break-small - 1) { @content; }

even if "handhelds" is never used?

That is a good point.. I was using $media == handhelds for another project, you are right, it is not needed here.

However I have also added a "both-screens" variable, to get rid of the min-width old mediaquery still being called.

I think having these semantic names will make it easier to understand.

I am happy to take the "both-screens" mixin out, let me know what you think.

"both-screens" could be useful in some cases, but wouldn't be more useful to specify even the "small-screens" style? We would have:

  • small
  • medium
  • wide

And the fourth special case for handling in the same way medium+wide screens.

P.S: warning, you've added two times the wide-screens selector:

+  @else if $media == wide-screens {
+    @media only screen and (min-width: $break-large) { @content; }
+  }
+  @else if $media == wide-screens {
+    @media only screen and (min-width: $break-large) { @content; }
+  }

Sorry about that, I have taken your considerations and added the patch again, and also removed my careless duplicates. It is late, hopefully no mistakes in this one.

I have also taken away "-screens" as I feel the extra wording may be unneeded.

Status:Active» Needs review

Thanks rcaracaus, this patch looks fine, moreover I like your idea to remove the "-screens" suffix.

@JohnAlbin what do you think about this patch? It works as expected adding the support to respond-to.

Excited about this too, …asking for a bit of patience for John's focus while he leads the Drupal 8 Mobile Initiative and works on core in general until at least after D8 feature freeze, Dec 1.

new2.45 KB

Here is a patch that applies the canary mason mixin (https://github.com/canarymason/breakpoint)

I added a few variables for breakpoints and a few extra for the sake of completeness ;-)

I’m not sure if this extension should be added to the sass-extension directory as per zen-grids.
Probably more important to do this if this extension was going to be used,

What about Snugug's respond-to? https://github.com/Snugug/respond-to

I had a look a snugug's $breakpoint... It looks like it could make it so we just use variables rather than that huge respond-to mixin. I will look at submitting a patch.

I finally got to try out Breakpoint on a project. Simple. Effective. Love it.

I had a look a snugug's $breakpoint... It looks like it could make it so we just use variables rather than that huge respond-to mixin. I will look at submitting a patch.

Isn't it the other way around? breakpoint mixin uses @include breakpoint( $variable ); and respond-to would use a mixin and strings @include respond-to( thing-1, thing-2 ); I have no opinion on respond-to, since I haven't looked at it that closely.

Version:7.x-5.x-dev» 7.x-6.x-dev

Since breakpoint can't be included in sass-extensions (due to custom Ruby code), I'm moving this off to 7.x-6.x, where Zen Grids will also be removed from the sass-extensions directory. That will make things more consistent. You'll have to install Zen Grids and Breakpoint in the normal way.

So Zen-grids and Breakpoint will still be required in the config file I assume... If so will the theme come with a Gemfile to specify version?

Status:Needs review» Needs work

I think we could get around the version problem by specifying the name and version info of each required gem in a gemfile (as @rcaracaus mentioned) to give more advanced devs the option of using bundler via "bundle install" when entering the project.. it will still work fine if the other users just choose to install the correct versions alone without the install step.

Filename: Gemfile

source 'https://rubygems.org'
gem 'rb-fsevent', '~> 0.9'
gem 'compass', '~> 0.13.alpha.4'
gem "breakpoint", '~> 2.0.5'

With this method, If the user has multiple versions of gems on their system, running the following step will assure the right local gems are used during compile.

'bundle exec compass compile'

I'd recommend not checking in Gemfile.lock to the repo.

The readme could state something to the effect of:

1. Install Bundler (`gem install bundler`)
2. Run `bundle install` from the theme's directory
3. Use `bundle exec compass compile` to compile CSS or `bundle exec compass watch` to watch and recompile on the fly.
Note: If you use rvm, you may need to do `rvmsudo bundle exec compass <command>` for permissions.