I was just looking at Inspect Element on one of my nested unordered lists and I noticed that one of my selectors with 2 ids is being ranked lower than the selector for a mere list element li. Does this have something to do with the media query that encloses the selector with 2 ids? Or why is this?
What you are seeing is not due to media queries but due to how inheritance is handled in CSS. Take the example below:
#super #specific {
color: blue;
}
p {
color: orange;
}
<div id="super">
<div id="specific">
<p>Paragraph text</p>
<div>Div text</div>
</div>
</div>
Even though you have a style that has a specificity value of 0200, the value of 0001 seemingly overrides it. From what I can tell the reason is due to how CSS calculates the specified value.
According to the spec, it first goes through the cascade to determine any values. If no values found then it will see if anything is inherited. Last it will use any default value for that element. Since the blue color in my example was passed to its inner elements through inheritance, that means that any CSS value applied to the inner elements would override that. It's also why the use of the inherit value in CSS is so important because it allows you to set inheritance as part of the cascade making sure those values take the correct precedence instead of just allowing it to default to it.
Related
Earlier to apply styles to a sidebar we would write the following
<div id="sidebar">
<p>Some text...</p>
</div>
and the corresponding CSS to set the color to Red would be like
#sidebar p{
color: Red;
}
The CSS Specificity here is {0,1,0,1}
In HTML5 We have the aside element that could be used as
<aside>
<p>Some text..</p>
</aside>
and the CSS to set the color to Red would be
aside p{
color:Red;
}
By using the HTML5 element the CSS Specificity is {0,0,0,2}
Using HTML5 elements improve the semantics. But HTML5 elements reduce the CSS Specificity. Provided that the target browsers support all HTML5 elements which among the 2 approaches would be appropriate?
Provided that the target browsers support all HTML5 elements which among the 2 approaches would be appropriate?
The latter approach using HTML5 elements would be the best approach, however there are two things to consider regarding rule specificity:
HTML5 is better at reducing clashes based on just element name alone as there are more of them, and when used correctly. Consider:
<div class="section">words...<div class="aside"><p>an aside</p>
versus
<section>words...<aside><p>an aside</p>
The latter is better as the semantics of the document are within the tags themselves.
When you are reusing a structure, its fine to add id and class attributes to make structure clearer.
<section>words...<aside><p>an aside</p>
<section>copyright...<aside><p>year of copyright</p>
versus
<section class="article">words...<aside><p>an aside</p>
<section class="copyright">copyright...<aside><p>year of copyright</p>
Here, the class on the latter adds context and reduces rule ambiguity.
So ultimately the answer to your question is use HTML5 elements intelligently with classes where appropriate.
According to MDN doc
The specificity is a weight that is applied to a given CSS
declaration based on the count of each selector type. In the case of
specificity equality, the latest declaration found in the CSS is
applied to the element. Specificity only applies when the same element
is targeted. CSS rules that directly target an element will always
take precedence over rules that an element inherits from an ancestor.
Then the tag, is lower then class, lower then id,
Also are evaluated External css link file precedence, and inner /in line css declaration.
For this kind of information you can refer to specific browser (engine)
for Mozilla you can refer to this doc https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity
In your case you have a id css rule (more spcecific) and a tag css rule (minor specific)
I'm reading the book: CSS Mastery: Advanced Web Standards Solutions, and finding the css code inside is almost writed in this format:
elementName#idName
elementName.className
but, I'm used to write code ignoring element name with this format:
#idName
.className
so, I want to figure out what difference is between the two format.
Actually, I understand when should use type.class. And, I just want to find out the impact when I use type.class insead of only using .class when there is only one kind of tag here.
There must be some impact on performance.
Here's a real life scenario as when to use elementName and when to just use class or id name:
HTML:
<a class="blue">I'm blue and underline</a>
<span class"blue">I'm blue and bold</a>
CSS:
.blue {
color:blue //will make both <a> and <span> blue
}
a.blue {
text-decoration:underline // will make only the <a> tags underline
}
span.blue {
font-weight:bold //will make only the <span> tags bold
}
but remember when it comes to IDs you should not have duplicate IDs on your page anyway, this is more practical for classes
The difference between the two is that the first:
element.class
Is calling the element with that specific class.
And the second:
.class
Is calling all elements that contain this class
I think that the element inclusion in the selector is a holdover from days where some browsers required it (I think IE5 does, but I could be wrong). This is no longer necessary, and it does not make sense to include element selector for at least three reasons:
It slows the selector down since the element selector is slower than the other two -- especially id. Assuming selection is optimized so that fast selection is done first (e.g. the element with the matching id is found before the element selector is checked), there is still the additional step of checking the element selector.
It's not as extensible since you can't change the element without also having to change the selector. The implication is also that div.class would function differently than label.class, but I think that the class should be descriptive enough.
It changes the specificity of the selector. This could be very frustrating for some developers who may want to change <div class="foo"> from green to red:
div.foo { color: green; }
/* below is not applied since the above has higher specificity */
.foo { color: red; }
I've never heard an argument that supports type.class unless old browsers need to be supported.
In my CSS I have the following:
.myDiv{
float:left;
width:100px;
height:100px;
}
.yellow{
background:#faf8c7;
}
.lightGrey{
background:#f8f8f8;
}
In my HTML
<div class="myDiv lightGrey yellow"></div>
This should display the div as the yellow colour but instead it is lightGrey.
If I change the order of the .yellow and .lightGrey in my CSS (not HTML) then the div becomes yellow...why is this?
Surely it should be the order that the classes are written in the HTML that determines whether the div is yellow or grey. The order of the CSS should be irrelevant.
surely it should be the order that the classes are written in the html that determines whether the div is yellow or grey
It's how the cascade was defined:
Find all declarations that apply to the element and property in question, for the target media type. Declarations apply if the associated selector matches the element in question and the target medium matches the media list on all #media rules containing the declaration and on all links on the path through which the style sheet was reached.
Sort according to importance (normal or important) and origin (author, user, or user agent). In ascending order of precedence:
user agent declarations
user normal declarations
author normal declarations
author important declarations
user important declarations
Sort rules with the same importance and origin by specificity of selector: more specific selectors will override more general ones. Pseudo-elements and pseudo-classes are counted as normal elements and classes, respectively.
Finally, sort by order specified: if two declarations have the same weight, origin and specificity, the latter specified wins. Declarations in imported style sheets are considered to be before any declarations in the style sheet itself.
#4 is the part you're struggling with, the declarations have identical specificity, and therefore the latter one is winning.
Cascading Style Sheet.
That means that style that appears later in the stylesheet will overwrite style that appeared earlier in the sheet.
order in your html code of each class myDiv lightGrey yellow is not important at all, it's like you say : I bought 3 colors, but we don't know what is the first or the last you bought
since all rules have the same specificity, the last one (for the meaning of Cascade) specified in the CSS wins. In other words, no matter you re-arrange your classes in the markup, with the given style your background is always lightgray.
Surely it should be the order that the classes are written in the HTML that determines whether the div is yellow or grey. The order of the CSS should be irrelevant.
for the above explanation it's the opposite
Given two classes of equal specificity defining the color property I thought the last class listed in the element class attribute would take precedence.
From http://htmlhelp.com/reference/css/structure.html:
Order of Specification To make it easy, when two rules have the same weight, the last rule specified wins.
In the following vacuum code example the order in which the class rule set is defined determines precedence. Here the last, or most recent, class rule set definition takes precedence.
<style>
.makeBlue {color: blue;}
.makeGreen {color:green;}
</style>
<div>
<p class="makeGreen makeBlue">makeGreen makeBlue</p>
<p class="makeBlue makeGreen">makeBlue makeGreen</p>
</div>
The output text is green.
If I swap the order of class declaration, and declare .makeGreen first
<style>
.makeGreen {color:green;}
.makeBlue {color: blue;}
</style>
<div>
<p class="makeGreen makeBlue">makeGreen makeBlue</p>
<p class="makeBlue makeGreen">makeBlue makeGreen</p>
</div>
The output text is blue.
I've never noticed this before. edit I thought edit the last class listed in the element class attribute takes precedence.
edit
To clarify -->
I sometimes think of an element as a pet, let's say a dog. I see adding a class to the element's class attribute as issuing the dog a command. If I tell it to sit, and later tell it lie down, I expect the dog to lie down. I do not expect the dog to remain sitting simply because I taught it how to sit after (more recently than) I taught it how to lie down.
So... two questions.
Is this how it is supposed to be? answered
If so... why? I am unable to see the advantage of having to dig through class
declarations in order to determine which was declared before the other.
Much thanks!
The order of the classes as you specify them on the elements is irrelevant. It's the order that you define them in your style declarations that matters. The quote you posted means in the style declarations, not the order the classes are listed on the elements.
This seems to limit options. If I want to use two classes on two different paragraphs but have the precedence be different, I'd need to define a third class that is the same as the first defined class but with a slightly different name.
e.g
.xxxxx {margin-top: 1em; margin-left: 0; text-align: left; ... [some other attribute definitions]}<br/>
.yyyyy {margin-top: 3em; margin-left: 1em; text-align: justify; ... [some different attribute definitions]}
<p class="yyyyy xxxxx">...</p>
will always use a top margin of 3em with a left margin of 1em and a text alignment of justify plus the other attributes in xxxxx and yyyyy. However, there might be a situation in which I want to override the margin-top, margin-left, and text-align settings while keeping all of the other attributes in xxxxx and yyyyy. If precedence was determined by order in the class attribute then I would have that option by doing this:
<p class="xxxxx yyyyy">...</p>
Since it is not, I have to create another definition below the two in question, as so:
.zzzzz {margin-top: 1em; margin-left 0; text-align: left; ... [some other attribute definitions]}
and use
<p class="yyyyy zzzzz">...</p>
This seems like a non-optimal solution to the problem whereas class attribute order precedence allows more flexibility without mucking up the CSS.
BTW, the Nook Glowlight does it the way it should be done by allowing me to set precedence by the order in the class attribute. And thus my css is a bit more compact.
If there is anything that I've learned in my decades of programming, it's that precedence is best placed as close as possible to where all the work gets done. Placing precedence in a linked static stylesheet reduces flexibility.
I have a div with an ID:
<div id="main">
What's the correct (or difference) between
div#main {
and
#main {
Regards,
There is a great doco on using efficient CSS selectors, focus on rules with overly qualified selectors:
ID selectors are unique by definition. Including tag or class
qualifiers just adds redundant information that needs to be evaluated
needlessly.
Instead of just applying the style to an element with id main, your selector will re-qualify the element by checking whether or not it's also a div (in that order). To clarify: css selectors are evaluated right to left, unlike same selector syntax when used in jQuery etc.
Re pixelistik's suggestion that div#main is more specific than #main - yes, that is technically correct, however if you have to resort to this to raise a rule's specificity, chances are the structure of CSS you're working on is not as thought through as it should be.
#main matches everything with ID 'main', whereas div#main matches only <div> elements with ID main.
Ideally, you should never have two elements with the same ID, so realistically the two don't make a difference, but there's probably performance related issues regarding whether specifying div makes it find the result faster.
So difference is that:
When you write div#main style will be only for <div> element.
When you write #main it can be used as style for <div>, <span>, <p>, etc.
And what recommend is hard to say, every developer it has it different. So i using for example
span.<nameClass> when is nested in <li> for example.
#nav li span.href a {
...
}
I think it's used when you want that someone class with specific name can have only one element.
So when your write span#href it will works only for <span id="href">Simply dummy text</span> not for others. When you write #href it will works for <span id="href">Simply dummy text</span> or Link but both are correct when you also asking about this. Differences i wrote above.
Both are correct.
div#main is more specific than #main, which means that styles defined with the first selector will override the ones of the second.
Here's a good introduction to CSS specifity:
http://htmldog.com/guides/cssadvanced/specificity/