What is a reset in CSS?

Quote:

---

Originally Posted by Stomme poes

Dan, Gary's point is if you're going to do this:

(the equivilant of)
h1, h2, h3, p, div, etc {
margin: 0;
}

but then
h1 {
margin: whatever;
}
h2 {
margin: whatever;
}
h3 {
margin: whatever;
}
p {
margin: whatever;
}
etc

Then stating 0 at the beginning doesn't do anything, ...

---

I can't speak for everyone, but that isn't how I use a reset stylesheet; I use it as a starting point: try thinking of it as a _minimal_ stylesheet, instead of a reset. If I want bigger margins I change it. This doesn't get served up as a special stylesheet on its own, it is more like a common starting point.

I was reading the link Cooper posted, and it seems (unless I look at the stylesheet of each browser, though only 2 are listed) that padding is only on the uls and ols, and some other things like td, blockquote. Is that so?

Also, what's padding-start? It looks like padding-left, but then why isn't it that name? So it must be something different.

If so, my long padding resets can just be
ol, ul {
padding: 0;
}
since I rarely used blockquote, and usually (almost every time) end up manually setting padding on table cells and headers.

??

Quote:

---

I can't speak for everyone, but that isn't how I use a reset stylesheet; I use it as a starting point: try thinking of it as a _minimal_ stylesheet, instead of a reset. If I want bigger margins I change it. This doesn't get served up as a special stylesheet on its own, it is more like a common starting point.

---

That wasn't an example stylesheet, but I was trying to say if you're doing
* {
margin: 0;
}

but then manually state margins on everyone anyway, then that line doesn't do anything.

Hi,

I have to agree with Gary and it was the conclusion I came to a few years ago when I wrote this article.

Quote:

---

Originally Posted by me

The final drawback of using the global reset method is that it is like taking a hammer to your layout when a screwdriver would have been better. As I have noted above there is no need to reset things like em, b , i, a, strong etc anyway and perhaps it's just as easy to set the margins and padding as you go.
As an example of what I mean take this code.

1. * {margin:0;padding:0}
2. p,ol,ul,h1,h2,h3,h4,h5,h5,h6 {margin:0 0 1em 0}

I have negated the padding on all elements and then given a few defaults for the most popular elements that I am going to use. However, when coding the page, I get to the content section and decide I need some different margins so I define the following:

CSS:

1. #content p {margin-top:.5em}

So now I have a situation where I have addressed that element three times already. If I hadn't used the global reset or the default common styling as shown above then I could simply have said:
#content p {margin:.5em 0 1em 0;padding:0}

---

Although I must admit I did use the meyer reset for a while as I mostly code css/html templates for clients and it was safer to reset everything because clients always mangle the code.:)

Quote:

---

Originally Posted by AutisticCuckoo

Unlikely, since that selector has a specificity of 0,0,0,0 and will be overridden by any other selector. You can put it wherever you like, although I agree that it would be a good idea to place it first. :)

---

Paul have mentioned what drawback of universal selector? Pls read this.
Drawback, of which there has been a lot of discussion, is whether the global reset method could have speed implications on the browsers rendering of the page. As the universal selector applies to every single element on the page, including elements that don't really need it, it has been put forward that this could slow the browser down in cases where the html is very long and there are many nodes for the parser to travel.


Its agree or not?

Quote:

---

Originally Posted by Stomme poes

Also, what's padding-start? It looks like padding-left, but then why isn't it that name? So it must be something different.

---

Consider languages that render right to left. Were the padding set to left, it would be on the wrong side. -moz-padding-start, and -webkit-padding-start are like internal variables that depend on {direction: ltr | rtl | inherit;} and/or the html attribute dir="ltr | rtl". The default is language dependent.

cheers,

gary

Quote:

---

Originally Posted by ajaxdinesh

Its agree or not?

---

Did you not read the essay he referenced? Paul addressed that very issue.

cheers,

gary

Though he's referenced twice in Paul's article, it should be noted that Meyer himself no longer uses it (the universal selector) in his reset.

I've gone back and forth on it the idea of resets myself and now I generally use Meyer's, with a few custom tweaks for the particular site it appears on.

The basic purpose of the reset is to get rid of all the browser defaults and set the values to a known starting point. That way you never get bit by the fact one browser uses margin for an effect while another uses padding, or something similar.

If you get worried about the cost of a reset file, then change it a little, and instead use it as a "defaults" file. Instead of setting the values to zero, or whatever is in the file, set it to whatever you want the default for that element to be in your documents. A reset file without a universal selector, such as Meyer's current one, can then be used as a skeleton to ensure you don't accidentally leave a tag unaccounted for. Set all the tags in the reset to whatever you want for the default, and now you're working from a known base and only need to custom style the exceptions.

Quote:

---

Originally Posted by AutisticCuckoo

That should be border-collapse:separate. :)

(I wonder why so many people spell that word wrong?)

---

Always remember, There's a rat at the heart of every separation.

(sep - A RAT - ion)

Quote:

---

Originally Posted by Stomme poes

I was reading the link Cooper posted, and it seems (unless I look at the stylesheet of each browser, though only 2 are listed) that padding is only on the uls and ols, and some other things like td, blockquote. Is that so?

<snip>

If so, my long padding resets can just be
ol, ul {
padding: 0;
}
since I rarely used blockquote, and usually (almost every time) end up manually setting padding on table cells and headers.

---

ol, ul, and blockquote are exactly the elements on the site I'm working on that are giving me trouble in IE 7. I'd never seen the info in Cooper's link before. I'll try this.

I've been told that margin and padding are not normally inherited. I understand that the asterisk affects every selector below it. But if I made this CSS rule:

body ol, ul, blockquote { padding: 0;}

does that go down to all subordinate ol, ul, and blockquote only because it is a body rule? Or should I apply it to the level directly above, eg,

#content ol, ul, blockquote { padding: 0;}

I currently have the rule:

body { margin: 0; padding: 0; }

so that the body background goes all the way to the edges of the browser window. But the rule doesn't apply to subordinate elements (as far as I can tell).

What I really want is for margin and padding to be the same for all as they are in FF. Does it make more sense to set everything to 0, or to FF's defaults?

Thanks!

For all commonly used elements, only OL and UL* have browser dependent margins and padding that can cause problems. As of IE8, and Opera sometime in v8 or v9, IE and Opera now use padding-left (side is dependent on language; rtl or ltr), and the same 40px value. For the nonce, if you want no indent, you should zero both margin(-left) and padding(-left). If you want something other than 40px indention, then zero one and set the other.

cheers,

gary

* There are other elements that have differences, e.g. FORM and H1-6, but these top and bottom margins are either of no matter, or if they do matter, you've already set them to your own values for typographic reasons.

Also, th's and td's have 1px padding in FF, and who know who else. I normally would never see this, but I had built these table-calendars where 1 px all the way around was just enough to break everything (I had built them originally on a page where everything's padding was removed, and later adjusted my padding declaration on the new page... and realised I either needed to manually strip the padding from the tables, or add the table elements to my padding reset at the top of the CSS sheet).

So my current padding reset is ol, ul, th, td... and for whatever reason, html and body are still in there, but no, not for inheritance reasons. I think because I could never determine if there was a browser who added padding to those elements somewhere.

Quote:

---

I've been told that margin and padding are not normally inherited. I understand that the asterisk affects every selector below it. But if I made this CSS rule:

body ol, ul, blockquote { padding: 0;}

does that go down to all subordinate ol, ul, and blockquote only because it is a body rule? Or should I apply it to the level directly above...

---

Zeroing margins and padding on the body only zeroes margins and padding on the body, not any children inside.

Zeroing margins and padding from "ul" does end up removing it also from inner/nested ul's, not because of inheritance, but because sub-lists are also ul's. It's just going by tag name, no matter where that tag name is.

Although in the CSS you posted:
body ol,
that's all ol's whose ancestor is the body (not that there would be anyone whose ancestor wasn't the body lawlz), while the ul and blockquote in that statement are simply listed alone. Do you see the difference? Just because they're all in one line, it's not the same as writing
body ol, body ul, body blockquote {stuff}

But since all those elements are always inside the body anyway, there's no point in mentioning the body.