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.
Related
So I had this idea to use EM values for borders on a bunch of elements as variables, based on a parents font-size, this would reduce a lot of redundant code for me. It all worked fine until I realized that some browsers/users have a minimum font-size, that you cant over ride.
The minimum values in some browsers seem to range from 6px to 12, or even more if the user has modified it. As Im not using this for font size it, is there any other trick i can use to set the width of a border without hard coding a pixel value?
Below is an example of what I was hoping would work cross browser, but for example in Firefox/Cyberfox, for me, it gives a 6 pixel wide border instead of 2 px:
.parent{
font-size:2px;
}
.child{
border:1em solid black;
}
<div class="parent">
<div class="child">
Hello world!
</div>
</div>
requirement: no sass, no js, just need pure css.
As someone else has mentioned in commends, em pixel equivalent is based on the parent font-size.
When dealing with user stylesheet overrides, you can never fully guarantee that your styles will override those of the end user. You can however utilize the !important directive and make your rules as specific as possible. You can go overboard quickly, so just test and use reasonable defaults.
html body .parent{
font-size:2px !important;
}
.child{
border:1em solid black;
}
This is going to be a specificity game, but !important is your strongest asset.
We are developing a widget that is intended to be embedded into 3rd party websites. The way it's embedded is dynamically injecting a div inside the body part of the page, using Javascript.
On a page without any or few style rules, the widget looks fine. The problem is: we are seeing various visual issues caused by the widget's style rules overriden by the web page (let's call it host page) it's on, when the host page has many CSS rules, some of which happen to trump the widget's if the widget does not define those rules explicitly (thus the widget inherits these from the host page).
It seems to me the obvious solutions to this is: define ALL CSS rules for each of the elements in the widget. When I say ALL, I mean all CSS rules like background color, etc. for all states like normal, focused. This obviously is a brutal force method, and can result in a good amount of work for just a simple widget. This doesn't really seem too smart.
So my question is: is there any clear-cut facility that allows one to prevent the host page's styles from messing around the widget's?
To give an example, let's say the host page has a CSS rule like this:
div {
border-bottom: 1px solid green;
}
This rule sets the bottom border to transparent for all div's.
Then we merrily define a whole bunch of rules in our widget, except we forget to define the border-bottom rule. In such a situation, all the div's bottom borders are green.
While it's reasonable to add a border-bottom rule for the widget to address this particular issue, the real problem is: you can't control what rules are present on the host page, therefore, in order to be really safe, you have to define ALL rules for ALL elements in the widget for ALL states, which is really cumbersome and error prone for me.
We are aware using iframe would be immune to such issues, but we prefer not to use it, and let's keep it out of the discussion.
We are also well aware of the method to use !important in CSS rules to override previous rules. But this still requires defining full CSS rules (i.e., the brutal force method). Please keep it out of the discussion too.
Thanks.
The all: initial; CSS property is what you are looking for :
The CSS all shorthand property resets all properties, apart from
unicode-bidi and direction, to their initial or inherited value. [MDN]
but it currently has low browser support.
Here is an example of how it can be used :
div div {
display: inline-block;
width: 50px;
height: 50px;
margin: 10px;
background: gold;
border-bottom:5px solid green;
}
#wrap div {
all: initial;
display:block;
height:10px;
background:pink;
margin:1px;
}
<div>
<div></div>
<div></div>
</div>
<div id="wrap">
<div></div>
<div></div>
</div>
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
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
While some people use this reset.
* {
margin: 0;
padding: 0;
}
Is every element has default margin and padding in each browser default stylesheet( but differently)?
While eric meyer collected some most used selectors and given this to all
{
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-size: 100%;
vertical-align: baseline;
background: transparent;
}
Are those elements has different type of font sizes?
different baseline, different background, outline and border?
if we keep besides cons of universal selector.
is this
* {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-size: 100%;
vertical-align: baseline;
background: transparent;
}
better than this
* {
margin: 0;
padding: 0;
}
You can find all default styles here: CSS2.1 User Agent Style Sheet Defaults.
If you investigate the list closely, then you'll notice that the browser-specific margins are only set for HTML-standard block elements and that nowhere a browser-specific padding is been set. In other words, the padding: 0 is superfluous. But indeed, the margin is the most disbalanced among browsers, to answer your actual question.
I am probably going to tread on someone's toes here, but in my humblest opinion using a CSS reset stylesheet is ridiculous. You would have to redefine most of those margins (and paddings) yourself anyway. You could as good just learn and keep yourself the rule to define yourself the margin (and if necessary padding) for every block element which you're going to use in the document.
As to the remnant of the reset:
The border: 0 is superflous as well. The <hr> and the most form input elements are the only elements which have a default border. Without it, the <hr> is invisible (actually, this fails in IE6/7) and the text input elements on a form with same background color are invisible as well.
The outline should certainly not be resetted, it breaks accessibility. You need to control it yourself, e.g. resetting it yourself on only links with a (background) image since that's the major reason to reset it. But still, it breaks accessibility. Rather consider giving it a different outline color or style so that it is still visible, but less disturbing.
The font-size: 100% would force you to redefine them yourself in the <h1>, <h2>, etc elements. But even without the reset, you would often already like to do that anyway. What's the point of this reset then?
The vertical-align: baseline; breaks alignment of <sub> and <sup> so that they look like <small>. Further the table headers may also be affected. Those defaults to middle in all browsers. You would need to redefine them yourself again. Plus, it is known that this reset may cause IE6/7 to go havoc with images.
The value of background: transparent; is unclear to me. I don't see any point of this reset expect that it may make IE6/7 mad. You would also need to redefine the background color for all form input elements yourself again which just adds more work (for the case they're placed in a colored container). I am sure that whenever you encounter an element which needs transparent background, you could easily spot that yourself and set it yourself.
Enfin, see what you do with this information. I don't stop you from using the CSS reset. I myself have found the CSS reset only useful >10 years back when I was just starting with HTML/CSS. But with years and years, I've learnt as well that this is plain nonsense. But I admit, it's useful for starters since the reset will force them to set the margins and other stuff themselves explicitly. Which you could do as good without the reset.
Well, 'better than this' is hard to say, but the one with more stuff does more.
outline 0 makes links not have the dotted border around them.
Border 0 makes images and such not have a border around them.
font-size: 100% probably does something like ensure the fonts are 100%.
vertical-align: baseline sets all vertical alignments to the bottom of the container,
background: transparent prevents some png problems.
but margin:0 and padding:0 are two that defiantly should not be omitted from your reset list.
The short answer is: Feel free to set all of those if you are ready to override it for any element that may need it later.
However, note that you may have a lot of work ahead of you when it comes to form elements. They require at least a border to look good, and some of them (e.g. buttons) need a padding too. Also, some browsers display a 3D-ish border around buttons by default. If you set border to 0, you will not be able to get that 3D look back using CSS.
Also, you might want to check out http://www.blueprintcss.org/. It equalises browsers quite well, it seems, though I haven't tried it myself.