How can this situation happen? (image is from chrome css inspector)
-there is no higher priority rule above
-there is no orange exclamation mark (error)
-I have NOT deactivated it manually in Chrome
Computed:
In developer tools, go to Computed tab beside Style Scroll down and look for those two properties. Expand it and you'll see which file and line number is applied to it
It is very difficult to answer your question by just looking at that image. The rules for CSS rule cascading are complex. I'll refer you to the spec:
https://www.w3.org/TR/2011/REC-CSS2-20110607/cascade.html#cascade
In short: more specific rules override more general ones. Specificity is defined based on how many IDs, classes, and element names are involved, as well as whether the !important declaration was used.
When the !important keyword is used on a specific property/value pair, it will cause that particular value to escape the cascade and become, as the name suggests, the most important value for that property, overriding any others. description here
Related
I am taking practice test for Microsoft 70-480. I came across the question in the image. To select attributes that end in specific given value should be a css attribute selector such as [attribute$='value']. I don't understand how we make that selection with a css pseudo-element. Can some one explain to me why
As you've correctly stated, you need an attribute selector for this (although you would need to use [attribute*=value] instead), and you can't match elements using pseudo-element selectors (that's why they're called pseudo-elements!).
The only explanation for the "correct answer" here being option C is that whoever wrote that test either made a mistake with the options, or doesn't understand CSS selectors. Hopefully the former.
I am adding some style to a webpage, but I am having a problem, I added a rule, and chrome developer tools say that is computed, but it is not applied. What this mean?
I'm not sure if this is always the case, but I think this generally means that its been overridden by another rule with a higher degree of specificity.
CSS rules are graded in terms of how specific they are to an element, and when rules clash, then the most specific will be given precedence.
You can address this by adding a class directly to the element, or by making your rule stricter (more specific).
In my case I solved the problem adding -webkit-appearance: none. Apparently google dev tools don't show webkit appearance but apply that.
I recently completed an assignment that had this question:
Within a CSS rule set, a selector includes
a selector and a declaration block
a selector and a value
a property and a selector
a property and a value
The correct answer given was option 4.
I don't quite agree with the answer. In fact, none of the answers seem correct to me, but I wanted to make sure I wasn't misunderstanding the question.
I would appreciate if someone could confirm if the question is flawed or explain the answer if it was indeed correct.
As W3C (World Wide Web Consortium says, a selectors are:
patterns that match against elements in a tree, and as such form one of several technologies that can be used to select nodes in an XML document.
Mozilla Developer Network describes CSS rules here.
Indeed, a CSS rule includes a selector, a property and a value.
Personally, the sintax of the question is a bit awkward, but it is not flawed.
In CSS A "rule set" (or just "rule") consist of a "selector" and a "declaration block".
A "declaration block" consists of "declarations" between curly brackets.
Each "declaration" contains a "property", a colon and a "value" separated from each other within the "declaration block" by a semi-colon.
So you are right. None of the options match, and option 4 is the definition of a "declaration", not a "selector".
See 4.1.7 Rule sets, declaration blocks, and selectors and 4.1.8 Declarations and properties
It's correct:
div { margin: 0; }
The whole line is a rule set
div is a selector
margin is a property
0 is a value
When using the same CSS property in one rule set, in the case of needing to provide a fallback for browsers that don't support a property you may be using, like so:
body{
background: rgb(255, 255, 255);
background: rgba(255, 255 ,255, 0.5);
}
Do browsers that understand both of these declarations render the first, then overwrite it with the second? Or does a browser save itself the hassle and only render the latter?
Edit: I am aware that if a browser understands both declarations it will render the latter, but I want to know if the browser renders/draws the first into the viewport and then overwrites it with the second or does a browser work in a way that means it only renders the one declaration that is required, potentially saving itself resources?
I would expect modern (and probably old) browsers to parse the CSS rules supplied to it before rendering anything. Here's a screenshot from the Chrome profiler for both rules:
And here's another, for only the first rule:
As you can see, there are no extra steps involved when two different rules are present. If the browser was to render it twice, you would see another "Paint". (The slight reduction in paint time for the single rule is likely to be because I removed the rgba rule, so the browser did not have to take transparency into account).
the last of the 2 will be applied
To be more precise: the first will be applied, then the second.
It would be the same as having 2 identical selectors setting the background property.
The one most descriptive will be applied. If they are the same, the last declared will be the one applied.
The "C" in CSS stands for Cascading which means styles can add to or supercede preceding CSS rules. So the second declaration will override the first.
Browser handle this correctly. You can use that kind of rules.
For example, chrome will apply rgba, and IE8 will apply rgb.
Browsers in general apply the following algorithm:
for each element in the DOM tree
for each CSS rule
if rule's selector matches element
apply all declarations in rule
render
This is not how it works:
for each CSS rule
for each element in DOM tree
if rule's selector matches element
for each declaration in rule
apply declaration
render
That would be a huge performance problem.
It follows from the basic UA conformance requirements that browsers must first parse all CSS rules, then decide, by the principles set in the specifications, what values shall be used for each property of each element. There is no allowance for “incremental rendering” in the sense of applying part of the CSS code before reading the rest. And it would be very odd for a browser to deviate from this, as it would mean more work to implementors, more complaints from authors and end users, and no benefits.
I'm curious what the difference is b/w E#myid vs. #myid (E is any element) given that there can only be one element with #myid on a page?
It must be a bug/mistake of you that #myid has no effect on the input element. It works fine for me.
As you changed your question:
Image you have two different documents that both use the same stylesheet. In one document a DIV element has the ID “foo” and in the other document a SPAN element has the same ID. You can then use the following stylesheet to style both element different:
#foo {
color: #FFF;
}
div#foo {
background-color: #F00;
}
span#foo {
background-color: #0F0;
}
Both elements would then have the same font color but a different background color.
They have different specificity.
http://www.smashingmagazine.com/2007/07/27/css-specificity-things-you-should-know/
The two selectors have different specificity. Rules given in a more specific selector will override rules given in a less specific one.
The specificity rules are really easy. Whenever there is a conflict (two or more rules setting different values on the same element), the following rules are consulted in order:
1) What 'space' does the rule live in? A rule in a higher 'space' automatically wins against rules in lower spaces:
a) Set by the user's stylesheet, with !important
b) Set by the author's stylesheet, with !important
c) Set by the browser's stylesheet, with !important
d) Set in a style="" rule
e) Set by the user's stylesheet, without !important
f) Set by the author's stylesheet, without !important
g) Set by the browser's stylesheet, without !important
2) How many #ids are in the selector? Selectors with more #ids automatically win against selectors with less (assuming they tied in rule #1).
3) How many .classes or :pseudoclasses are in the selector? Selectors with more .classes automatically win against selectors with less (assuming they tied in the previous rules).
4) How many plain elements are in the selector? Again, more is better.
5) Finally, how far down in the document is the rule? Later rules override earlier rules, if they are tied on all previous categories. This applies within a document (at the bottom of your CSS file vs at the top) and between documents (any rules in the second <link>ed css file are 'later' than the rules in your first <link>ed css file).
Understanding specificity can help you write simpler CSS. I almost always start my selectors with the closest #id that I can, because it simultaneously limits the spread of the selector to exactly the elements that I want, and automatically overrides any 'global' css rules I may have set in the document.
The difference is that in different pages you could have different elements using that ID. Why you would do that, is beyond me, but it could be needed for (just an example) a div on some pages taking the same attributes as a span on other pages.
Different browsers will give you different and strange results on non specified corner cases. Some browsers allow for multiple elements sharing the same id, others don't. It even changes with different versions of the same browser. Without knowing wich browser you are using, it's harder to replicate the bug, but I recommend you to test your css on several browsers.
Along with the other folks points about ID not necesarily being unique on a page...
It is possible to have one ID applied to either of N different elements (eg <UL Id=MyList> or <OL Id=MyList>). Then you could have different bits of javascript to handle the various elements (ie. a bit of code to handle UL, a different bit of code to handle OL).
Not saying whether or not that's would be a good design... just saying that it's possible.
Edit: what I mean is that the server side could generate a page with either an <OL> or a >UL>... not both at one time. Think dynamic web page. And again... I'm not saying one way or another if this is a good design... just that it IS POSSIBLE.