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. :-(
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; }
}
Comments
Comment #1
JohnAlbinThis looks way better then the bare-bones respond-to() mixin. https://github.com/canarymason/breakpoint
Comment #2
echoz CreditAttribution: echoz commentedSass 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
Comment #3
JohnAlbinWOO-HOO!
Comment #4
JohnAlbinTo 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.
Comment #5
rcaracaus CreditAttribution: rcaracaus commentedI 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.
Comment #6
KrisBulman CreditAttribution: KrisBulman commentedWe 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
Comment #7
gmclelland CreditAttribution: gmclelland commentedConsidering 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?
Comment #8
rcaracaus CreditAttribution: rcaracaus commentedI 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.
Comment #9
KrisBulman CreditAttribution: KrisBulman commentedpatch is 0 bytes?
Comment #10
rcaracaus CreditAttribution: rcaracaus commentedoops, here is the patch
Comment #11
FiNeX CreditAttribution: FiNeX commented@rcaracaus: your patch looks fine but why are you doing this:
even if "handhelds" is never used?
Comment #12
rcaracaus CreditAttribution: rcaracaus commentedThat 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.
Comment #13
FiNeX CreditAttribution: FiNeX commented"both-screens" could be useful in some cases, but wouldn't be more useful to specify even the "small-screens" style? We would have:
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:
Comment #14
rcaracaus CreditAttribution: rcaracaus commentedSorry 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.
Comment #15
FiNeX CreditAttribution: FiNeX commentedThanks 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.
Comment #16
echoz CreditAttribution: echoz commentedExcited 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.
Comment #17
gavin.hughes CreditAttribution: gavin.hughes commentedHere 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,
Comment #18
barraponto CreditAttribution: barraponto commentedWhat about Snugug's respond-to? https://github.com/Snugug/respond-to
Comment #19
rcaracaus CreditAttribution: rcaracaus commentedI 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.
Comment #20
JohnAlbinI finally got to try out Breakpoint on a project. Simple. Effective. Love it.
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.Comment #21
JohnAlbinSince 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.
Comment #22
rcaracaus CreditAttribution: rcaracaus commentedSo 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?
Comment #23
KrisBulman CreditAttribution: KrisBulman commentedI 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
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.
I'd recommend not checking in Gemfile.lock to the repo.
The readme could state something to the effect of:
Comment #24
steinmb CreditAttribution: steinmb as a volunteer commentedComment #25
JohnAlbin