I know that sass provides us with #extend method that allows me to do this:
%knob {
width: 10px;
height: 10px;
}
.house {
&__door {
&__knob {
color: inherit;
#extend %knob;
&--red {
#extend %knob;
// $1
color: red;
}
&--blue{
#extend %knob;
// $1
color: blue;
}
}
}
}
however i would prefer not to define abstract class %knob at all, would it be possible to reference/include properties defined in __knob (width and height in this case) from within its modifiers --red and --blue?
im including sassmeister snippet here to help out a bit: http://sassmeister.com/gist/58b5b4673a18ecadbba7
example here might not look like an issue but if an element with a long class name has 2 or more different groups of modifiers, and I wont create an abstract class, i sometimes end up with html tags looking like this <p class="some other classes some-house__some-door__some-knob some-house__some-door__some-knob--red">example</p> which I find not very desirable.
what i would like to achieve:
referencing parent element would alow me to reduce this string to <p class="some other classes some-house__some-door__some-knob--red"></p> without necessity of declaring an abstract %knob class
why am I hesitant about using an abstract class here:
declaring an abstract class inside __door element (http://sassmeister.com/gist/bc49e0885342e96a8fbd) gives me this result:
.house__door .house__door__knob, .house__door .house__door__knob--red, .house__door .house__door__knob--blue {
width: 10px;
height: 10px;
}
instead of desired
.house__door__knob, .house__door__knob--red, .house__door__knob--blue {
width: 10px;
height: 10px;
}
and declaring an abstract class outside of the scope its going to be used in makes the code less readable
or maybe theres a different apporach i could use in order to make my code more readable/maintainable?
while searching for an answer to my question i came to the conclusion that inheriting parent element properties/ using #extend or #include here might not be the best idea as it would work well only if an element had 1 modification at most:
in other cases if multiple modifications extended same model, and were to be used to the same html element, all of the base properties would be declared multiple times
also there is no need at all to deeply nest elements (i.e. foo__bar__baz). separating elements makes code easier to maintain.
Related
After reading tutorial after tutorial regarding Less (LessCSS), I was just wondering how this & operator is supposed to be used. I know it's referring the parent element like:
div {
&.fullheight {
height: 100%;
}
}
// turns into
div.fullheight {
height: 100%;
}
But I often saw this:
div {
span {
& {
padding: 1em;
margin: 1em;
}
}
}
// turns into
div span {
padding: 1em;
margin: 1em;
}
Like when using ONLY the & operator inside of a class, it represents pretty much the parent element, but is doing this bad practise since you can have the same result when you would type like this:
div {
span {
padding: 1em;
margin: 1em;
}
}
Both work, so is it bad/good practise or are each of them maybe used in different situations?
For extra clarity, below is the link to an answer where I first saw that you can write & only in a class without anything else.
LESSCSS - use calculation and return value - First post by ScottS, fourth solution in his post.
Generally writing something like below would be considered as bad practice because the & there is just redundant and does no value add at all. It just outputs the entire parent selector div span.
div {
span {
& {
padding: 1em;
margin: 1em;
}
}
}
So, you should avoid writing such selectors which use only the & (parent selector).
The other example to which you have linked is an interesting case which I would term as an educated hack to get around the variable scoping and lazy loading concepts in Less.
Assume that the same code was written without the parent selectors (like below).
#unit:em;
#basevalue:1;
#val: 1;
#setUnit: unit(#basevalue*#val, #unit);
.someAwesomeClass {
#val: .2;
padding: #setUnit;
#val: .1;
margin: #setUnit;
}
Here the #val variable is declared twice within the same block. Since Less does lazy loading of the variables, they need not be declared before being used (and) if the same variable is declared twice or more within the same scope, the last declaration would win.
When defining a variable twice, the last definition of the variable is used, searching from the current scope upwards. This is similar to CSS itself where the last property inside a definition is used to determine the value.
So, the compiled CSS output would have the value as 0.1em for both padding and margin whereas the expectation is for padding to be 0.2em and for margin to be 0.1em.
To overcome this, the author of that answer has introduced two namespaces (with no name) and has thus restricted the scoping issue. The variable defined within each nested block becomes local to that block only and so will be considered as two separate variables.
#unit:em;
#basevalue:1;
#val: 1;
#setUnit: unit(#basevalue*#val, #unit);
.someAwesomeClass {
&{
#val: .2; /* this declaration applies only within this nest */
padding: #setUnit;
}
&{
#val: .1; /* this declaration applies only within this nest */
margin: #setUnit;
}
}
As indicated by the author of that answer (in the first line), it was a workaround because there was no way to create a true function with Less.
But starting with Less v2, we can define our own custom functions in Less and use them as described in this answer by Bass Jobsen. The ability to write such custom functions should eliminate the need to write such hacks.
You can also refer to the comment by seven-phases-max in the same thread for a solution without the need for such hacks.
Bottomline is that usage of & alone as a selector is a bad practice. The solution in the linked answer was a hack which was useful in earlier versions of Less. It is still useful but there are alternate options and so & alone as a selector should be used only in extremely rare circumstances where none of the other option work.
I'm looking into LESS because I definitely see some of their benefits. For instance colour declaration.
One thing I don't understand tho, and maybe I'm not getting the flow right is - why use the following LESS snippet
.radius {
-webkit-border-radius:5px;
-moz-border-radius:5px;
border-radius:5px;
}
.btn-red{
background-color:red;
.radius;
}
.btn-green{
background-color:green;
.radius;
}
...
When we can use the .radius class in the html file right away. I'm left with the impression that LESS will add a ton of duplicate code once it gets compiled.
I'm using the following, which makes more sense. Same with font-size, margins, etc... Aren't classes used in such cases?
<div class="btn-red radius">Cancel</div>
<div class="btn-green radius">Go</div>
The snippet above does not benefit from SASS/LESS capabilities that much. Lets have a closer look and check this SCSS snippet.
// Abstract placeholder.
%radius {
border-radius: 5px;
}
// Put your global styling here.
// I'm assuming that you can alter the markup and have button.btn.btn-green
.btn {
// Color modifier.
&-red {
#extend %radius;
background-color: red;
}
&-green {
#extend %radius;
background-color: green;
}
}
The CSS output will be:
.btn-red, .btn-green {
border-radius: 5px;
}
.btn-red {
background-color: red;
}
.btn-green {
background-color: green;
}
And then you have to pick up Autoprefixer and vendor-prefixes issue is solved once and for all.
Because now, you can just specify the class btn_red or btn_green and all the buttons will automatically have a radius.
Your HTML should contain only the semantics, and styling or classes referring to styling should not be part of it.
That applies to the other classes as well. If for instance, you would rename btn_red to btn_cancel, you have a meaningful classname that you can apply to any kind of cancel button. And in the CSS you can specify that a cancel button is red and a 'Go' button is green, and both have a radius, without needing to modify the HTML at all.
So, the ultimate goal is to have the HTML describe the structure and the CSS describe how that structure should look. And a CSS preprocessor is only their to make a bulky spaghetti-like CSS file more structured.
There are several benefits.
You can use more semantic class names. Rather than encoding style information directly in your class names, (btn-red, radius) you could use a single class that conveys the usage of the style, rather than its contents.
You can avoid repeating yourself.
#radius-size: 5px;
-webkit-border-radius:#radius-size;
-moz-border-radius:#radius-size;
border-radius:#radius-size;
You can parameterize it so that you'd be able to use different radiuses (radii?) in different contexts.
.radius(#radius-size) { ... }
Because there are cases that developer has-no-access or don't-want to change the markup. and the only solution is to include all props from a predefined class.
for example:
you have bootstrap loaded (then you already have .has-success and .has-error classes) and if you want to use HTML5's native form validation using input's :valid and :invalid states, you have to use JavaScript to add/remove success/error classes based on input's states. but with this feature of LESS you can include all props of success/error class inside input's states. the code for this example could be something like this:
#myinput {
&:valid { .has-success; }
&:invalid { .has-error; }
}
I havent done CSS in awhile (~5-7yrs).
So i need a little assistance in a possible solution to my quandry.
Ideal design:
table.ctable
{ class:collapsible collapsed; }
Now i know that its syntactically not correct but was wondering if there was a way to create some base-class CSS and then have those class(es) derive into a parent. I know its not OOP, but figured there would be a way around the current structure to accomidate this type of inclusion.
You couls use a SASS mixin:
#mixin left($dist) {
float: left;
margin-left: $dist;
}
#data {
#include left(10px);
}
or a LessCSS mixin:
.left(#dist) {
float: left;
margin-left: #dist;
}
#data {
.left(10px);
}
No, unfortunately you can't inherit rules from another class. The closest you can get is JavaScript getting elements by class name and applying extra classes to them, but then you have the jump between the page loading the JS running.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Should css class names like 'floatleft' that directly describe the attached style be avoided?
I was wondering what the best practices were for the naming and usage of CSS classes.
For instance, in a scenario where you want to center the text of both the button text and the header text, is it better to repeat this style in both classes like
.button-text {
text-align: center;
/*some properties*/
}
.header-text {
text-align: center;
/*other properties*/
}
Or is it better practice to move that style out into a separate class like
.center {
text-align: center;
}
.button-text {
/*some properties*/
}
.header-text {
/*other properties*/
}
and have the class of "center" applied to elements that have the classes of "button-text" and "header-text".
What it comes down to, is, should CSS class names represent what an element is "button-text" or "state, what an element looks like "center"?
Thanks!
A CSS class should represent what you use the element for, not what the element looks like.
Consider that you have headers that are red and bold, and change the design to large blue letters instead. If you named your classes after the look of the headers, you end up with:
.RedBold {
color: blue;
font-size: 200%;
}
Having a class named center is definitely the wrong approach - this class name already implies the presentation, that's not the point of defining presentation in a separate file. A better way to avoid code duplication would be:
.button-text, .header-text {
text-align: center;
}
.button-text {
/*some properties*/
}
.header-text {
/*other properties*/
}
Another option is specifying multiple classes, e.g. class="button text" instead of class="button-text". This gives you:
.text {
text-align: center;
}
.button.text {
/*some properties*/
}
.header.text {
/*other properties*/
}
Unfortunately, this approach has to be ruled out if you need to support MSIE 6.0, all other browsers (including newer MSIE versions) deal with multiple classes correctly. As other people already noted which solution you choose is mainly a question of maintenance - choose the one that will be easier to change and adapt to new requirements.
Maintainability is king. Whatever you find most easy to maintain - in my opinion, this is your second example.
It depends how much you will center text, the issue with the second point is that you could then end up with a long list of classes added to each element in your HTML which isn't so clean.
If these happen in, for example, a p tag a lot, then you'd possibly be better off putting one class in the parent so the children can inherit it.
i tend to group items together example like
.button-text, .header-text{
text-align:center
}
then if they need something unique add that to another
ie
.button-text{
font-size:22px;
}
.header-text{
font-size:44px;
}
class name's should be usefull but its not a biggie, just ensure they are unique. Often i name things based on their hierarchy within a page or section, as to prevent any accidental duplication.
Is there any way to bypass LESS scoping? It's becoming annoying. Basically, I have a .text-box which defines background, border, etc. Then, in a sub-section there's a one-off change to add a margin-top: .text-box { margin-top: 10px }. Now I can't use .text-box within that section and get my original box styles; instead, all I get is the margin-top. How can I get the definition higher in the heirarchy? I suppose I could make it a function, and call that function in both places, but being that I'm using LESS, I want to do less and KISS. In PHP, you'd get to the global namespace by using / prefix, or in C++ using :: prefix.
Additionally, it doesn't seem like any definitions with the node name work for prototyping. Meaning, I can't declare it ul.products, and then use ul.categories { ul.products }. I have to omit the node name in order to re-use it. Meaning: .categories { .products }. Is this an oversight/impossibility?
Thanks
ok so let's say you've got your mixin defined, for example:
.text-box {
background: #eee;
border: 1px solid #ccc;
color: #333;
margin-top: 5px;
}
now you want to add property or modify it in some subsection, then simply do this:
div.content {
div.sub_section {
.text-box;
margin-top: 10px; // this will override 5px defined in the mixin.
}
}
...which is putting your mixin in place, and adding some property you need to add (which will override any property from the mixin itself BUT make sure the overriding property is defined AFTER the mixin is called.
it's not ideal solution, as it creates two declarations in the output css file (there will be one from mixin followed by the one you defined in .sub_section), but otherwise I don't know a solution to this problem other than defining a parametric mixin..
--
your second issue - I think that less doesn't support scope-limited definitions on purpose... if you really need to know that certain mixin is to be used by a specific tag, I would deal with it like so:
.ul_products { ... }
.ul_categories { .ul_products; ... }
ul.categories { .ul_categories; }
you can also define a bundle and call stuff from there:
#ul {
.products { ... }
.categories { ... }
}
ul.categories { #ul > categories; }
i hope i got it right.. ?