Recent convert to RoR and I've been using Compass w/ Blueprint to dip into the proverbial pool. Compass has been fantastic, but I've come across something strange within the Typography library.
The blueprint-typography-body mixin contains the following:
=blueprint-typography-body($font-size: $blueprint-font-size)
line-height: 1.5
+normal-text
font-size: 100% * $font-size / 16px
My question revolves around "font-size." I'm a bit lost, as I would expect to pass in a font size and have that size reflected upon page load. However, in this scenario the formula seems to dictate a percentage against the default font.
ie:
+blueprint-typography-body(10px) //produces 7.5px off of the default font size of 12px from what I can tell.
In essence, I'm curious if there is a standard to setting font size within Compass other than explicitly declaring "font-size: 10px".
Note: The reason I'm leaning towards Blueprint/Compass font stylings is due to the standardization of line-heights, fonts and colors.
To be honest, the compass port of the blueprint typography is not fully configurable yet. So changing that default is probably not going to give you a proper font rhythm.
However, The next release of susy has a fully configurable vertical rhythm module that I helped build and it's pretty nice.
Susy
Vertical Rhythm Module
Just read in the discussion on Compass documentation (Julio Antúnez's comment) that you can adjust font sizes like this:
#import "compass/typography"
$base-font-size: 14px
$base-line-height: 21px
header h1
+adjust-font-size-to(18px)
Not sure this is recommended way but it works for me. I just started using Compass & Blueprint so above might cause problems elsewhere.
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.
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 have this swf of map locations. However, I didn't put the map background inside the swf since it will be too big and I won't be able to convert it. Now the problem is the swiffy background can't be transparent even if I remove the backgroundColor. Replacing the v5.2 to 5.1 making the whole locations icon disappear and the whole thing become black.
I have the same map with different function that I converted in 5.1 and it's still working well. Is there any way to convert my new map using v5.1?
Yeah, relying on a online "compiler" makes large product development and maintenance darn near impossible or at least terribly frustrating. I've asked Google numerous times for a stand alone compiler, and they aren't interested in sharing it right now. We've just got to move along with them and rebuild every file with each update for reasons similar to yours.
Here is a possible work-around for you:
<style type="text/css" media="screen">
#div > *:first-child {
background-color: transparent !important;
}
</style>
In working with a piece of legacy javascript, I've discovered that the only way to style a particular control is to set it's background image. This makes it a pain to support more than a couple of different background colors. What I'd like to do, then, is have compass generate the image at compile-time, and inline it as a data-uri. To a compass n00b, this seems reasonable, since each "background image" is just a square swatch of solid color.
Does anyone know of a project out there to automate this? Is it even a reasonable approach? If the "generate all the images in advance" approach is really the best, then I could probably manage that, but it seems far less elegant.
Thanks.
Use the compass-rgbapng like this:
body {
#include rgba-background-inline(rgba(0,0,0,1));
}
do You have any elegant approach to benefit from CSS3 features, like border radius or gradients?
I am looking for a solution that would avoid browser-specific CSS properties and browser-specific stylesheet files. I find them both hard to maintain and too verbose.
It could be a Javascript library that would take care of cross-browser compatibilit. Thus, I could use only W3C CSS3 properties support (not browser-specific) and get rid of the library when browsers will start tu support CSS3 well.
So far, I have found these resources that seem to fulfill at least some of my expectations:
eCSStender - JS that is told to imitate the CSS3 features on different browsers (even IE6), I haven't tested yet, however (read about eCSStender)
Mordernizr - JS that detects which CSS3 properties the browser supports
... I'll fiil it with your answers
Or maybe you have other approach that lets You take advantage of CSS3 without very verbose code?
You could use LESS, which has a border-radius example on their homepage:
.rounded_corners (#radius: 5px) {
-moz-border-radius: #radius;
-webkit-border-radius: #radius;
border-radius: #radius;
}
#header {
.rounded_corners;
}
However, I really don't find it that messy to use browser prefixes. For a border-radius, the only thing you need is this:
-webkit-border-radius: 5px;
-moz-border-radius: 5px;
border-radius: 5px;
That will work in about a dozen browsers (if you include mobile browsers). Using indentation in this fashion also makes it easier not to forget to update one of the properties. When you decide do drop support for Safari 4 or whatever, you can simply search and replace the rules you want to remove from your CSS files.
Compare that to when we needed box model hacks, NS4, IE5/Mac fixes, and all of that crap.
This is not CSS3 specific, but as you are asking for a concise way to handle the styles and do mention modernizr (which works by adding classes like no-borderradius to your <html> element if that feature is not available), I thought it might be helpful for a generally improved way to organize your CSS.
There is LESS that allows the use of variables, mixins or nested rules in CSS (see the link for examples). This however requires you to compile your .less files into valid .css. To avoid this, there is/will be less.js (see also: Less.js Will Obsolete CSS) which enables you to include .less files directly in your page (useful at least during development).
I think LESS does not require you to learn a lot of new syntax rules and might help to organize fallback CSS right next to the "real" style.