I was working with custom radio buttons and checkboxes, the css is vast so I want to convert it to less way of organizing but how can I convert this statement to less
input[type='checkbox']:checked + .mycheck-overlay:before{
/*some css*/
}
any help would be greatfull....
It depends how you want to structure your LESS, the following is still valid, if you dont need any styling for the intermediate sections.
input[type='checkbox']:checked + .mycheck-overlay:before{
/*some css*/
}
However, depending on exactly which section of the rule you wish to style, in full you can break it down thusly:
input[type='checkbox']{
/* normal checkbox styles */
&:checked{
/* checked state checkbox styles */
+ .mycheck-overlay{
/* style of elements with class mycheck-overlay immediately after a checked input checkbox */
&:before{
/* the before psuedo styling for those... */
}
}
}
}
Note that you can use the ampersand & character preceding a nested rule to indicate it should be applied in conjunction with the parent selector (i.e. when the rule is compiled, no space should be left between it and the preceding selector)
Related
I'm trying to select input elements of all types except radio and checkbox.
Many people have shown that you can put multiple arguments in :not, but using type doesn't seem to work anyway I try it.
form input:not([type="radio"], [type="checkbox"]) {
/* css here */
}
Any ideas?
Why :not just use two :not:
input:not([type="radio"]):not([type="checkbox"])
Yes, it is intentional
If you're using SASS in your project, I've built this mixin to make it work the way we all want it to:
#mixin not($ignorList...) {
//if only a single value given
#if (length($ignorList) == 1){
//it is probably a list variable so set ignore list to the variable
$ignorList: nth($ignorList,1);
}
//set up an empty $notOutput variable
$notOutput: '';
//for each item in the list
#each $not in $ignorList {
//generate a :not([ignored_item]) segment for each item in the ignore list and put them back to back
$notOutput: $notOutput + ':not(#{$not})';
}
//output the full :not() rule including all ignored items
&#{$notOutput} {
#content;
}
}
it can be used in 2 ways:
Option 1: list the ignored items inline
input {
/*non-ignored styling goes here*/
#include not('[type="radio"]','[type="checkbox"]'){
/*ignored styling goes here*/
}
}
Option 2: list the ignored items in a variable first
$ignoredItems:
'[type="radio"]',
'[type="checkbox"]'
;
input {
/*non-ignored styling goes here*/
#include not($ignoredItems){
/*ignored styling goes here*/
}
}
Outputted CSS for either option
input {
/*non-ignored styling goes here*/
}
input:not([type="radio"]):not([type="checkbox"]) {
/*ignored styling goes here*/
}
Starting from CSS Selectors 4 using multiple arguments in the :not selector becomes possible (see here).
In CSS3, the :not selector only allows 1 selector as an argument. In level 4 selectors, it can take a selector list as an argument.
Example:
/* In this example, all p elements will be red, except for
the first child and the ones with the class special. */
p:not(:first-child, .special) {
color: red;
}
Unfortunately, browser support is somewhat new.
I was having some trouble with this, and the "X:not():not()" method wasn't working for me.
I ended up resorting to this strategy:
INPUT {
/* styles */
}
INPUT[type="radio"], INPUT[type="checkbox"] {
/* styles that reset previous styles */
}
It's not nearly as fun, but it worked for me when :not() was being pugnacious. It's not ideal, but it's solid.
If you install the "cssnext" Post CSS plugin, then you can safely start using the syntax that you want to use right now.
Using cssnext will turn this:
input:not([type="radio"], [type="checkbox"]) {
/* css here */
}
Into this:
input:not([type="radio"]):not([type="checkbox"]) {
/* css here */
}
https://cssnext.github.io/features/#not-pseudo-class
I know CSS selector with the highest specificity takes precedence (i.e. .classname < #idname).
I also know that if things are the same specificity, then the last statement called takes precedence:
.classname1 { color: red; }
.classname1 { color: blue; } // classname1 color will be blue
Does the ordering of HTML classes on a DOM element affect the statement priority?
I have to disagree slightly with Jon and Watson's answers, as...
Yes, it Can (depending on the statement)
Your question is:
Does the ordering of CSS classes on a DOM element affect the statement priority?
Which does depend on the statement in question.
HTML Ordering Does Not Typically Matter
The following are equivalent when it comes to a straight call to a class (i.e. .class1 or .class2) or to a combined call (i.e. .class1.class2 or .class2.class1):
<div class="class1 class2"></div>
<div class="class2 class1"></div>
Cases Where Statement Priority for above HTML Can be Affected Based on HTML Order
The main place where ordering in HTML matters is with the use of attribute selectors in your CSS.
Example 1 Fiddle using the following code seeking to match attribute value will NOT have any change in font color, and each div will have different properties because of the ordering of the classes:
[class="class1"] {
color: red;
}
[class="class1 class2"] {
background-color: yellow;
}
[class="class2 class1"] {
border: 1px solid blue;
}
Example 2 Fiddle using the following code seeking to match beginning of attribute value will NOT have any change in font color for the second div, and each div will have different properties because of the ordering of the classes:
[class^="class1"] {
color: red;
}
[class^="class1 class2"] {
background-color: yellow;
}
[class^="class2 class1"] {
border: 1px solid blue;
}
Example 3 Fiddle using the following code seeking to match end of attribute value will NOT have any change in font color for the first div, and each div will have different properties because of the ordering of the classes:
[class$="class1"] {
color: red;
}
[class$="class1 class2"] {
background-color: yellow;
}
[class$="class2 class1"] {
border: 1px solid blue;
}
A Clarifying Statement about "Priority"
To be clear, in the cases above, what is affected as far as "statement priority" is concerned is really a matter of whether the statement actually applies or not to the element. But since the application or not is in a sense, the basic priority, and since the above are cases where such application is actually based on the ordering of the classes on the HTML Dom element (rather than the presence or absence of the class), I thought it worth adding this as an answer.
Possible Valid Use of Class Ordering?
This is a thought occurring to me, based on BoltClock's comment. Consider just two classes being used to style elements based on whatever factors are deemed critical to different styling. These two classes theoretically can replace the use of eleven different individual classes using the combination of attribute selectors (actually, as will be noted later, the possibilities are almost limitless with but a single class, but I'll discuss that in a moment since this post is about ordering of multiple classes). For these two classes we can style elements differently as follows:
Assuming these HTML Combinations
<div class="class1">Element 1</div>
<div class="class2">Element 2</div>
<div class="class1 class2">Element 3</div>
<div class="class2 class1">Element 4</div>
CSS Possibilities
/* simply has the class */
.class1 {} /* affects elements 1, 3, 4 */
.class2 {} /* affects elements 2-4 */
/* has only a single class */
[class="class1"] {} /* affects element 1 only */
[class="class2"] {} /* affects element 2 only */
/* simply has both classes */
.class1.class2 {} /* affects elements 3-4 */
/* has both classes, but in a particular order */
[class="class1 class2"] {} /* affects element 3 only */
[class="class2 class1"] {} /* affects element 4 only */
/* begins with a class */
[class^="class1"] {} /* affects elements 1 & 3 only */
[class^="class2"] {} /* affects elements 2 & 4 only */
/* ends with a class
NOTE: that with only two classes, this is the reverse of the above and is somewhat
superfluous; however, if a third class is introduced, then the beginning and ending
class combinations become more relevant.
*/
[class$="class1"] {} /* affects elements 2 & 4 only */
[class$="class2"] {} /* affects elements 1 & 3 only */
If I calculate right, 3 classes could give at least 40 combinations of selector options.
To clarify my note about "limitless" possibilities, given the right logic, a single class can potentially have imbedded in it code combinations that are looked for via the [attr*=value] syntax.
Is all this too complex to manage? Possibly. That may depend on the logic of exactly how it is implemented. The point I am trying to bring out is that it is possible with CSS3 to have ordering of classes be significant if one desired it and planned for it, and it might not be horribly wrong to be utilizing the power of CSS in that way.
No, it does not. The relevant part of the W3C standard makes no mention of the order of appearance for classes.
No, it does not, like you said, if two rules have the same specificity, the one that comes later in your CSS will be applied.
No. But if you want to make one of your declaration blocks to has more precedence (w/o many !importants) make its selector more specific.
For example, for a div:
div.classname1 { color: red; } /* classname1 color will be red (for `div`s) */
.classname1 { color: blue; }
What's missing or a little hard to find in other answers is this:
What matters is the order in which the browser reads/parses the class names
The class defined last will win
.a {
color: red;
}
.b {
color: blue;
}
<div class="a b">This text will be blue</div>
<div class="b a">This text will ALSO be blue</div>
Example comes from this source
May be affected by the order of your imports
Because if this you may need to pay attention to how you import CSS in your files.
For example in my JavaScript based project I have a component that I can pass extra classes to. In order for my own classes to overwrite styles of the classes of the component itself I need to first import the component I wish to style (which will import its own styles) and only then import my own styles:
//import the component first, which will import css
import {SomeComponent} from 'some-library/SomeComponent';
//And THEN our own styles
import './styles.css';
return <SomeComponent className={myClassName} />
Like this my buildprocess (Webpack) will put my own classes later in the CSS bundle than the components ones.
I have a class in my css called .btn:
.btn {
//stuff here
}
and I am going to create another class, lets say .btn2. I want to be able to inherit the characteristics from .btn into btn2, as I only want to change the color of button 2. Is there a way in CSS for this? Or should I just copy and paste the original stuff into the new class?
I'd suggest:
/* comma-separated selectors: */
.btn,
.btn2 {
/* shared properties */
}
.btn2 {
/* properties unique to btn2 */
}
JS Fiddle demo.
You can do it with dynamic stylesheets. Check out LESS or SASS.
EDIT:
Some additional info at a commenter's request. Here are the official sites. They both have examples on their home pages.
http://lesscss.org/
http://sass-lang.com/
What you can do is this
.btn, .btn2 {
/* Styles goes here */
}
This way, both the classes will share common properties defined in the rule block.
As far as the inheritance goes, something you would like to have..
.btn2 {
.btn; /* Won't work in pure CSS */
}
Won't work in pure CSS, you need to take a look at SASS or LESS
I know CSS selector with the highest specificity takes precedence (i.e. .classname < #idname).
I also know that if things are the same specificity, then the last statement called takes precedence:
.classname1 { color: red; }
.classname1 { color: blue; } // classname1 color will be blue
Does the ordering of HTML classes on a DOM element affect the statement priority?
I have to disagree slightly with Jon and Watson's answers, as...
Yes, it Can (depending on the statement)
Your question is:
Does the ordering of CSS classes on a DOM element affect the statement priority?
Which does depend on the statement in question.
HTML Ordering Does Not Typically Matter
The following are equivalent when it comes to a straight call to a class (i.e. .class1 or .class2) or to a combined call (i.e. .class1.class2 or .class2.class1):
<div class="class1 class2"></div>
<div class="class2 class1"></div>
Cases Where Statement Priority for above HTML Can be Affected Based on HTML Order
The main place where ordering in HTML matters is with the use of attribute selectors in your CSS.
Example 1 Fiddle using the following code seeking to match attribute value will NOT have any change in font color, and each div will have different properties because of the ordering of the classes:
[class="class1"] {
color: red;
}
[class="class1 class2"] {
background-color: yellow;
}
[class="class2 class1"] {
border: 1px solid blue;
}
Example 2 Fiddle using the following code seeking to match beginning of attribute value will NOT have any change in font color for the second div, and each div will have different properties because of the ordering of the classes:
[class^="class1"] {
color: red;
}
[class^="class1 class2"] {
background-color: yellow;
}
[class^="class2 class1"] {
border: 1px solid blue;
}
Example 3 Fiddle using the following code seeking to match end of attribute value will NOT have any change in font color for the first div, and each div will have different properties because of the ordering of the classes:
[class$="class1"] {
color: red;
}
[class$="class1 class2"] {
background-color: yellow;
}
[class$="class2 class1"] {
border: 1px solid blue;
}
A Clarifying Statement about "Priority"
To be clear, in the cases above, what is affected as far as "statement priority" is concerned is really a matter of whether the statement actually applies or not to the element. But since the application or not is in a sense, the basic priority, and since the above are cases where such application is actually based on the ordering of the classes on the HTML Dom element (rather than the presence or absence of the class), I thought it worth adding this as an answer.
Possible Valid Use of Class Ordering?
This is a thought occurring to me, based on BoltClock's comment. Consider just two classes being used to style elements based on whatever factors are deemed critical to different styling. These two classes theoretically can replace the use of eleven different individual classes using the combination of attribute selectors (actually, as will be noted later, the possibilities are almost limitless with but a single class, but I'll discuss that in a moment since this post is about ordering of multiple classes). For these two classes we can style elements differently as follows:
Assuming these HTML Combinations
<div class="class1">Element 1</div>
<div class="class2">Element 2</div>
<div class="class1 class2">Element 3</div>
<div class="class2 class1">Element 4</div>
CSS Possibilities
/* simply has the class */
.class1 {} /* affects elements 1, 3, 4 */
.class2 {} /* affects elements 2-4 */
/* has only a single class */
[class="class1"] {} /* affects element 1 only */
[class="class2"] {} /* affects element 2 only */
/* simply has both classes */
.class1.class2 {} /* affects elements 3-4 */
/* has both classes, but in a particular order */
[class="class1 class2"] {} /* affects element 3 only */
[class="class2 class1"] {} /* affects element 4 only */
/* begins with a class */
[class^="class1"] {} /* affects elements 1 & 3 only */
[class^="class2"] {} /* affects elements 2 & 4 only */
/* ends with a class
NOTE: that with only two classes, this is the reverse of the above and is somewhat
superfluous; however, if a third class is introduced, then the beginning and ending
class combinations become more relevant.
*/
[class$="class1"] {} /* affects elements 2 & 4 only */
[class$="class2"] {} /* affects elements 1 & 3 only */
If I calculate right, 3 classes could give at least 40 combinations of selector options.
To clarify my note about "limitless" possibilities, given the right logic, a single class can potentially have imbedded in it code combinations that are looked for via the [attr*=value] syntax.
Is all this too complex to manage? Possibly. That may depend on the logic of exactly how it is implemented. The point I am trying to bring out is that it is possible with CSS3 to have ordering of classes be significant if one desired it and planned for it, and it might not be horribly wrong to be utilizing the power of CSS in that way.
No, it does not. The relevant part of the W3C standard makes no mention of the order of appearance for classes.
No, it does not, like you said, if two rules have the same specificity, the one that comes later in your CSS will be applied.
No. But if you want to make one of your declaration blocks to has more precedence (w/o many !importants) make its selector more specific.
For example, for a div:
div.classname1 { color: red; } /* classname1 color will be red (for `div`s) */
.classname1 { color: blue; }
What's missing or a little hard to find in other answers is this:
What matters is the order in which the browser reads/parses the class names
The class defined last will win
.a {
color: red;
}
.b {
color: blue;
}
<div class="a b">This text will be blue</div>
<div class="b a">This text will ALSO be blue</div>
Example comes from this source
May be affected by the order of your imports
Because if this you may need to pay attention to how you import CSS in your files.
For example in my JavaScript based project I have a component that I can pass extra classes to. In order for my own classes to overwrite styles of the classes of the component itself I need to first import the component I wish to style (which will import its own styles) and only then import my own styles:
//import the component first, which will import css
import {SomeComponent} from 'some-library/SomeComponent';
//And THEN our own styles
import './styles.css';
return <SomeComponent className={myClassName} />
Like this my buildprocess (Webpack) will put my own classes later in the CSS bundle than the components ones.
I'm trying to select input elements of all types except radio and checkbox.
Many people have shown that you can put multiple arguments in :not, but using type doesn't seem to work anyway I try it.
form input:not([type="radio"], [type="checkbox"]) {
/* css here */
}
Any ideas?
Why :not just use two :not:
input:not([type="radio"]):not([type="checkbox"])
Yes, it is intentional
If you're using SASS in your project, I've built this mixin to make it work the way we all want it to:
#mixin not($ignorList...) {
//if only a single value given
#if (length($ignorList) == 1){
//it is probably a list variable so set ignore list to the variable
$ignorList: nth($ignorList,1);
}
//set up an empty $notOutput variable
$notOutput: '';
//for each item in the list
#each $not in $ignorList {
//generate a :not([ignored_item]) segment for each item in the ignore list and put them back to back
$notOutput: $notOutput + ':not(#{$not})';
}
//output the full :not() rule including all ignored items
&#{$notOutput} {
#content;
}
}
it can be used in 2 ways:
Option 1: list the ignored items inline
input {
/*non-ignored styling goes here*/
#include not('[type="radio"]','[type="checkbox"]'){
/*ignored styling goes here*/
}
}
Option 2: list the ignored items in a variable first
$ignoredItems:
'[type="radio"]',
'[type="checkbox"]'
;
input {
/*non-ignored styling goes here*/
#include not($ignoredItems){
/*ignored styling goes here*/
}
}
Outputted CSS for either option
input {
/*non-ignored styling goes here*/
}
input:not([type="radio"]):not([type="checkbox"]) {
/*ignored styling goes here*/
}
Starting from CSS Selectors 4 using multiple arguments in the :not selector becomes possible (see here).
In CSS3, the :not selector only allows 1 selector as an argument. In level 4 selectors, it can take a selector list as an argument.
Example:
/* In this example, all p elements will be red, except for
the first child and the ones with the class special. */
p:not(:first-child, .special) {
color: red;
}
Unfortunately, browser support is somewhat new.
I was having some trouble with this, and the "X:not():not()" method wasn't working for me.
I ended up resorting to this strategy:
INPUT {
/* styles */
}
INPUT[type="radio"], INPUT[type="checkbox"] {
/* styles that reset previous styles */
}
It's not nearly as fun, but it worked for me when :not() was being pugnacious. It's not ideal, but it's solid.
If you install the "cssnext" Post CSS plugin, then you can safely start using the syntax that you want to use right now.
Using cssnext will turn this:
input:not([type="radio"], [type="checkbox"]) {
/* css here */
}
Into this:
input:not([type="radio"]):not([type="checkbox"]) {
/* css here */
}
https://cssnext.github.io/features/#not-pseudo-class