Have never done this before, so my understanding may be totally off. I understand that LESS optimizes and minifies your CSS. So... is it better to just use LESS or should you still minify your files some how?
Feel free to raise other differences that I don't know about.
Less is a preprocessor, it compiles into static CSS. Less enables you to use variables and mixins which help you to write DRY and reusable code.
Example:
CSS:
p {
color:red;
}
h1 {
color: red;
}
Less:
#color: red;
p {
color: #color;
}
h1 {
color: #color;
}
If you want to use yellow instead of red you only have to change #color: red; now.
The same for mixins, Less:
.default-style() {
color: #color;
border: 1px solid black;
}
p {
.default-style();
}
h1 {
.default-style();
}
If you do not need a border for your default style any more, you will only have to remove the border property from the .default-style() mixin.
Less does not minify or optimize your (comiled) CSS code.
Since Less 2 you can use plugins that postprocess your compiled CSS code. This plugins can minify / compress or optimize your code.
For instance use clean-css (https://github.com/less/less-plugin-clean-css) for compressing and CSScomb (https://github.com/bassjobsen/less-plugin-csscomb) for optimizing.
Related
I would like to know which way of coding stylesheets is better in terms of performance, readability and everyday use case.
Let's say we want to make styles:
.container {
background-color: red;
.nested-container {
color: blue;
}
}
.container-two {
background-color: black;
.nested-container {
color: blue;
}
}
I wonder which way is more efficient for this kind of case.
/* mixins way */
#mixin duplicated-container {
.nested-container {
color: blue;
}
}
.container {
background-color: red;
#include duplicated-container;
}
.container-two {
background-color: black;
#include duplicated-container;
}
/* combined sets way */
.container {
background-color: red;
}
.container-two {
background-color: black;
}
.container,
.container-two {
.nested-container {
color: blue;
}
}
First way is much more readable, at least for me.
Second way makes output file smaller than when using mixins, because code is not duplicated in any way.
Please keep it in mind that this is just very simple example of what i want to achieve, if container and container-two are in two different places in file, first way makes it very readable and easy to play with, but it duplicates code in final output, so i'm not sure if it is good to use mixins this way.
This has been big dilemma for me for last few days and i decided to ask professionals for help, because I always end up with messy stylesheets.
I appreciate all help.
The first seems like a better choice, since classes are listed in a single place.
With the second approach, once you add a .container-three you'd have to remember to also add it to the list of classes under which .nested-container is gettings its styles from.
You should not worry about the filesize when using mixins. With a modern pipeline of CSS minifier and gzipped content being default for most servers, duplicating content in CSS does not significantly increase the filesize, and might even perform better.
Do not worry about duplicating code. It's a micro-optimisation that would be heavily optimised by gzip anyway. Go for readability in this case.
Are there any tools to compile CSS custom properties declared at not :root rule? I want following code with custom properties
.dark {
--bg-color: black;
--fg-color: white;
}
.light {
--bg-color: white;
--fg-color: black;
}
.foo {
background: var(--bg-color);
display: block;
}
.bar {
color: var(--fg-color);
display: inline;
}
be compiled to their non-custom-prop equivalents like that
.light .foo, .light.foo {
background: white;
}
.dark .foo, .dark.foo {
background: black;
}
.light .bar, .light.bar {
color: black;
}
.dark .bar, .dark.bar {
color: white;
}
.foo {
display: block;
}
.bar {
display: inline;
}
The goal is to
switch color schemes by switching dark/light class on root DOM element
use valid css syntax (no sass less)
keep rules code compact
It's actually not safe to do that. I can tell you because I tried so hard to make a safe transformation.
But I failed.
https://github.com/postcss/postcss-custom-properties/issues/1
Ideal solution. Your example is valid CSS and can be used in many browsers (not in IE, Edge (but is in development) and Opera Mini as of writing this answer, 2017-03-27, other major browsers are fine).
Suboptimal solution. Some CSS can be transpiled to achieve better browser support. The solution I found does not support variables on non-:root elements, however. There are also other objections against transpiling of 'future' CSS into 'current' CSS. To the best of my knowledge, you will have to implement your own transpiler (or postcss plugin) if you want to transpile custom properties not on the :root element, but be warned that that is hard in general. Now you don't need the general part, so it is possible. Just does, to the best of my knowledge, not exist yet.
Preprocessing solution. Of course, you don't need a general implementation of custom properties. You have different themes that have their own values for the same set of properties and that's it. Thus, a separate stylesheet can be created as a preprocessing step using any CSS preprocessor.
Now you say the following,
use valid css syntax (no sass less)
but I am going to show this anyway, because I believe that it is a valid solution to your problem. It is definitely the only one I know that actually works if you want to/need to support IE, Edge and/or older versions of other major browsers (Firefox < 31, Chrome < 49, Safari < 9.1, Opera < 36)
You could do this using SASS for example, to do the transpiling on the server side.
// define styles, use variables throughout them
// your entire style definition goes into this mixin
#mixin myStyles($fg-color, $bg-color) {
.foo {
display: block;
background: $bg-color;
}
.bar {
display: inline;
color: $fg-color;
}
}
// define themes, that set variables for the above styles
// use named arguments for clarity
.dark {
#include myStyles(
$fg-color: white,
$bg-color: black
);
}
.light {
#include myStyles(
$fg-color: black,
$bg-color: white
);
}
This compiles to the following.
.dark .foo {
display: block;
background: black;
}
.dark .bar {
display: inline;
color: white;
}
.light .foo {
display: block;
background: white;
}
.light .bar {
display: inline;
color: black;
}
This is not exactly what you want to obtain, but very close. Realistically, I think this is the closest you will get to obtaining your desired output. I know you want to
keep rules code compact
but what you are saying there (I think) is that you want to split out custom properties from their rules to save on number of rules, which is not something any preprocessor I know supports.
You can organize your source SASS in separate files to keep an overview easily. You can even set up a build system that generates a separate stylesheet for every theme you have. It is then possible to have your users select an alternative stylesheet. Browsers have some support for this, but switching using JavaScript is also definitely possible in the latter case. Simply set all stylesheets to be disabled except for the selected one. Here is an example.
With the LESS preprocessor, you can nest CSS code inside other CSS code, like this:
.Element {
.AnotherElement {
background-color: #FFF;
}
.YetAnotherElement {
background-color: #000;
}
}
This would make the background of .Element .AnotherElement white, and it makes .Element .YetAnotherElement have a background color of black. It does it all without writing it out like:
.Element .AnotherElement {
background-color: #FFF;
}
.Element .YetAnotherElement {
background-color: #000;
}
Does the first example coincide with CSS syntax, or do I have to use the LESS preprocessor?
Nesting is a feature of LESS and SASS, not native to CSS.
This is one of the most common uses for CSS preprocessors, but they offer a lot more too.
No, css doesn't support this syntax, in your css example the "Element" and "AnotherElement" will to receive this properties, AnotherElement will not inherit properties of Element.
I'm using the SASS port of Bootstrap, and I'm wondering if there's any difference between using the pre-defined mixins and using SASS's #extend.
For instance, if I have:
<div class="wrapper">
Some content here....
</div>
Is there any difference between doing
.wrapper {
#include make-row();
}
and
.wrapper {
#extend .row;
}
?
If there's no difference, are there other mixins that aren't equivalent to a single #extend statement? If there aren't such mixins, why do the mixins even exist?
The big difference between #extend and a mixin is the way the css is compiled. It doesn't look like much in simple examples, but the differences and implications are significant and can be a real headache in the wild if used carelessly. #extend is a little bit like fools gold, looks great at first, but ...
Let's look at a simple example:
#extend
.row {
width: 50px;
}
.new-row {
#extend .row;
}
.another-row {
#extend .row;
}
compiles into:
.row,
.new-row,
.another-row {
width: 50px;
}
mixin
#mixin row() {
width: 50px;
}
.new-row {
#include row();
}
.another-row {
#include row();
}
compiles into:
.new-row {
width: 50px;
}
.another-row {
width: 50px;
}
A mixin includes the properties everywhere it is hit - copying them each time - whereas an #extend groups the selectors and defines the properties once. This isn't immediately obvious, because the difference is in the compiled css but it has some important implications:
Load order
With #extend the selectors will be grouped at the first point in the sass where they are encountered which can lead to some weird over-riding. If you define a selector and use #extend to bring in a property to and try to override a property defined earlier in your sass, but after the point at which the extended properties are grouped in the css then the override will not work. This can be quite perplexing.
Consider this logically ordered set of css definitions and the likely HTML: <div class='row highlight-row'></div>:
.red-text {
color: red;
}
.row {
color: green;
}
.highlight-row {
#extend .red-text;
}
compiles into:
.red-text,
.highlight-row {
color: red;
}
.row {
color: green;
}
So even though the sass ordering makes it look like the row colour would be red, the compiled css will make it green
Poor groupings
#extend can result in poorly grouped selectors in the resulting css. You can end up with thirty or forty unrelated things all sharing the same property for example. Using #extend for fonts is a good example of this.
Nesting
If you are using deeply nested sass (which is not good, btw) and you use #extend you will duplicate the fully nested selector for every #extend you use, resulting in bloated css. I've seen this a lot:
.selector-1 .selector-2 .selector-3 .selector-4,
.selector-1 .selector-2 .selector-3 .selector-4 a,
.selector-1 .selector-2 .selector-3 .selector-4 li,
.selector-1 .selector-2 .selector-3 .selector-4 td {
font-family: arial;
}
If you're new to SASS it pays to look at the compiled css.
Media queries
#extend do not work inside media queries, because media queries are not selectors.
Conclusion
My rule of thumb is to use an #extend over a mixin if you have no parameters and if you can reasonably define the #extend and share it amongst a few tightly related selectors that exist nearby in the sass, for example, in the same file that defines a sass module. Buttons are a good example of well used #extend:
%button {
padding: 10px;
}
.call-to-action {
#extend %button;
background-color: $green;
}
.submit {
#extend %button;
background-color: $grey;
}
The best article to help make the choice is here
PS, the % sign is a use of placeholder extends
Can CSS have inheritance like OOP?
For example I have this style
.myButton {
background-color:#ffec64;
border:1px solid #ffaa22;
}
Can I define parent for color attributes? Something like
myYellow: #ffec64
So that in every styles I will just use
.myButton {
background-color:myYellow;
border:1px solid #ffaa22;
}
So that changing yellow color will only be on myYellow attribute not for every background-color attributes.
Thanks in advance
This is not possible when using CSS alone.
You can do this by using a css preprocessor like LESS or SASS. These allow for variables, mixins, functions and many other techniques that allow you to make CSS that is more maintainable, themable and extendable.
Once you have written your LESS or SASS you then need to compile it to standard css (in the case of LESS this can be done client-side).
You may need to use CSS Pre Processors like LESS or SASS.
Example Using LESS variables
#myYellow: #ffec64;
.myButton {
background-color: #myYellow;
border: 1px solid #ffaa22;
}
or even you can use LESS mixin to inherit css class.
.myCommonButton {
background-color: #myYellow;
border: 1px solid #ffaa22;
}
.myButton {
.myCommonButton;
color: black;
}