2

When using Sass I would do something global like this (which I got from CSS-tricks btw)

//  Variables for MQ's

$mq-mobile-portrait     : 320px !default;
$mq-mobile-landscape    : 480px !default;
$mq-tablet-portrait     : 768px !default;
$mq-tablet-landscape    : 1024px !default;
$mq-desktop             : 1382px !default;

Then I would create mixins for the media queries like this (I'll only include a few to give you an idea

// Mixins

// Both portrait and landscape
@mixin mobile-only {
    @media (max-width : $mq-mobile-landscape) {
        @content;
    }
}

// Everything up to and including the portrait width of the phone
// Since it's the smallest query it doesn't need a min
@mixin mobile-portrait-only {
    @media (max-width : $mq-mobile-portrait) {
        @content;
    }
}

So Sass has this @content which is great because it means that I don't have to declare the content within the mixin but can do an @include mixinName and it creates the parent wrapper for any CSS properties I need to put into it across different files. I discovered that this worked well for my work flow.

So here's an example of that in a partial .scss file:

section.footer {
    height: 90px;
    padding: 0 10px;
    @include mobile-portrait-only {
        padding-top: 10px;
        background: $gum;
        div.ftrLogo {
            display: inline-block;
            margin: 0;
            height: 70px;
            width: 45%;
            div.smlLogo {
            display: block;
            background: url('../images/svg/small-logo2.svg');
            width: 106px;
            height: 49px;
            margin: 0 auto;
            padding: 0;
            }
            p.footer {
                font-size: .375em;
                color: $white;
                text-align: center;
            }
        }
}

So as you can probably gather the @content allows you to just call an empty media query wrapper anywhere in your files (obviously you have to import all of your partials into one main file) but this is great.

Today I'm using LESS on a project and I like it a lot the problem is I can't seem to find an equivalent solution in LESS-land.

I was reading up on passing rulesets http://lesscss.org/features/#detached-rulesets-feature which looks like it's close to what I want but my brain is not understanding it today; I'm optimistic about tomorrow.

If anyone has tried anything like this or can immediately see the error in my ways; please provide your two cents. I really want to figure it out and thought to ask this gifted community of SO'ers.

Thank you in advance you're a baller!

MARS
  • 305
  • 1
  • 3
  • 14
  • 1
    I think you are looking for something like [this](http://stackoverflow.com/questions/12132738/send-properties-as-argument-for-mixin/26804738#26804738). The last sample where the selector is also sent along with the ruleset is more like what you are looking for. – Harry May 25 '15 at 04:17

2 Answers2

4
//  Variables for MQ's
@mq-mobile-portrait: 320px;

// Mixins
.mobile-portrait-only(@rules) {
  @media (min-width: @mq-mobile-portrait) {
  @rules();
  } 
}

Now you can use the following code:

div {
color: white;
  .mobile-portrait-only({
    color: white;
    width: 100%;
    max-width: 500px;
   });
}

The above will compile into CSS code as follows:

div {
  color: white;
}
@media (min-width: 320px) {
  div {
    color: white;
    width: 100%;
    max-width: 500px;
  }
}

So detached rules are rules between {} assigned to a variable:

@detached: {};

Detached rules can be used as an argument for a mixin:

.mixin(@detached){}

You as call the above mixin with a detached rule as a parameter:

.mixin({color: red;});

or

 @detached: {color: red;} // watch out for the last declaration wins rule for variables  
 .mixin(@detached); 

Inside the mixin you should call the detached rules set to copy its properties and selectors (in fact you don't copy but insert them read for processing):

.mixin(@detached-rules) {
  @detached-rules(); // parenthesis are required here 
}

Finally for your example your code should look like that shown below:

    @gum: url();
    @white: white;

    //  Variables for MQ's
    @mq-mobile-portrait: 320px;

    // Mixins
    .mobile-portrait-only(@rules) {
      @media (min-width: @mq-mobile-portrait) {
      @rules();
      } 
    }


section.footer {
    height: 90px;
    padding: 0 10px;
    .mobile-portrait-only( {
        padding-top: 10px;
        background: @gum;
        div.ftrLogo {
            display: inline-block;
            margin: 0;
            height: 70px;
            width: 45%;
            div.smlLogo {
            display: block;
            background: url('../images/svg/small-logo2.svg');
            width: 106px;
            height: 49px;
            margin: 0 auto;
            padding: 0;
            }
            p.footer {
                font-size: .375em;
                color: @white;
                text-align: center;
            }
        }
        });
}
Bass Jobsen
  • 48,736
  • 16
  • 143
  • 224
0

I hadn't thought of doing it like Bass Jobsen suggested (although I've now seen that his approach is basically how the less docs do it), but I invented a mixin which I think is a bit more flexible. Though they are similar in result, I think the following solution allows for more customization and is easier to implement on the fly.

First I define the different sizes I want to use - to keep it simple, I'll just do two using a 'mobile first approach' (meaning if I don't include a media query, the rules will apply to all sizes and I should only include queries for sizes larger than mobile).

@tablet:~"(min-width:768px)";
@desktop:~"(min-width:1100px)";

Then the mixin:

.respond(@_size;@_rules){
 @media @_size {
    @_rules();
  }
}

And Used Like the following:

.selector {
    background:green;
    .respond(@tablet,{
      color:red;
      background:blue;
    });
}

And That Outputs:

.selector {
   background:green;
}
@media (min-width:768px){
   .selector{
       color:red;
       background:blue
    }
}

With only two sizes to remember, it is easy enough just to do it the way Bass Jobsen suggested, but in practice, depending on how fine-grained I want my control to be, I may define up to 8 different media sizes (though I rarely use them all), and my approach above makes the process like calling one function rather than defining 8 different functions ( as I would do were I using the alternate approach ).

Hope this helps someone. It saves me a ton of time.

Community
  • 1
  • 1
dgo
  • 3,877
  • 5
  • 34
  • 47