Big project, semi-competent programmer, much confusion.
Example: I wrote the CSS command that sets the formatting for the book's title
h0 { text-align: center; ... }
and it worked. Time passed, I made changes -- one of which disrupted the entire CSS enterprise. During repair, I began to wonder if 'h0' was in some way a forbidden name, so changed it to
h1 { text-align: center; ... }
and moved it out of a CSS file to the 'style' section of 'ChapTab.shtml', the first HTML loaded and the only place it is used. This works.
But I have used 'h1' for another format many places later on, so I change this command back to
h0 { text-align: center; ... }
and it puts the title at the left.
FF's CSS-usage add-on shows this 'h0' (as written) as the active command, but disobeyed. I find this confusing unless 'h0' is indeed pre-empted, or something. What's going on?
You can see this happening at the title of the page
http://www.electromontis.net/evoligion/_A/A00.shtml
(We will worry about the oversize font in the left column of the table, and the perpetual left-alignment below, at some later date.)
h0 is being treated as an inline element, so the text-align property won't work on it. Add the property display: block; to h0 to make it a block element. The text-align property works on block elements.
And I agree with #Rubenxfd - I'm not aware of an h0 tag. Best to stick with HTML standard tags where there are default properties (like display).
There is no h0 tag, so browser renders it as <span>. Add h0 {display: block} to act as h1 tag.
Your th has font-size: 140%;. Change/remove it.
perpetual left-alignment below Did not get this one, but if you are talking about all elements that are left-aligned below table: There is no align rules set, so it's left-aligned by default.
So I was tweaking the Firefox built-in reader mode using Stylish extension. The first thing I did was to change the font:
body.loaded.serif div#moz-reader-content, h1#reader-title, div#reader-credits{
font-family: "Marion";
}
It worked fine. Later on I wanted to tweak the links:
a{
text-decoration: none;
}
And the links stay unchanged. I can see in Firebug that this declaration is overriden by the default style declaration (as in "aboutReaderContent.css") which also used a single selector. Then I tried making it more specific:
html body.serif.loaded div.content div#moz-reader-content p a{
text-decoration: none;
}
Still no effect. Firebug says it was still overriden. I had to resort to !important.
My question is, why did this element does not follow the specificity rule? As I understand it, even in multiple files, browser will follow the most "specific" selector regardless the order these files are loaded. To add to my confusion, the first tweak actually overrode the default stylesheet, but that's in another file "aboutReader.css". What am I missing?
I have created a web widget. That my client put in their websites. Basically on load it calls webservice and loads data specific to client.
As a result it looks like:
<div class="widget">
<div class="container">
</div>
</div>
Dynamically I apply CSS styles to my widget class. To look consistent with our corporate styling.
The problem is when client application styles overwrite the style I applied run time.
For example if client has, it overwrites my styles:
body {
margin: 0 auto;
padding: 0;
width: 90%;
font: 70%/1.4 Verdana, Georgia, Times, "Times New Roman";
}
Is there any way to break inheritance? Just to say whatever div with class widget styles has do not inherit parent styles.
I don't think you can break CSS inheritance per se, but you can try to circumvent it by following the rules of CSS specificity. Here's a good article about Specificity.
As a last resort, try adding !important to styles in the widget to give it a higher specificity than the default styles.
#myWidget{
font: 100%/1 "Times New Roman", Serif !important;
}
If the client is also using !important it could cause problems. If you could setup a jsFiddle with an example, we could help find the issue.
Note, going the route of adding !important should be a last resort as it's the 'nuclear option' of style specificity.
You can not force elements to NOT inherit parent styles.
You can however override all possible styles that you do not want changed. If your CSS specificity is higher than the customers specificity then your styles will be dominate/expressed on the page.
See:
CSS Specificity via css-tricks.com
Per your example using the code below would be more specific than the body declaration and thus override :
.widget .container {
font-family: Arial;
}
You can't break style inheritance as such, but you can ensure that your styles are either more important or loaded in the right order so yours comes out on top.
Have a look at the !important tag.
Alternatively if you load your stylesheets after theirs yours will take precedent (unless theirs is inline). You can use Javascript to load your styles after the body has loaded (But then you'd get a "flicker" effect).
You could also try inline styling. Inline styling has the highest priority. This will work if client overrides use an imported stylesheet.
Like others have mentioned, another option is !important.
You can also read up the relevant specs at http://www.w3.org/TR/CSS2/cascade.html where they describe exactly how they cascade. If above mentioned tricks don't work, perhaps specs will give you a clue or you will know for certain that this is not possible.
Use of the !important css attribute is considered a bad practice. Because it introduces the potential for precedence conflicts, and makes it extremely difficult to troubleshoot css in the long run.
A less intrusive approach to this problem is to delimit your widget with an id, and in your stylesheet, to reset some of the most important style declarations using the "universal" selector, such as:
#myWidget *{
margin: 0;
padding: 0;
background: none;
border: none;
}
For example. Then, define your overrides specifically.
First of all I want to tell you why I'm asking this question. I usually update projects that have been written poorly and without a reset. I want to improve the project's quality so it seems that applying a CSS reset is absolutely necessary.
I don't want to do a hard work of pixel perfect testing in every browser every time I change something and I don't want to completely rewrite all CSS.
So:
When I'm writing:
*{
margin:0;
padding:0;
border:0;
}
I know what trouble to expect: <p> will loose padding and <input>, <select>, etc. will loose padding and border. So I have to specify them manually.
This code is more difficult to understand:
*{
font-size: 100%;
font: inherit;
vertical-align: baseline;
}
And I'm completely confused with this:
body {
line-height: 1;
}
*{
font-size: 100%;
font: inherit;
vertical-align: baseline;
}
This sets all elements in the document to inherit font and font-size from parent elements by default unless specified otherwise, which can prevent user-agent stylesheets from applying font styles with less specific rules.
vertical-align: baseline; is another widespread rule to avoid user-agent rules which don't always apply this (I believe) expected default behaviour to all elements.
Here's a brief look at what this does: demo. In the demo, try setting a rule to middle rather than text-top.
body {
line-height: 1;
}
This is the same. If you're not familiar with line-height, it's quite simple. You may have dealt with it without realizing it: Sometimes it appears to be a margin issue when in fact, the line height of an element is exceeding what you expected. This often happens when you place a typeface into a design which has a very dissimilar x-height to other typefaces.
If you don't understand its function, throw some dummy text into a document and start playing with it. It's very useful (essential) for producing good typography in different situations.
It seems you're not clear on css attributes and how they effect elements. The better your understand this, the better you can utilize a reset. No reset really fits all for a few reasons. For example, you might not be using any elements where vertical-align may end up being mismatched. You may have rules in a large reset that apply to elements you don't even have.
As with anything in web design, if you don't understand it, hands on experience will teach you a lot.
Check out this fiddle with simple input control on a form:
http://jsfiddle.net/KXYHw/
Toggle reset and see how input font and font size changes.
What are cons of global css reset * { margin: 0; padding: 0; }?
What people prefer eric meyer css.
This is eric mayer css
html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, font, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-weight: inherit;
font-style: inherit;
font-size: 100%;
font-family: inherit;
vertical-align: baseline;
}
/* remember to define focus styles! */
:focus {
outline: 0;
}
body {
line-height: 1;
color: black;
background: white;
}
ol, ul {
list-style: none;
}
/* tables still need 'cellspacing="0"' in the markup */
table {
border-collapse: separate;
border-spacing: 0;
}
caption, th, td {
text-align: left;
font-weight: normal;
}
blockquote:before, blockquote:after,
q:before, q:after {
content: "";
}
blockquote, q {
quotes: "" "";
}
Isn't it bit specific and heavy. I never use many elements which is in this rest like blockquote and caption.
Update:
and eric reset resetting 9 properties for 58 elements. isn't it also slow same like people talk about global reset.
What are cons to use this
* { margin: 0; padding: 0; }
select { min-width:1.5em; }
The problem is that there are some elements that need margins and/or padding to display properly, and people forget to set them back. Also, for many elements, you are going to be setting your own styles, overriding the reset, so the reset is redundant; you should instead just set the styles the way you want them.
One problem I see a lot is with lists. If you blindly apply a reset, the bullets for the list will appear outside of the containing element, which always bothers me:
+--------------------+
| Some paragraph, |
| with text. |
| |
*| One |
*| Two |
*| Three |
+--------------------+
Perhaps some designers are deliberately doing this, but I think a lot of the time I see this, it's because someone has blindly applied a reset and not thought about what it would do to the indentation of list items. If you look for this, you will see it all over the place; and pretty much invariably, the site you see it on uses a CSS reset. For more information on how to format lists correctly, see Consistent List Indentation on the Mozilla Developer Center.
Another problem is that after doing a reset, there are sometimes obscure elements that people don't remember to apply margins back to. For instance, the <dl> element; it's default style isn't great, but it at least lets you distinguish between the <dt> and <dd> elements within them. If you apply a reset, you lose that and wind up with everything crammed together with no distinction. Stack Overflow's reset does this, for instance, making <dl> elements pretty much useless:
Term
Definition
Term
Definition
Stack Overflow's reset also lacks any top or bottom margins on the <dl> element, and only a bottom margin to <p>; so I had to add an extra <br> in order to prevent the above <dl> from running up against this paragraph.
If you do use a reset, be very careful to make sure that all HTML elements do display in a sensible way. And remove the parts of your reset that are overridden by later rules that you add; there's no real reason to reset <b> and <i>, and then later apply font-weight and font-style to them, and if you reset a margin to 0 and then set it to 2 em, then why not remove the reset to 0?
Eric Meyer's CSS reset is not only to remove padding and margin, but to make default styling consistent across browsers. Many of the style rules reflect that fact. I don't know which elements are not included in his reset by default, but I can say that the particular reset you posted does contain many revisions to ensure maximal compatibility across browsers.
As for speed, if the speed of cascading < 100 styles through your site is what makes or breaks your performance, you probably have deeper issues at hand. Make sure that as many files are cached as possible and don't sweat a few extra CSS rules.
speed is a con, however slight the impact, using a global style sheet (*) applies the attributes to EVERY element possible, even if you are not using one or more
I don't see too many cons. I think using a really robust CSS reset is essential these days if you are running your site in multiple browsers.
The problem some of the time is that different elements such as p, h1,h2 etc are all affected by line-height, font-size etc, so just doing padding:0 and margin:0 won't guarantee a full reset.
Hope this helps.
The cons for a global reset are more based on your own personal setup. You can also edit someone else's reset as long as you credit them.
Cons:
I created my own reset way back when and made mistakes that I had to go back over and remove.
Hence if you use someone else's reset and it contains something you didn't expect you might 'lose functionality' on some objects that you were used to. This can be remedied by erasing the offending reset if you need to.
Pros:
I've been working with resets for almost a year now and I like it a lot. I really don't notice any performance issues and nothing surprises me about the way elements display, and I don't have to do stupid stuff like setting the margin/padding of the body and html to 0 whenever I build a new site.
The difference is miniscule, but the "star rule" actually takes longer to process as it goes through each element, applying (or in this case removing) the default styles.
Resets like Eric Meyer's target elements specifically, meaning slightly less processing time.
Setting line-height to 1 as suggested is just plain wrong from the standpoint of legibility. Even in the context of printing, layout software sets a default line-height (leading) of about 1.15. For the web, where you often have long measures (line lengths), you MUST have a line-height greater than 1 (typically, I start with 1.5 and often up it to 1.75). There is a reason for typographic principles, and that is to help readability. Setting solid, a print term for line-height of 1, is only to be used in special situations, such as very large size headings. IT SHOULD NOT BE A DEFAULT.
Yes, people "can" revise/alter the reset in their own styles, but the fact is, this reset is seen as a holy grail by so many, who blindly adopt it and never change things to use sound typographic principles. And this site is an illustration of the problem. Your eye needs some vertical space to easily follow from the end of one line to the start of another. When line-height is equal to the font-size, it makes text harder to read.
for browser there are some default margins and padding and they may be another for each element (for example another for li and for input) depending of browser.
reseting this value will make you sure that in each browsers for all elements margin & padding are 0
Dont use resets.
Resets are really annoying to fellow and future developers.
When I add a h1 tag I expect a margin and padding on it. When I add a p tag I expect space between each paragraph.
Its really annoying when people remove all of this. I end up having to go back look at their reset figure out which of the billion terrible ones out there this developer decided to use and then more then likely change.