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.
Related
I have read about SCSS and LESS. But I can't understand the differences clearly.
I know SCSS and LESS both have more functionality of CSS (I mean extension of CSS).
What is different between SCSS and LESS?
Which one is better?
Both Sass and Less are CSS preprocessors.
From keycdn.com
A CSS preprocessor is basically a scripting language that extends CSS and then compiles it into regular CSS.
So Sass and Less don't change the functionality of CSS, as they are compiled into plain old CSS. What they do is make it easier to write and maintain CSS with tools such as mixins, nesting, variables, and more.
SCSS, which stands for 'Sassy CSS' is one of two syntaxes for Sass.
From the sass reference:
The second and older syntax, known as the indented syntax (or sometimes just "Sass"), provides a more concise way of writing CSS.
The difference
Both Sass and Less have very similar features. Sass uses Ruby whereas Less uses Javascript. There are syntactical differences, for example, Sass uses $ for variables whereas less uses #.
There are some slightly more subjective differences, this website claims that "LESS Has More User-Friendly Documentation Than Sass", however personally I have found the Sass documentation and examples very easy to use.
SCSS and LESS are both "supersets" of vanilla CSS. That means valid CSS is automatically also valid SCSS and LESS, but not necessarily the other way around.
The difference between SCSS and LESS is that they have a different syntax. They mostly have the same functionalities.
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 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>
familiarizing myself with a code base for an in-progress project that I will be joining soon. I came across this mixin being used frequently and I have a couple of questions.
1. is this a fairly standard practice or css idiom and I am just unfamiliar with it?
2. Looks like it's adding an empty space after the pseudo element for the clearfix, but why insert one :before also?
#mixin container
&:before, &:after
content: ""
display: table
&:after
clear: both
*zoom: 1
Obviously I could just wait and ask the team when I join up but I want to know now dangit! Also, if it's an idiom I should be familiar with, maybe I have some googling to do before then lol.
Thanks everyone!
You're looking at the "micro clearfix" by Nicolas Gallagher (see: http://nicolasgallagher.com/micro-clearfix-hack/). The explanation behind the :before is as follows:
This “micro clearfix” generates pseudo-elements and sets their display
to table. This creates an anonymous table-cell and a new block
formatting context that means the :before pseudo-element prevents
top-margin collapse. The :after pseudo-element is used to clear the
floats. As a result, there is no need to hide any generated content
and the total amount of code needed is reduced.
Including the :before selector is not necessary to clear the floats,
but it prevents top-margins from collapsing in modern browsers.
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.