I'm hacking some SASS code (I've never seen any SASS before, I've only used plain old CSS2 in the past) and feel like I don't really understand what does #include media-query($variable) mean. I've tried googling it but surprisingly it doesn't seem to find any kind of manual or example for this code. As far as I understand it is used to define a medium-specific rule to apply a different style when the web page is rendered on a mobile device and in fact this is what I need but I feel like I have to understand the exact meaning of the code to use it correctly.
#include media-query($variable)
is a mixin call.
you should have somewhere in your sass files a mixin declaration like this:
#mixin media-query($variable) {
// ...
}
Related
So I am on the fence about learning SASS. I still don't get it. Why bother if I can write CSS and understand it and it works.
Why learn to raise chickens if all I want is the egg?
It seems as though the SASS would take longer to figure out then just writing the css.
I can use variables in CSS3. I also don't understand why you would write .foo {padding: $width/2;}
I have to figure out what padding I want then figure out the mathematical equation to write it. I just want to write padding: 12px; and be done...
Please enlighten me on WHAT Makes SASS better? quicker? easier?
thanks -
Advantages are like this
You can separate your sass files into modular areas. For instance
SASS
1. tools (put bourbon or bitters here)
2. basics (body, links or common things)
3. modules (reuasable stuff. Boxes, cards, etc)
4. layouts (your containers, footers, headers etc)
In doing this you can easily find where the CSS is that you may want to change. There are several youtube videos that discuss how to make modular sass directorys.
You can use variables. Suppose you have a color that is used several times in a CSS file. SASS allows you to change one variable and that would change all instances of that usage. $red: #ff0000 is an example of a variable. When you use it, just use
color: $red
Mixins are functions that you can use and easily create a small amount of sass that will convert into large amounts of CSS.
I suggest watching videos on youtube to learn it. You wont be sorry. Especially learn modular usage like SMACSS
Here is a link to a vid that will help you
Sass is an extension of CSS that adds power and elegance to the basic language. It allows you to use variables, nested rules, mixins, inline imports, and more, all with a fully CSS-compatible syntax. Sass helps keep large stylesheets well-organized, and get small stylesheets up and running quickly, particularly with the help of the Compass style library.
If you choose to stick with CSS, there is nothing wrong with that. (My understanding is that) People like SASS because they can type is with variables and such and it will then be converted into regular CSS. So yes, it does basically the same thing, but the improvements come as writing it, which is faster and more efficient. People that use SASS like that they don't have to write the same or similar things, they can instead just use SASS and get it converted to CSS which is faster than writing it, now I am just a SASS beginner, so please don't read into my thoughts that much, some of this may be not 100% correct, but it is my understanding. In my opinion, you should look into SASS and maybe try it a little, if you find it is more efficient and you like it more, stick with it, but if you decide it just isn't for you, then just stick with CSS.
Im working on a new project and started to use grunt-sass instead of grunt-contrib-sass because its alot faster. I also removed compass. The thing now is that i cannot find a way to add 'susy' grid and 'breakpoint' anymore. I used to put this in a config.rb file but im not using this anymore because im not using compass.
So i added all susy style in my project and thats works fine but its not my preferred method. But cant find a way to add breakpoint.
Is there a way to add these? Or do i have to use compass for this?
Sorry for my bad english, not very good at it.
No need for Compass, there's a new susy-media breakpoint Mixin designed to work with LibSass which is what you are essentially using via grunt-sass. That's what I use and it works great. So you'd define some Susy grid variables and breakpoints in a _vars.scss partial for example:
// Define susy.
$susy: (
columns: 12,
gutters: .8,
);
// Define some breakpoints.
$bp-narrow: 30em; // 480px
$bp-med: 48em; // 768px
Now put it all together, say in _layout.scss for example:
// the breakpoint (media query)
#include susy-media($bp-med) {
// now a grid
.l-foobar-wrap {
.foo {
#include span(7)
}
.bar {
#include span(5 at 8)
}
}
}
For more info, read the susy docs, it's all there for you and this works with grunt-sass (LibSass). It's part of my everyday workflow.
Note, as an alternative for really nice media query rendering and retina workflows, I now use Include Media rather than susy-media and it also works fine with LibSass.
I use Singluritygs and Breakpoints (with the included respond-to) and I want my global gutter width to change according to those breakpoints.
I thought this would work, but it doesn't:
$breakpoints: add-breakpoint('small', 768px);
#include add-grid(12);
#include add-gutter(1);
#include respond-to('small') {
#include add-gutter(1/2);
}
Am I approaching this the wrong way?
Note that adding a grid does work using this technique:
#include respond-to('small') {
#include grid-span(9, 4);
}
Problem and solution
Singularity is not compatible with Respond-To. Or, to be more precise, Respond-To does not provide functionality required by Singularity.
The correct way of defining responsive gutters is described here and looks like this:
#include add-gutter(.25 at 900px);.
Responsive grids and gutters should be defined on top of your Sass, alongside mobile-first grids and gutters.
Example:
$bp-small: 768px;
#include add-grid(12);
#include add-gutter(1);
#include add-gutter(1/2 at $bp-small);
.foo {
#include float-span(1);
#include breakpoint($bp-small) {
#include float-span(1);
}
}
Demo:
http://sassmeister.com/gist/b49bd305f029afe9cd68
Update 1
davidpauljunior
I thought Singlurity was compatible with respond-to, I'm using it to successfully add new grids - see my added note in the question. The docs say that for reponsive grids use Breakpoint, and Breakpoint includes Repond-to in it (github.com/Team-Sass/breakpoint/wiki/Respond-To).
You were doing it wrong.
Singularity maintains a list of grid definitions for various breakpoints (and another list for gutter definitions). When spanning, Singularity asks Breakpoint for the context (current breakpoint) and retrieves corresponding grid and gutter definitions from lists.
When used with Respond-To, Singularity is unable to retrieve the context and considers that it spans item in the mobile-first context.
Instead populating the grid/gutter definition lists with defintions for each breakpoint, you had only one entry in the list -- the mobile first one.
By reapplying add-gutter() inside a media query, you thought that you were setting the gutter definition for that media query. But instead you were overwriting the mobile-first grid definition globally. And due to Respond-To not reporting context to Singularity, it was using the mobile first definition inside the media query.
This is a valid approach per se. In fact, i've being actively using it with Singularity 1.0. But it has an obvious downside: due to the fact that grid/gutter definitions are overridden globally, you end up needing to reapply add-grid() and add-gutter() before every usage of spanning mixins, otherwise there's a change that Singularity will be using definitions that you don't expect. This is especially the case if you organize your Sass code in a large number of small files.
I suggest that you investigate two extensions that i wrote:
Breakpoint Slicer -- a very quick and efficient syntax for Breakpoint. It's better than Respond-To, and has full support for Singularity.
Singularity Quick Spanner -- a tool with a number of shortcut mixins for Singularity. One of them is designed to ease the approach of reapplying grid/gutter definitions every time.
Update 2
davidpauljunior
I still don't see why if grids can be redefined globally within Respond-to media queries, why gutters can't. Also, you said I only have 1 entry 'the mobile first one', but that entry was the screen size after mobile first (768px).
You have to understand that #include add-gutter(1/2); overwrites the mobile-first gutter definition regardless of whether you execute it inside a media query or not.
Above i have already explained (and provided a link to documentation) how media query-aware grids and gutters should be defined. Repeating:
lolmaus
The correct way of defining responsive gutters is described here and looks like this:
`#include add-gutter(.25 at 900px);`.
This is how your initial attempt actually works: http://sassmeister.com/gist/c530dfe7c249fad254e9 Please study this example and its output, i hope you will understand now.
davidpauljunior
The idea was that for no media query (mobile first) it would take the global gutter, for my first media query (768 and up) I would reset the global gutter and so on. I've set them all using variables now. Perhaps I'm just missing something about Respond-To.
Again, i have already said that this is a valid approach. My last SassMeister link proves that it is already working for your initial attempt.
And Respond-To is suitable for this situation: it doesn't report the media query context to Singularity, but you're not having Singularity take the media query context into account, you're having it use only the mobile-first definition all the time.
Just don't forget to reapply grids and gutters every time you span a new element, just to make sure that you're doing it in the desired context.
You can make the job of resetting the grid/gutter definitions easier with my reset-grid() helper.
I recently started using bootstrap SCSS on my node project. So I have app/bower_components/bootstrap-sass/lib/_glyphicons.scss for example.
Looking at my CSS output I see things like:
#media -sass-debug-info{filename{font-family:file\:\/\/\/home\/some\/path\/project\/app\/bower_components\/bootstrap-sass\/lib\/_normalize\.scss}line{font-family:\0000332}}
audio,
canvas,
video {
display: inline-block;
}
I have 2 questions:
This seems like a security hole. Everyone can deduce something about my OS and directory structure simply by looking at my CSS. What is the correct way to close this security hole?
How does it work? I nearly got it figured out, but I am missing something. Looking at the SCSS, I see bootstrap is using $icon-font-path which apparently turns into this absolute path. Looking at compass documentation, I see they provide absolute values but no $icon-font-path
This is the piece of code I am referring to:
#font-face {
font-family: 'Glyphicons Halflings';
src: url('#{$icon-font-path}#{$icon-font-name}.eot');
src: url('#{$icon-font-path}#{$icon-font-name}.eot?#iefix') format('embedded-opentype'),
url('#{$icon-font-path}#{$icon-font-name}.woff') format('woff'),
url('#{$icon-font-path}#{$icon-font-name}.ttf') format('truetype'),
url('#{$icon-font-path}#{$icon-font-name}.svg#glyphicons-halflingsregular') format('svg');
}
Both answers are correct. To sum it up, there's no magic.
Bootstrap initializes $icon-font-path with a default value.
if you include bootstrap's SCSS in a manager that requires a different value for $icon-font-path you should also override their default value.
The syntax $icon-font-path: some_value !default; means - use this value if not already set.
So when you include you should do the following
/* override icon-font-path value and include scss */
$icon-font-path: bower_components/bootstrap/fonts;
#include bower_components/bootstrap/bootstrap.scss;
paths might be different in real scenarios.
This seems to be a standard mechanism for publishing a reusable SCSS modules.
Here is the variables file where they set the $icon-font-path variable.
It looks like $icon-font-path is set to the foldername of the font files. not necessarily a security hole because its a relative path to the fonts.
The -sass-debug-info mess is rudimentary "source mapping", so browser developer tools can show you the original line number and filename of the Sass rule that generated that CSS (instead of the line number for the generated CSS).
Firebug has a FireSass plugin that understands these annotations. I think Chrome has built-in support, but it might be behind an experimental flag.
It has nothing to do with fonts; font-family is just used because it's an easy way to shove a string into CSS in a way that's still accessible to JavaScript without actually affecting the rendering of the document. It also has nothing to do with Bootstrap; this is part of the scss compiler.
It won't be there in compressed output, which I hope you're using in production. :)
#guy mograbi: In Bootstrap-SASS-3.3.6, $icon-font-path in /bootstrap/bootstrap/_variables.scss #83 is declared like this:
$icon-font-path: if($bootstrap-sass-asset-helper, "bootstrap/", "../fonts/bootstrap/") !default;
Since $bootstrap-sass-asset-helper is not defined yet, it may be useful to include the _variables.scss before overwriting the $icon-include-path, so we can read the "settings" and overwrite the $icon-font-path together with the if() cases.
We can use something like:
#include bower_components/bootstrap/bootstrap/_variables.scss;
$icon-font-path: if($bootstrap-sass-asset-helper, "bootstrap/", "/fonts/bootstrap/");
#include bower_components/bootstrap/bootstrap.scss;
I’ve hacked around this before by writing my own mixins, but I get a feeling there must be an inbuilt method in Susy to get around this problem.
I have a mobile-first grid which uses my default $grid-padding, say 1.5em, but once I hit my first breakpoint I switch to a wider $grid-padding-tablet, perhaps 3em, and so on through other breakpoints.
In addition, some elements also use the bleed mixin to give the visual impressions of infinite width.
Is there an easy way, just using something like #include container rather than building my own media queries and mixins to accomplish this?
The built-in technique for this is the with-grid-settings mixin (documentation):
#include at-breakpoint($tablet) {
#include with-grid-settings($padding: $grid-padding-tablet) {
// your tablet code here
}
}