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
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 */
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.
I have a css file that have following css element:
.ms-webpart-chrome {
background-color: white;
}
I want to make it transparent instead of white and same time I want to have this css element like it is beacuse its a global css and some pages are using it.
So I was thinking that I could use inherance it.
This is how it looks in html and this div classes are generated automaticly which means I cant change or do anything.
<div class="ms-searchCenter-main">
<div class="ms-webpart-zone ms-fullWidth">
<div id="MSOZoneCell_WebPartWPQ1" class="s4-wpcell-plain ms-webpartzone-cell ms-webpart-cell-vertical ms-fullWidth ">
<div class="ms-webpart-chrome ms-webpart-chrome-vertical ms-webpart-chrome-fullWidth ">
So basicly I need to have this one like it is beacuse i dont want to change it or remove it:
.ms-webpart-chrome {
background-color: white;
}
And I need to create a new one and use !important with the inherance.
Any kind of help is appreciated
Note: I tried following:
.ms-searchCenter-main .ms-webpart-chrome
{
background-color: transparent !important;
}
but it didnt work
You can certainly specify a background color to be "transparent," as this is the default value in the CSS specification (see reference page at w3schools.com).
If your goal is to make the background color transparent across all elements with class "ms-webpart-chrome" then try adding more selectors to increase the weight of your new rule:
body div.ms-webpart-chrome {
background-color: transparent !important;
}
Setting "background: none;" is also an option. You could try adding both.
It would be better if your new rule followed the other rule (not directly, just after it in the order). Also, check to see if any of the sub elements are picking up a background.
While IE has developer tools, I strongly recommend Firefox + Firebug + DOM Inspector + Web Developer Toolbar as a standard testing suite. You can easily traverse the DOM to see if any sub elements have backgrounds applied, as well as test different CSS rules live on the page.
You can't specify a background colour to be transparent, as transparent isn't a colour. However, you can achieve it with background: none !important;. Element's don't have background colours by default, so just restore it to the default (none) and it will be transparent.
Look at this demo here. I've set the background to red at the top, but then over-written it with background: none; lower down. This makes it transparent. The red border shows where the element is
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.
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.