I'm playing around with some CSS and so far all of these seem to do the same:
background: url('/images/file.png');
background: image-url('file.png'); /* Doesn't requires as much info about the path. */
background-image: url('/images/file.png');
Is there a difference or is it just up to preference?
Your first property declaration is a shorthand:
background: #COLOR url('image.png');
This is equivalent to this:
background-color: #COLOR;
background-image: url('image.png');
By omitting the color, you are just specifying the image.
And info on the property from the CSS2 spec:
The 'background' property is a shorthand property for setting the individual background properties (i.e., 'background-color', 'background-image', 'background-repeat', 'background-attachment' and 'background-position') at the same place in the style sheet.
The second one is invalid CSS.
The second one is just invalid CSS. Don't use it.
The third one is preferred, as it doesn't reset the other properties (also from the spec):
Given a valid declaration, the 'background' property first sets all the individual background properties to their initial values, then assigns explicit values given in the declaration.
Related
I'm wondering what happens if a CSS style is supplied for a property which the browser supports, but the style itself isn't supported.
Take for example the following in IE8;
background: url(../path/to/img.png);
background: rgba(0,0,0,0.8);
Does IE8 simply ignore the second style due to it's lack of supported for CSS3 colours?
Thanks :).
Does IE8 simply ignore the second style due to it's lack of supported for CSS3 colours?
The answer is YES, it will completely ignore that value, and hence it won't render any color, it's a common practice to use a fall back with a hex value like
.class_name {
background: #000;
background: rgba(0,0,0,.5);
}
So, when you write the background twice, it's completely valid, the browsers who understand the rgba() will render an opaque background, but the browsers who don't understand rgba() will use #000.
Though, there are various workarounds for that, like, you can use :before or :after, with filter property with a negative z-index, which can be used as an opaque background, or you can do is, use a normal 1x1 px opaque png image only for IE8.
For example
background: url("IMAGE_URL_HERE")\9; /* Targets IE8 and below */
My goal is for all cells in a table to have a background color except ones with the class 'transparent'. Here is some sample code (corresponding jsfiddle):
<style>
td { background-color: red }
td.transparent { background-color: none }
</style>
<table>
<tr>
<td>foo</td>
<td class="transparent">bar</td>
</tr>
</table>
Why doesn't the td.transparent cell follow the td.transparent css rule? When I inspect the element the rule is there, but it is getting overridden by the td rule, which seems to break normal css specificity rules.
I can get what I want by using rgba(0,0,0,0) instead of none, but rgba is not supported in IE8 and I would like to avoid using an ugly hack if I could.
I'd also like to simply understand why this isn't working the way I expected.
Thoughts?
The value needs to be a valid color, and none is not a valid color. Instead you can use transparent (similar to rgba(0,0,0,0) but more widely supported). If that's no good you can always go with white or use a more specific rule for the red background instead.
For what it's worth: you could replace background-color:none with background: none and it will work.
None isn't a valid color, instead use transparent.
jsFiddle demo
td.transparent {
background-color: transparent;
}
Alternatively, you could also use the following:
The reason this works is because it is stating there should be no background in general. It is not referring to a specific color as in the first example.
td.transparent {
background: none;
}
jsFiddle using this method.
As a side note, usage of CSS3 colors (rgba) is not 100% supported. Reference here: http://caniuse.com/css3-colors
In addition, I would like to say that all of this could be avoided if you didn't set an inital background-color in the first place. There would then be no reason to overwrite the original style if this were the case.
The proper syntax (for CSS2.1) is:
background-color:transparent;
http://www.w3.org/TR/CSS2/colors.html#propdef-background-color
Another alternative is to reset the property to the value from the parent element (inherit) or to the default value set by the browser for the property (initial)
In my particular case where I needed to override the background color, background-color: initial; is what fixed the issue.
I just took a look on CSS background-clip. Its a way to mask text with an image. (or the other way round? ^^). Anyway, i thought the order of statements in CSS doesn't effect the result, but with background clip it does.
The CSS for this effect looks like this usually:
.text{
color: transparent;
background: url(pic.ending);
-webkit-background-clip: text;
}
So, this is the first <p> in the fiddle below.
But when I change the order of this to following:
.text_wrong{
-webkit-background-clip: text;
color: transparent;
background: url(pic.ending);
}
It doesn't work. The text isn't masked, the background takes place in the hole <p>. So the error occurs when background clip is before background, right?
Why? Do you have any idea? Sorry for my bad English. (Heres the fiddle.)
background is the shorthand notation for the background properties. This will overwrite all other background rules made earlier. Even though -webkit-background-clip has a vendor prefix it is still a background property. In your second example it gets overwritten when you set the background properties with the shorthand notation.
To make your example work you can use background-image instead of background.
Example
/* sets a single property */
background-color: red;
/* overwrites all single properties */
background: no-repeat;
Demo
Try before buy
This is called Cascading and the ulimate goal of CSS is to represent those items that are declared last in the cascade.
For instance, lets assume the below to be your CSS declaration in stylesheets.
div{height:15px;}
div{height:30px;}
div{height:20px;}
So the div will take the height to be 20px as this is the last declared rule and it will override all the other rules declared earlier.
Hope this solves your query.
According to the w3c specs the value text for background-clip is not a listed value in the specs. Therefor support might be buggy!
http://www.w3.org/TR/css3-background/#background-clip
Determines the background painting area, which determines the area
within which the background is painted. The syntax of the property is
given with
= border-box | padding-box | content-box
For example, if we need to set a div's font-size to 22px, is there a possible way to let the descendants of this div still inherit from the font-size from body? (or any inheritable style, thanks to #Sourabh for pointing out background is not inherited).
I think a key point is that so that we can change the style of body or some parent and let it pass through, even though there is an intermediate change of style. So preferably, we won't do it by:
body, #foo * { font-size: 16px }
#foo { font-size: 22px }
This is related to the case as described in How to solve flicker on iPad when event delegation is used? , where the -webkit-tap-highlight-color need to be set for a div, but the descendants of this div will be best to inherit what is above this div (the parent of this div).
I can use JavaScript to put the style of this div in a temporary variable, and then change the div's style, and then change the style for just the immediately children of this div to the value of that temporary variable, but then whatever that is set for the style of body won't get inherited by those children or their descendants.
No. In the DOM, a descendant element will inherit any inheritable CSS of the parent(s). You can 'reset' it back to match the parent item by declaring it again, but you can't do exactly what you are asking which is only changing the BODY style declaration.
Off the top of my head, the one solution I can think of would be not rely on pure inheritance from the body element but instead create a class and use it on all elements where you want to control aspects from one declaration. That still may be tricky due to CSS specificity, though.
If I'm understanding your question correctly, you could use a > combinator like so:
Working Example
body, #foo { background: yellow }
#foo>* { background: blue }
or like so:
Working Example2
body {
background: yellow;
}
#foo {
background: blue;
}
#foo>* {
background: yellow;
}
W3C background-color Stats
Initial: transparent
Inherited: no
All elements are transparent regardless of their parent's background-color. But that color is transparent so parent's color is visible on the child. So basically, if you want them to inherit color, you can't (not with CSS at least) (there might be a trick that I am not aware of). You have to specify the color for every element if you don't want it to be transparent.
The answer is not quite.
You can reset a property to its initial values by using the initial css keyword, which is particularly useful for these user-agent set styles (like -webkit-tap-highlight-color)
See this jsFiddle.
Note however that this isn't the value that would be set by default if the parent didn't exist, but literally the browser's default setting. In particular, body level formatting is not taken into account.
I've also included the default keyword, which is effectively the same as not including any font-size specifier at all - it goes up the cascade chain to find one that has a font-size specified, in this case on the element-name selector.
As I understand it, when you use the shorthand property background, the browser first sets all background properties to their default values and then puts in the values that you're declaring. Is it then better to use background-color:white; instead of background:white? Does this change when you are putting in more values such as background position or background image? Or is it always best to declare attributes individually?
I'm thinking that there must be some sort of tipping point where the savings in bytes balance the processing time gained by specifying attributes individually. However, I could be completely wrong - that's why I'm asking here.
I hear you about best practices, but as mentioned the differences in processing and even load time are negligible. There is no best practice for when to use these rules, aside from what makes sense in your stylesheet. The real difference is that they effect inherited properties differently. Setting background-color: white; will only overwrite the background-color rule (whether or not it was originally set with background or background-color) but background will overwrite the any/all background rules set, thus potentially killing background images and associated background-repeat, etc. Here's an example:
.box {
background: url(star.png); // set with just background instead of background-image
width: 100px;
height: 100px;
float: left;
margin: 10px;
}
.box1 {
background-color: blue;
}
.box2 {
background: green;
}
With HTML like:
<div class="box1 box"></div>
<div class="box2 box"></div>
.box1 will show the star.png image (with a blue background if the image is transparent), while .box2 will only show a green background, no image. The best practices lesson with these two rules is to evaluate CSS authoring and inheritance in general — not rendering performance. That in mind, it's generally best to apply background to the most general/abstracted rule of an element, and then overwrite properties on more specific instances, using classes or IDs, with background-color, background-image, etc.
The processing time of your CSS should be neglectable. If you're restraining from using them just because of that, well, don't restrain yourself anymore.
When using just a color, background: color and background-color: color should give the same result.
At then end it boils down to if you prefer shorthands to individual declarations. Usually, shorthands will use sensible defaults values, so it's all right. I usually don't remember the correct order for them (especially the font shorthand), but other than that I think they're fairly okay.
You might be using much more shorthand properties than you expect, anyways. For instance, margin and padding are the shorthands of their -top, -right, -bottom and -left components, and border is the shorthand for border-width, border-color and border-style, which are all shorthands for their border-[direction]-[attribute] properties. By using border instead of all the non-shorthand properties, you're saving like 11 lines.