I want to use some css framework but hate its unsemanticness. So I want to use LESS. The basic idea is mixin framework's css into my own classes. But I feel LESS can't handle some scenarios. For example, some classes are define in the framework as:
div.prepand = {...}
or
* html .span-1 = {...}
LESS mixin doesn't seem to support the above situations. Any idea?
I'm not sure which framework did you mean by saying that "some classes are define in the framework as:".
In Less, you don't declare mixins the way you showed it. You do it like so:
.my_mixin { ... }
And then below in the file you can (re)use it like so:
div.content {
.my_mixin;
}
Other than that, I don't understand your question. You want to mixin framework's CSS into your own classes? What does that mean? You write CSS in Less or you don't ...
I've just put together the grid portion of blueprint.css in LESS here. You can set the column and gutter widths, then use mixins like this:
#header {
.span(20);
.prepend(2);
}
I've added a couple of example #media queries as well, allowing for responsive layouts.
I hope it might be of use to someone.
Related
I trying to understand the logic behind media queries in sass.
For example, if I want to set media queries for my container in css in will be:
#media only screen and (max-width: 37em){
.container{
some code
}
}
But in sass it will be:
.container {
#media only screen and (max-width: $bp-medium){
some code
}
}
As you can see it the upset!
how the sass look after it compiled?
In sass you can e.g. set standard values - just like in your example $bp-medium. If you set this value to 37em, it will behave similar to your css example.
By the way, you can just as well use the css way for sass. Wouldn't recommend though, since this is what sass makes powerful.
By moving the media query inside a selector, you are organising all styles relevant to a component in the same place. When you choose to do it the CSS way, you'll organise the styles based on the media queries. This will give you a bad overview of what the component would look like in big projects and large files.
I doubt so i want to know if is better to do something like:
.class {
#include breakpoint($desk) {
}
}
or the opposite:
#include breakpoint($desk) {
.class {
}
}
Im using the second one because i think in this way I group all the class or ID in a breakpoint, but I'm not sure.
In Sass, media queries bubble up to the top of nesting, so both examples produce identical CSS.
The second approach lets you group multiple declarations under one media query, but you should only use it when those declarations would appear next to each other anyway. There's an opinion that you should not structure your code so that it produces less media queries. Instead, you should structure your code by function, i. e. by what page elements the code describes. Media queries should be applied as narrowly as possible. Server's gzip compression will deal with duplicate code.
But this is a matter of personal preference and both examples are valid and acceptable.
I was wondering if it is possible to define the styles of an element depending on the value of the body ID.
It is difficult to explain but something like this would be ideal:
HTML:
<body id="home">
CSS:
body#home {
a { /* code here */ }
p { /* code here */ }
}
body#profile {
a { /* different code here */ }
p { /* different code here */ }
}
I know I can do this:
body#home a { /* code here */ }
but that becomes very repetitive.
I will be looking forward to your responses,
Peter
You can do this if you use a CSS framework like SASS or LESS
Here's the documentation on how to do this with LESS. Hope this helps.
IDs are supposed to be unique, so #home { ... } is acceptable.
Then and child elements would be:
#home .myClass { ... }
This technique if often used to re-skin pages be simply changing the ID or class on a body.
Be aware that while nesting styles like this can be supported using CSS frameworks, it should be well thought-out to maintain modularity and clean inheritance in your CSS. You can end up doing more harm than good. In particular, watch out for something know as the inception rule, described here:
http://thesassway.com/beginner/the-inception-rule
The Inception Rule: don’t go more than four levels deep.
Any change you make to your markup will need to be reflected into your
Sass and vice versa. It also means that the styles are bounded for
life to the those elements and that HTML structure which completely
defeats the purpose of the "Cascade" part of "Cascading Style Sheets."
If you follow this path, you might as well go back to writing your CSS
inline in your HTML (please don't).
The best way to do what you are talking about is to have a base stylesheet the site.
They have either:
A <style> element in the header overriding anything you choose
or
Have a different stylesheet for each page
I have a tonne of CSS styles like so:
.T .class1{...}
.T .class2{...}
.T .class3{...}
...etc
Is there any way to write this without writing the .T each time? Something like the way media queries work would be great:
.T{
.class1{...}
.class2{...}
.class3{...}
...etc
}
Is something like this possible? If not, can we speculate as to the reasons why not?
No, CSS does not support this. However, CSS pre-processors like SASS and LESS do.
I've always wished CSS would structure that way, but sadly, it does not.
If all of the ".class1, .class2, etc." are to be styled the same, you can use a couple methods.
You could do something like:
.T .class1, .T .class2, .T .class3....{
/* Your code here */
}
Or you could do something like this (depending on your applications):
.T *{
/* Your code here */
}
The latter is less specific and would select everything inside of the .T element.
I'm assuming you need each "class1, class2" styled individually though, which would render these answers useless. At that point, you could use javascript to achieve this, though it is not as elegant.
I'm creating a touch stylesheet for a web app. The body tag has the
class T so everything below it will be styled up for fat fingers
You can write all styles in mobile.css and attach this file only for mobile device with JS
As mentioned, you can try the magic of:
- SASS: http://sass-lang.com/
- LESS: http://lesscss.org/
Once you start using them, just be careful not to go crazy when nesting selectors.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
In our project we use SASS for styles development. Also, we use Bootstrap and it contains next well-known mixin:
#mixin clearfix {
*zoom: 1;
&:before,
&:after {
display: table;
content: "";
// Fixes Opera/contenteditable bug:
// http://nicolasgallagher.com/micro-clearfix-hack/#comment-36952
line-height: 0;
}
&:after {
clear: both;
}
}
And we use it in our styles:
.class-example {
#include clearfix();
. . .
}
After the compilation into CSS, SASS copies all content of mixin into each class we used mixin. So, it's a big amount of duplicated code. We use mixin about 100 times, so it's about 1000 extra lines in css.
So, the question: which is better form performance/support/readability/etc. point of view
Use mixin and allow duplicated code be
Create class .clearfix and use it in markup like <span
class="example-class clearfix"> ... </span> to avoid duplication
Also, if someone has better solution - I'll be glad to get it. Any comments/discussions are welcome.
To begin with, I'd like to mention that applying overflow: hidden to an element with floating children clears the floats much like how including the clearfix mixin you're talking about does it.
For readability and performance, this is probably the clear winner. I don't have any data supporting that overflow: hidden actually renders faster than the clearfix, but I wouldn't be surprised if it does. It's much less CSS, though, so it's definitely a winner in terms of downloaded data.
It's not always possible to use overflow: hidden though as your layout may have some relative positioning going on. In those cases, the best performant method is to create a global class for .clearfix and apply it to all elements that are supposed to clear their children. While it doesn't sound like it's easily maintainable, I'd argue that it is more easily maintainable that including that mixin throughout your CSS since you won't have to clear the cached CSS whenever you make changes.
My recommendation is to use both overflow: hidden and .clearfix. Scrap #include clearfix.
The reasoning is that you can't always get away with just one method (sometimes you may want to use the :after element for something else, sometimes you may want content to stretch outside their containers) so having both available makes sense anyway.
With both methods available you're able to adapt to any scenario. Just remember you could tie overflow: hidden to a class name to keep it just as DRY as .clearfix.
My 2¢.
Edit:
Alternatively, but maybe not ideally, you could use #extend to create an output like this:
.element-1,
.element-2,
.element-3,
.element-4,
.element-5 {
// clearfix stuff
}
So that clearfix is defined at one place rather than multiple times through the document. Personally I'm not a big fan of it, but perhaps it makes sense to you.
I would suggest to make it a "helper" -class as you fine said your self, they are alot more agile and you put them where they are needed, also there are different clearfixes depending on the situration, some are overflow fixes some are table layout fixes and so on, i would rather create a class and add them where its needed, this also makes you layout classes independent of clear fixing. So they can live as stand alone and reusable codes not to have to worry if the clearfix could mess up potential layouts :)
Im using them as classes for a better and more agile way to do my layouts.
Edit, so i would say your solution number 2 is the best also for not as u are saying duplicating 100 lines of code.
Like others have said already, for a simple utility mixin like this, I'd define it as an extension instead, like this:
%clearfix {
//clearfix code
}
And then use it in the SASS like this:
.container{
#extend %clearfix;
}
This way, no matter how many times you extend it, the code that it outputs is in the CSS only once, instead of hundreds of times.
I would argue against using classes like clearfloat or clearfix in the markup unless you reeeallly need to-- why muddle up the markup when you can do it better and faster with CSS? Instead of tracking through a lot of different markup files, you can easily change it in one place, in your SASS file.
This allows you to have everything in one place, instead of spread out in many places, which makes maintaining it much easier, as I know from experience.
I am using bootstrap's less files in my current project and it has the following in mixins.less file:
// UTILITY MIXINS
// --------------------------------------------------
// Clearfix
// --------
.clearfix {
*zoom: 1;
&:before,
&:after {
display: table;
content: "";
// Fixes Opera/contenteditable bug:
// http://nicolasgallagher.com/micro-clearfix-hack/#comment-36952
line-height: 0;
}
&:after {
clear: both;
}
}
we can define so-called "mixins", which have some similarities to functions in programming languages. They’re used to group CSS instructions in handy, reusable classes. Mixins allow you to embed all the properties of a class into another class by simply including the class name as one of its properties. It’s just like variables, but for whole classes. Any CSS class or id ruleset can be mixed-in that way:
.container{
.clearfix();
}
As far as clearfix is concerned, I just use it as clearfix because it is doing one task which is clearing floats and i.e. what bootstrap offers one class to get a particular task. It is independent of other classes.
You can use it in html like this:
<div class="clearfix"></div>
I recommend using the mixin and don't worry about the very small performance hit. In the future if there are certain content types that you no longer want to use the clearfix on, you will have to go through all of your html to remove the tag.
It is always safer to keep your markup clean and do your layout and styling in the css. In this case you are taking a very small performance hit in order to save yourself in terms of future support. If you are seeing performance as an issue, you might want to think about ways that you could set up your markup or css so that you don't have so many classes that call .clearfix.
First of all!
I would start off by suggesting not using overflow: hidden. It is a hack and therefore will lead to confusing code for people in the future, especially new people to any business you apply this code in. There are also repercussions that a JavaScript developer would have to contend with for any position related elements.
So what are the PROS and CONS of applying a clearfix class everywhere or just applying an include within your SASS?
clearfix class
clearfix on a DOM element shows that the content is floating to any person without looking any further. The clearfix styling is written only once, making your Stylesheet files smaller.
#include clearfix
Great whoooop dee doo, let's all use the include everywhere and expand our Stylesheet mass shall we. But wait! I did find an interesting opportunity to really use it, which I will do for this exact reason.
If you have classes not in a template that requires a clearfix, so written all over the DOM. I could imagine wanting to use the include option. Though this is fairly rare.
Also, as a class undergoing responsive changes on the page suddenly requires a clearfix, you can nestle that within a nice #import media() with bourbon neat for example. But even this would be rare as you could just apply the clearfix again and be done with it right from the start.
Conclusion
I think a happy medium is called for, which should always be the case when writing SASS. But that is my personal opinion :-P