If two classes in CSS have the same derived class how does CSS resolve the proper class?
For example:
.ClassA.Left {}
.ClassB.Left {}
.Left {}
Since the class 'Left' can be applied to any object how can I be assured it is the one I want?
What priority is used to bind 'Left'?
Anything with .Left as a class will get the styles applied in .Left, unless it also has ClassA (class="Left ClassA") then it will get the styles from .Left and .ClassA.Left, with ClassA.Left taking priority since it has higher specificity. Same rules apply to class="Left ClassB".
See here about specificity: https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity
Specificity
The concept
Specificity is the means by which a browser decides which property
values are the most relevant to an element and gets to be applied.
Specificity is only based on the matching rules which are composed of
selectors of different sorts.
How is it calculated?
The specificity is calculated on the concatenation of the count of
each selectors type. It is not a weight that is applied to the
corresponding matching expression.
In case of specificity equality, the latest declaration found in the
CSS is applied to the element.
Note: Proximity of elements in the document tree has no effect on the
specificity.
Crescent order of specificity
The following list of selectors is by increasing specificity:
Universal selectors
Type selectors
Class selectors
Attributes selectors
Pseudo-classes
ID selectors
Inline style
The !important exception
When an !important rule is used on a style declaration, this
declaration overrides any other declaration made in the CSS, wherever
it is in the declaration list. Although, !important has nothing to do
with specificity.
The :not exception
The negation pseudo-class :not is not considered as a pseudo-class in
the specificity calculation. Although, selectors placed into the
negation pseudo-class count as normal selectors.
Source: https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity
Equally, if the element had all three classes (ClassA, ClassB and Left) the the order in which the classes are listed in your CSS sheet matters.
.ClassA.Left would be beaten by .ClassB.Left (for common properties) as .ClassB.Left was lower in the cascade.
Single class selectors are beaten by multiple class selectors, thus .ClassA.Left beats .ClassA
Source order of the classes in the HTML is not a factor.
Codepen Specificity Example
Related
I have the following formats:
td:nth-child(6) { /* Saturday */
color: #ff7f7f;
}
td:nth-child(7) { /* Sunday */
color: #ff0000;
}
and later
.prevmonth, .nextmonth {
color: gray;
}
where prevmonth and nextmonth are classes in <td>-tags.
But the days from last month or next month are not shown in gray when they are a Saturday or Sunday.
Why the later format does not override the earlier format?
I helped myself by extending the earlier format with ...:not(.prevmonth, .nextmonth). That works fine.
CSS not only uses the latest selector for styling, it also uses the rule of specificity. If your selector is more specific (targeting an id, for example), it will override less specific selectors.
When the selectors have the same specificity, then the last one "wins".
This is used when working with CSS frameworks quite often. They give you a default style for a selector and you can copy the selector and override that style in a file which is added after the frameworks' files.
But of course it makes sense that styling an ID should have preference, since you give only exactly that one HTML element the ID, so the styling must be exclusive to that element as well.
You might have default stylings for table, but it makes sense table.sortable for example is a more specific styling for a table. It inherits the table styling and applies more or different styles when the table has class sortable as well.
All browsers implement CSS specificity.
Links:
See CSS Specificity on MDN
Cheat-sheet: Specifishity
So the answer.. or more of a task:
In your example, classes are more specific than pseudo-elements.
You will have to change selectors so they override themselves according to specificity. This takes a little time to set up, but at least you don't spam !important everywhere.
To quote the MDN:
Selector Types
The following list of selector types increases by specificity:
Type selectors (e.g., h1) and pseudo-elements (e.g., ::before).
Class selectors (e.g., .example), attributes selectors (e.g., [type="radio"]) and pseudo-classes (e.g., :hover).
ID selectors (e.g., #example).
Universal selector (*), combinators (+, >, ~, ' ', ||) and negation pseudo-class (:not()) have no effect on specificity. (The selectors declared inside :not() do, however.)
For more information, visit: "Specificity" in "Cascade and inheritance", you can also visit: https://specifishity.com
Inline styles added to an element (e.g., style="font-weight: bold;") always overwrite any styles in external stylesheets, and thus can be thought of as having the highest specificity.
In my stylesheet, .four-across li defines width: 174px; at line 8806. Below that rule at line 9603, .no-search-results defines width: auto;. However, the 174px rule is overriding an element with .no-search-results. Why would that be?
You should read about CSS specificity.
.four-across li is more specific than .no-search-results, so it have higher importance level.
Specificity is calculated by counting various components of your css
and expressing them in a form (a,b,c,d). This will be clearer with an
example, but first the components.
Element, Pseudo Element: d = 1 – (0,0,0,1)
Class, Pseudo class, Attribute: c = 1 – (0,0,1,0)
Id: b = 1 – (0,1,0,0)
Inline Style: a = 1 – (1,0,0,0)
by Understanding Style Precedence in CSS: Specificity, Inheritance, and the Cascade
Document order matters only when given specificity is exactly the same. In you example first selector is (0,0,1,1) and second is (0,0,1,0), so the first one overrides the second one, no matter how are they ordered within CSS document.
Read:
Reviewing CSS Style Priority Level
Understanding Style Precedence in CSS: Specificity, Inheritance, and the Cascade
In this case it's because a class and an element type are more specific than just a class, and it's favored over the order.
Two reasons:
The last rule scanned has precedence over those scanned previously, all else being equal.
The more specific the rule is (two specifiers as opposed to one) the higher the precedence.
I have a jsbin with a table of inputs, using bootstrap. What confuses me is that the style with
input.someClass {
background-color: blue;
}
is applied, as expected, but
.anotherClass {
background-color: green;
}
is not applied to my input elements. What is the reason for this? For reference, check out http://jsbin.com/enaris/3/edit
What is the reason for this?
It's simply a matter of specificity - the first selector has a type selector attached to the class name whereas the second selector only has a single class. The second selector is therefore more specific and takes precedence.
This is migrated from another answer of mine, it may help:
You can think of specificity as four numbers, starting with (0,0,0,0):
!important rules always take precedence, only another !important rule
can override a previous one (its an accessibility feature of CSS,
designed to override the UA stylesheet)
The universal selector (*) has a specificity of 0
Combinators like + and ~ also have no specificity
Inline styles have the highest specificity (other than !important)
and count as the first number (1,0,0,0)
ID's (#test) count as the second number in the above set (0,1,0,0)
Classes, pseudo-classes and attribute selectors are the third number
(0,0,1,0)
Type selectors and psuedo-elements (e.g. - <p> & ::after) take place of the
fourth number, and are the least specific
Remember that if two rules have the same specificity and specify the
same property the latter in the stylesheet will win
Based on the above, the first selector has a specifictiy of (0,0,1,1) while the second only has (0,0,1,0)
CSS rules are applied from least specific to most specific.
You have:
Least Specific More Specific Most specific
.anotherClass input[type=...] (bootstrap) input.someClass
So, in your example b-cell is more specific than bootstrap styles and a-cell is less.
You can force a-cell to take precedence with !important (but use !important with caution, as it might become a debugging hell):
.a-cell {
background-color: green !important;
According to the CSS docs:
http://www.w3.org/TR/CSS21/cascade.html#specificity
Specificity is defined by (amongst other things) the number of attributes and pseudo-classes in the selector.
So, my question is, is it possible to increase specificity by repeating the same classname over and over again?
For instance:
would
.qtxt.qtxt.qtxt.qtxt.qtxt
{
}
have a higher specificity than
.qtxt.lalgn
{
}
or
.lalgn .qtxt//(space added to create child selector)
{
}
?
Yes, it is possible and intentionally so. While this is not mentioned in the CSS2 spec, it is explicitly mentioned in the Selectors 3 spec:
Note: Repeated occurrances [sic] of the same simple selector are allowed and do increase specificity.
Therefore browsers must increase the specificity when encountering repeated simple selectors, as long as the selector is valid and applicable. This not only applies to repeated classes, but also applies to repeated IDs, attributes and pseudo-classes.
Given your code, .qtxt.qtxt.qtxt.qtxt.qtxt will have the highest specificity. The other two selectors are equally specific; combinators have no bearing in specificity calculations at all:
/* 5 classes -> specificity = 0-5-0 */
.qtxt.qtxt.qtxt.qtxt.qtxt
/* 2 classes -> specificity = 0-2-0 */
.qtxt.lalgn
/* 2 classes -> specificity = 0-2-0 */
.lalgn .qtxt
Also, the space in your last selector is the descendant combinator; the child combinator is >.
.qtxt.qtxt.qtxt would have the highest specificity...
http://jsfiddle.net/nXBTp/1/
However, this is only the case if you repeat the class name more times that any other selector, for example:
http://jsfiddle.net/nXBTp/2/
You shouldn't need to hack specificity like this... if you need to force a value, use !important.
I've looked at similar questions here but I haven't found one particular to my case.
If I read this article correctly: http://css-tricks.com/specifics-on-css-specificity/
then what is happening doesn't make sense to me. Can someone explain if this is due to locality, inheritance or specificity please? I've stripped out all the unrelated css.
CSS
a:link {font-size:0.875em;color:#005984}
.button {color:#fff}
HTML
<a class="button">Awesome call to action</a>
I end up with a button that has blue text, instead of white. Now, a is an element, so it should have lower specificity than the .button class, should it not?
Thanks for your time.
This is due to specificity: although a is an element type selector which is less specific than a class selector, it's accompanied by a :link pseudo-class which is equally specific to your .button class. A type + pseudo-class will therefore be more specific than a class.
There is no inheritance going on here as there are no parent element styles that I can see being applied to your element. Inheritance refers to adopting styles from parent elements. When you see the link displaying blue instead of white, that's the cascade at work, not inheritance.
Locality isn't a CSS term (at least not in its glossary), so I'm not sure what you mean by that.
If you need your call-to-action button to be white, simply give it the a selector as well, so your selectors are equally specific and the last declaration will take precedence:
a:link {font-size:0.875em;color:#005984}
a.button {color:#fff}
A selector's specificity is calculated as follows:
- count the number of ID selectors in the selector (= a)
- count the number of class selectors, attributes selectors, and pseudo-classes in the selector (= b)
- count the number of type selectors and pseudo-elements in the selector (= c)
- ignore the universal selector
Selectors inside the negation pseudo-class are counted like any other, but the negation itself does not count as a pseudo-class.
Concatenating the three numbers a-b-c (in a number system with a large base) gives the specificity.
So:
a:link
- a=0
- b=1
- c=1
- Result = 011
.button
- a=0
- b=1
- c=0
- Result = 010
Result: a:link is higher than .button.
Fix: :link won't work on anything but a tags anyway, so specifying a:link is redundant. Use :link instead, and that will fix the problem (provided .button is defined after :link)