homepage Welcome to WebmasterWorld Guest from 54.196.168.78
register, free tools, login, search, subscribe, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Visit PubCon.com
Home / Forums Index / Code, Content, and Presentation / CSS
Forum Library, Charter, Moderator: open

CSS Forum

    
Global or Universal reset - reset.css
do you use it and if so which is your preference..
SuzyUK




msg:3329012
 7:53 pm on May 2, 2007 (gmt 0)

Having often posted the phrase,
"be wary of using the Global reset -
* {margin: 0; padding: 0;} - UNLESS you really know what it is affecting."

I'm pleased to see that Eric Meyer has taken it a few steps further. Without an IE stylesheet it's pretty much still experience, but he has suggested a Universal reset reloaded [meyerweb.com]:

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;
/*background-image: transparent;*/ /* edit! has been removed again */
}
/* 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: collapse;
border-spacing: 0;
}
caption, th, td {
text-align: left;
font-weight: normal;
}
blockquote:before, blockquote:after,
q:before, q:after {
content: "";
}
blockquote, q {
quotes: "" "";
}

While that's obviously much more lines than the global reset solution, is it simply the easy answer to yahoo grids, where it's a copy/paste solution?

Eric then goes on to say....
...Simply the act of taking those defaults into consideration and thinking about them closely puts you ahead of 99% of your peers. I do think that reset styles are quite useful; otherwise, I wouldnít have written about them here, and certainly not to the extent that I have...

what's your preference, if any?

Suzy

edit reason: - Eric updated his code to change background: transparent; to background-image: transparent;

edit again: - background removed, background-image: transparent; is not valid...

[edited by: SuzyUK at 3:47 pm (utc) on May 4, 2007]

 

Robin_reala




msg:3329088
 9:17 pm on May 2, 2007 (gmt 0)

I donít, as I think they're dangerous. Weíre not perfect, and itís all too easy to forget to re-define stuff (especially the :focus example in Ericís stylesheet, thatís just a ridiculously bad idea). My designers deliver me a Fireworks PNG and rightfully complain if I miss setting a margin, line-height etc., so I suppose I have that extra layer of protection though.

londrum




msg:3329103
 9:26 pm on May 2, 2007 (gmt 0)

i use
* {margin: 0; padding: 0;}
all the time. and the only thing i've come across that is a bit annoying with it is it messes up the form buttons. some browsers will have literally no padding on them, whereas IE always seems to have a bit that you can't remove. same with the padding above and below <hr> lines.

Setek




msg:3329363
 1:11 am on May 3, 2007 (gmt 0)

I have a default section at the start of my stylesheet that universally resets margin and padding, but then also reapplies margin and padding to most things:

* { margin: 0;
padding: 0; }

h1, h2, h3, h4, h5, h6 { margin: 15px 0; }
p, table, dl, ul, ol { margin: 10px 0; }
ul, ol, dl dd { margin-left: 40px; }

Ö etcetera. I used to find problems but I think Iíve managed to work out all the niggling things that bothered me.

and the only thing i've come across that is a bit annoying with it is it messes up the form buttons. some browsers will have literally no padding on them, whereas IE always seems to have a bit that you can't remove.

londrum, you can remove that by applying overflow: visible; to your input buttons :) It doesnít affect standards-compliant browsers negatively either, so you can just put it in your regular stylesheet rather than IE-only conditional.

same with the padding above and below <hr> lines.

*shrugs* I donít use <hr>s everÖ I consider them to be a Ďpresentationalí element. If I wanted to divide something from something else, Iíd encase them in <div>s.

Xapti




msg:3329477
 5:42 am on May 3, 2007 (gmt 0)

Maybe he explains it in his page, but why the outline:0? outline is inheirantly 0 on everything, is it not? not only that, but IE-wise, outline isn't even supported.

But one thing which somewhat irks me:
font-size:100%. AFAIK, that doesn't render properly with Firefox on Windows with a non-standard (96dpi) font setting. Because I run at high res, I make text bigger through Windows (120dpi). Problem is, if I go surfing around with my favourite browser, any page which uses relative font sizing (text form, %, em, etc.) without a base absolute size, such as pixels, it renders it without increasing it's size. I've ranted on this once before, but it seems like I'm the only person on the whole damn globe who realizes the bug is there!
Both his page, this page, and a horde of pages on the web, give this bug. I'm just glad my vision is still somewhat decent (granted, I think viewing the small text just makes it worse though).

Anyways,
I personally just go *{padding:0;margin:0} because it gets rid of the weird spaces some browsers have seemed put on things, but also does it easily, and in a small amount of code. I don't like large code, so I'll avoid it if I can.

Of course, whenever I use an object, such as a button, or styled div, I'll specifically mention the margin or padding I want for it then and there... I don't really see what the problem is.

One thing I am somewhat considering though, is position:relative and z-index:1.
seems somewhat unsafe, but I could probably handle it. The reason being is so that I can position elements behind their parents, and position things with respect to their parents without ever having to remember to add the tacky position:relative, or z-index:1/0 to it. I don't ever position anything with respect to anything other than it's parent, and if ever I do, I could change the specific case to position:static.

[edited by: Xapti at 5:53 am (utc) on May 3, 2007]

Setek




msg:3329479
 5:56 am on May 3, 2007 (gmt 0)

Maybe he explains it in his page, but why the outline:0? outline is inheirantly 0 on everything, is it not? not only that, but IE-wise, outline isn't even supported.

Actually, outline on :focus is not inherently 0, but I believe by default is 1px dotted #999. And I think it's just in case.

Asiding the fact I think that's a terribly bad idea--how will standards-compliant browser users be able to navigate through a website through a keyboard?

And no, IE-wise, it isn't supported, and I actually think it's rather good that in terms of accessing a website through a keyboard. It at least half stops unknowing developers from making an accessibility faux pas.

One thing I am somewhat considering though, is position:relative and z-index:1.
seems somewhat unsafe, but I could probably handle it. The reason being is so that I can position elements behind their parents, and position things with respect to their parents without ever having to remember to add the tacky position:relative, or z-index:1/0 to it. I don't ever position anything with respect to anything other than it's parent, and if ever I do, I could change the specific case to position:static.

Yes, does sound unsafe--I'm already imagining all the different problems you would have with that. It just doesn't seem modular enough--I think you'll probably spend more time labelling everything as position: static; making it more a hindrance than useful.

[edited by: Setek at 5:59 am (utc) on May 3, 2007]

Fotiman




msg:3329791
 2:21 pm on May 3, 2007 (gmt 0)

I use the Yahoo UI Library [developer.yahoo.com]'s Reset CSS [developer.yahoo.com] and Fonts CSS [developer.yahoo.com]. In my opinion, this provides a much more solid foundation, and levels the playing field across browsers.

SuzyUK




msg:3330117
 7:54 pm on May 3, 2007 (gmt 0)

I believe Yahoo's reset.css was used a base for this "reloaded" suggestion.

I also happen to think that Yahoos! base/grid css files are overkill and that they over-address some points and do not address others.

Eric Meyers reloaded CSS reset seems to be better thought out and has more x-browser experience behind it IMO - though I do admit to being to busy to dissect it thoroughly right now so decision is not final ;)

>> re: Yahoo's fonts.css
as discussed previously [webmasterworld.com] I wouldn't be touching that with a barge pole unless again you are in control and are only concerned with font sizing and not liquid layout. Using the Yahoo! grids may well put you in a box *UNLESS* again you know what you're doing

I personally do not like to use the global reset, even though I could. Like Setek I have devised my own stock default list, based on experience and knowledge more than anything - I can't wait to get some time to have a proper look at Eric Meyers suggestion in order to see the reasoning behind things like e.g. "background-image: transparent"..

.

Fotiman




msg:3330162
 9:07 pm on May 3, 2007 (gmt 0)


I believe Yahoo's reset.css was used a base for this "reloaded" suggestion.

Yes it was.


I also happen to think that Yahoos! base/grid css files are overkill and that they over-address some points and do not address others.

Hold your horses! I never said anything about the Grid CSS file, nor do I think it's even appropriate to bring into this particular thread. You can use Reset and Fonts without Grids.

In any case, the point of the Yahoo Reset CSS is to create a level playing field across browsers. In other words, to get each browser to a consistent starting point. What would you suggest is over or under addressed? I'm going to follow up this post with a side-by-side comparison of both files and exactly what styles they have in common.


Eric Meyers reloaded CSS reset seems to be better thought out and has more x-browser experience behind it IMO - though I do admit to being to busy to dissect it thoroughly right now so decision is not final ;)

More x-browser experience? I definately disagree with you on that point. The Yahoo stuff has been tested (and documented) against many browsers. Eric's version is still in its infancy. I would consider his version to be very much Beta quality at this point (it's not even 1 month old yet).


>> re: Yahoo's fonts.css
as discussed previously I wouldn't be touching that with a barge pole unless again you are in control

When would you not be?


and are only concerned with font sizing and not liquid layout.

I've not yet encountered a single real-world use case where using the Yahoo Fonts CSS with liquid layout had any unexpected behavior.

Using the Yahoo! grids may well put you in a box *UNLESS* again you know what you're doing

Again, this is not relavant.

Fotiman




msg:3330164
 9:12 pm on May 3, 2007 (gmt 0)

Below I am listing the contents of both the Yahoo Reset CSS and Eric Meyer's version of Reset. These have been re-structured to be 'selector' based. That is, this will try to compare individual selectors to get a better idea of how the styles are being applied. Obviously, this version becomes much larger than the actual version because in the actual versions, many of the style rules are shared. This is only done to compare what styles are being applied to what selectors.

First, the Yahoo version:

abbr,acronym {
border:0;
}
address,cite,code,dfn,em,strong,var {
font-style:normal;
font-weight:normal;
}
blockquote {
margin:0;
padding:0;
}
body {
margin:0;
padding:0;
}
caption {
font-style:normal;
font-weight:normal;
text-align:left;
}
fieldset {
margin:0;
padding:0;
border:0;
}
h1,h2,h3,h4,h5,h6 {
margin:0;
padding:0;
font-size:100%;
font-weight:normal;
}
img {
border:0;
}
ol,ul {
margin:0;
padding:0;
list-style:none;
}
table {
border-collapse:collapse;
border-spacing:0;
}
td {
margin:0;
padding:0;
}
th {
margin:0;
padding:0;
font-style:normal;
font-weight:normal;
text-align:left;
}
q:before,q:after {
content:'';
}
div,dl,dt,dd,li,pre,form,p {
margin:0;
padding:0;
}
/*
* THESE ARE ONLY DEFINED IN YAHOO VERSION
*/
input,textarea {
margin:0;
padding:0
}

Now, Eric's version:


abbr, acronym {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-weight: inherit;
font-style: inherit;
font-size: 100%;
font-family: inherit;
vertical-align: baseline;
background-image: transparent;
}
address,cite,code,dfn,em,strong,var {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-weight: inherit;
font-style: inherit;
font-size: 100%;
font-family: inherit;
vertical-align: baseline;
background-image: transparent;
}
blockquote {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-weight: inherit;
font-style: inherit;
font-size: 100%;
font-family: inherit;
vertical-align: baseline;
background-image: transparent;
quotes: "" "";
}
body {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-weight: inherit;
font-style: inherit;
font-size: 100%;
font-family: inherit;
vertical-align: baseline;
background-image: transparent;
line-height: 1;
color: black;
background: white;
}
caption {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-weight: inherit;
font-style: inherit;
font-size: 100%;
font-family: inherit;
vertical-align: baseline;
background-image: transparent;
text-align: left;
font-weight: normal;
}
fieldset {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-weight: inherit;
font-style: inherit;
font-size: 100%;
font-family: inherit;
vertical-align: baseline;
background-image: transparent;
}
h1, h2, h3, h4, h5, h6 {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-weight: inherit;
font-style: inherit;
font-size: 100%;
font-family: inherit;
vertical-align: baseline;
background-image: transparent;
}
img {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-weight: inherit;
font-style: inherit;
font-size: 100%;
font-family: inherit;
vertical-align: baseline;
background-image: transparent;
}
ol, ul {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-weight: inherit;
font-style: inherit;
font-size: 100%;
font-family: inherit;
vertical-align: baseline;
background-image: transparent;
list-style: none;
}
/* tables still need 'cellspacing="0"' in the markup */
table {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-weight: inherit;
font-style: inherit;
font-size: 100%;
font-family: inherit;
vertical-align: baseline;
background-image: transparent;
border-collapse: collapse;
border-spacing: 0;
}
td {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-weight: inherit;
font-style: inherit;
font-size: 100%;
font-family: inherit;
vertical-align: baseline;
background-image: transparent;
text-align: left;
font-weight: normal;
}
th {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-weight: inherit;
font-style: inherit;
font-size: 100%;
font-family: inherit;
vertical-align: baseline;
background-image: transparent;
text-align: left;
font-weight: normal;
}
q:before, q:after {
content: "";
}
div,dl,dt,dd,li,pre,form, p {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-weight: inherit;
font-style: inherit;
font-size: 100%;
font-family: inherit;
vertical-align: baseline;
background-image: transparent;
}
/* THESE STYLE ONLY EXIST IN MEYER'S VERSION */
/* remember to define focus styles! */
:focus {
outline: 0;
}
blockquote:before, blockquote:after {
content: "";
}
html, applet, object, span, iframe, a, big,
del, font, ins, kbd, s, samp,
small, strike, sub, sup, tt,
label, legend,
tbody, tfoot, thead, tr {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-weight: inherit;
font-style: inherit;
font-size: 100%;
font-family: inherit;
vertical-align: baseline;
background-image: transparent;
}
q {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-weight: inherit;
font-style: inherit;
font-size: 100%;
font-family: inherit;
vertical-align: baseline;
background-image: transparent;
quotes: "" "";
}

Fotiman




msg:3330174
 9:35 pm on May 3, 2007 (gmt 0)

If either of these is over-addressing certain things, I would say it's Eric's version. But anyway, here is a comparison of both files. I am marking each style rule with a 'Y' (for Yahoo) and/or an 'M' (for Meyer). This way, you can better see which rules each one defines, how they overlap, and where one might be lacking or stronger than the other:

abbr, acronym {
.M margin: 0;
.M padding: 0;
YM border: 0;
.M outline: 0;
.M font-weight: inherit;
.M font-style: inherit;
.M font-size: 100%;
.M font-family: inherit;
.M vertical-align: baseline;
.M background-image: transparent;
}
address,cite,code,dfn,em,strong,var {
.M margin: 0;
.M padding: 0;
.M border: 0;
.M outline: 0;
.M font-weight: inherit;
.M font-style: inherit;
Y. font-weight: normal;
Y. font-style: normal;
.M font-size: 100%;
.M font-family: inherit;
.M vertical-align: baseline;
.M background-image: transparent;
}
blockquote {
YM margin: 0;
YM padding: 0;
.M border: 0;
.M outline: 0;
.M font-weight: inherit;
.M font-style: inherit;
.M font-size: 100%;
.M font-family: inherit;
.M vertical-align: baseline;
.M background-image: transparent;
.M quotes: "" "";
}
body {
YM margin: 0;
YM padding: 0;
.M border: 0;
.M outline: 0;
.M font-weight: inherit;
.M font-style: inherit;
.M font-size: 100%;
.M font-family: inherit;
.M vertical-align: baseline;
.M background-image: transparent;
.M line-height: 1;
.M color: black;
.M background: white;
}
caption {
.M margin: 0;
.M padding: 0;
.M border: 0;
.M outline: 0;
.M font-style: inherit;
YM font-weight: normal;
Y. font-style: normal;
.M font-size: 100%;
.M font-family: inherit;
.M vertical-align: baseline;
.M background-image: transparent;
YM text-align: left;
}
fieldset {
YM margin: 0;
YM padding: 0;
YM border: 0;
.M outline: 0;
.M font-weight: inherit;
.M font-style: inherit;
.M font-size: 100%;
.M font-family: inherit;
.M vertical-align: baseline;
.M background-image: transparent;
}
h1, h2, h3, h4, h5, h6 {
YM margin: 0;
YM padding: 0;
.M border: 0;
.M outline: 0;
.M font-weight: inherit;
.M font-style: inherit;
YM font-size: 100%;
Y. font-weight: normal;
.M font-family: inherit;
.M vertical-align: baseline;
.M background-image: transparent;
}
img {
.M margin: 0;
.M padding: 0;
YM border: 0;
.M outline: 0;
.M font-weight: inherit;
.M font-style: inherit;
.M font-size: 100%;
.M font-family: inherit;
.M vertical-align: baseline;
.M background-image: transparent;
}
ol, ul {
YM margin: 0;
YM padding: 0;
.M border: 0;
.M outline: 0;
.M font-weight: inherit;
.M font-style: inherit;
.M font-size: 100%;
.M font-family: inherit;
.M vertical-align: baseline;
.M background-image: transparent;
YM list-style: none;
}
/* tables still need 'cellspacing="0"' in the markup */
table {
.M margin: 0;
.M padding: 0;
.M border: 0;
.M outline: 0;
.M font-weight: inherit;
.M font-style: inherit;
.M font-size: 100%;
.M font-family: inherit;
.M vertical-align: baseline;
.M background-image: transparent;
YM border-collapse: collapse;
YM border-spacing: 0;
}
td {
YM margin: 0;
YM padding: 0;
.M border: 0;
.M outline: 0;
.M font-weight: inherit;
.M font-style: inherit;
.M font-size: 100%;
.M font-family: inherit;
.M vertical-align: baseline;
.M background-image: transparent;
.M text-align: left;
.M font-weight: normal;
}
th {
YM margin: 0;
YM padding: 0;
.M border: 0;
.M outline: 0;
.M font-style: inherit;
Y. font-style: normal;
.M font-size: 100%;
.M font-family: inherit;
.M vertical-align: baseline;
.M background-image: transparent;
YM text-align: left;
YM font-weight: normal;
}
q:before, q:after {
.M content: "";
.Y content: '';
}
div,dl,dt,dd,li,pre,form, p {
YM margin: 0;
YM padding: 0;
.M border: 0;
.M outline: 0;
.M font-weight: inherit;
.M font-style: inherit;
.M font-size: 100%;
.M font-family: inherit;
.M vertical-align: baseline;
.M background-image: transparent;
}
/* THESE ARE ONLY DEFINED IN YAHOO VERSION */
input,textarea {
Y. margin:0;
Y. padding:0
}
/* THESE STYLE ONLY EXIST IN MEYER'S VERSION */
/* remember to define focus styles! */
:focus {
.M outline: 0;
}
blockquote:before, blockquote:after {
.M content: "";
}
html, applet, object, span, iframe, a, big,
del, font, ins, kbd, s, samp,
small, strike, sub, sup, tt,
label, legend,
tbody, tfoot, thead, tr {
.M margin: 0;
.M padding: 0;
.M border: 0;
.M outline: 0;
.M font-weight: inherit;
.M font-style: inherit;
.M font-size: 100%;
.M font-family: inherit;
.M vertical-align: baseline;
.M background-image: transparent;
}
q {
.M margin: 0;
.M padding: 0;
.M border: 0;
.M outline: 0;
.M font-weight: inherit;
.M font-style: inherit;
.M font-size: 100%;
.M font-family: inherit;
.M vertical-align: baseline;
.M background-image: transparent;
.M quotes: "" "";
}

Note, I've not yet made up my mind which version (if either) is better. Obviously, I think there may be some excessive styling happening in Eric's version, and perhaps not enough in the Yahoo version. I think the key points of interest are:

  • The way the two versions handle fonts (Eric's tends to 'inherit', while the Yahoo version tends to be 'normal')
  • The missing input and textarea styles in Eric's version
  • The outline style in Eric's version

I think it will require a little more time in the wild before one method proves to be superior to the other. But it is certainly interesting. :-)

[edited by: Fotiman at 9:40 pm (utc) on May 3, 2007]

iamlost




msg:3331355
 11:47 pm on May 4, 2007 (gmt 0)

I like the quick and dirty global (padding, margin) reset and do recommend it, especially for debugging purposes, but it can have painful consequences with elements native to an operating system, i.e. form controls.

Indeed CSS 2.1 specifically disassociates itself from form controls:

3 Conformance: Requirements and Recommendations [w3.org]
...
3.2 UA Conformance
...
CSS 2.1 does not define which properties apply to form controls..., or how CSS can be used to style them. User agents may apply CSS properties to these elements. Authors are recommended to treat such support as experimental. A future level of CSS may specify this further.

Actually, I see the entire point of developing site template stylesheet(s) to be removing the need for a global reset.

I suppose a Yahoo or Meyer reset.css has value in providing a level starting point for building a site template set: adjust to suit then delete unused elements. Unfortunately, many of the comments I have read (and indeed Yahoos inference) propose importing reset.css to equalise things and then importing the specific page styles. What a silly convoluted excessive advertise-your-incompetence idea.

I suspect that I am not alone, especially among others that develop sites via templates, in already having some starting-point.css that sets preferred typography attributes as well as addressing various x-browser issues. Indeed I have my starting-point IE Conditional Comments as well. Seems logical: standard tools to make a professional job easier. But they are meant to be modified to meet the site/page requirements, not used as is with changes to follow separately.

SuzyUK




msg:3331698
 4:32 pm on May 5, 2007 (gmt 0)

It is all relevant.. well at least I think so anyway, to me it's along the same lines that iamlost refers to when he says most, and indeed yahoo leads you to believe you have to import them all then add your own stylesheet, which I agree is excessive!

Eric's version is not over-addressing anything imo, it's likely to be clearer to understand - and even if it is more, there is at least more chance of an explanation! - I'm just about willing to bet he's forgotten more than most can hope to remember - even in my wee world of helping - it is really difficult to write a code sample without getting picked up because of something I input out of habit but which I've forgotten. (e.g. display:inline; on floats for IE grrr ) - the rule 'picked on' of course usually has a good reason for being there - but sometimes one can't remember why :o

note: the rule I had picked on to look at later, the background-image: transparent; thing is gone from the code, I've seen it was there because of IE7? but still haven't had time to dissect - anyone know what/why?

Using either Yahoo's or Erics, if used as copy/paste solutions are akin to using the global reset to start with. I'm sure there's nothing wrong with using any of them *IF* you know/or don't care what it's resetting. and I'm pretty sure you do know Fotiman. :) - I just happen to think Eric Meyers code might be more intuitive to amend to suit? but that's the unchecked bit..

You're possibly right I shouldn't have brought grids into this, but to my thinking - 'grids' is just like reset.css or fonts.css - it is another way of shoving a preconceived idea of a protocol/CSS template at folks - people are looking for a copy/paste answer to a question that can't quite be answered yet, at least not with a definitive answer.. there are so many ways to do things, and the "best" way often comes down to preference - though admit it would help if IE had a default stylesheet!

You've done a lot of work, Fotiman! - thank you.. (I've flagged this thread for later reading of your code) - but splitting the properties up is possibly a wasted exercise - When we as CSS people strive to inform others that you can use comma separated rules to cut down the work, splitting them to make Meyers code look longer is cheeky ;)

Suzy

Fotiman




msg:3332966
 3:08 pm on May 7, 2007 (gmt 0)


When we as CSS people strive to inform others that you can use comma separated rules to cut down the work, splitting them to make Meyers code look longer is cheeky

Note, it was not my intention to make Meyer's code look longer. My intention was only to better clarify which styles were being applied to which elements for both stylesheets. I just wanted to be able to compare which style rules were being applied in which cases. I think some of the styles that the Meyer's version includes are probably overkill, while some of them are great ideas. But (for me at least), it helps to see it all laid out.

Fotiman




msg:3332973
 3:16 pm on May 7, 2007 (gmt 0)

@iamlost

Unfortunately, many of the comments I have read (and indeed Yahoos inference) propose importing reset.css to equalise things and then importing the specific page styles. What a silly convoluted excessive advertise-your-incompetence idea.

@SuzyUK

and indeed yahoo leads you to believe you have to import them all then add your own stylesheet, which I agree is excessive!

I have to disagree with you on this. I see nothing wrong with including a reset.css file first, and then overwriting any styles that you need for a specific page. I don't think that's an "advertise-your-incompetence" idea at all. Sure, you could put those into a single stylesheet... but does it make that much difference? No. The reset.css stylesheets are small enough to be negligable, and in fact might be more efficient over the course of several pages if that functionality is abstracted out into it's own file, especially since it has been minified.

In addition, I think the Yahoo documentation is excellent. I know that I don't *need* to include the grids style if I don't want it.

I'm not saying it's the answer to everything, but I also disagree with you regarding it being a bad idea to put it in its own CSS file.

iamlost




msg:3333167
 7:05 pm on May 7, 2007 (gmt 0)

The Yahoo inference:

Getting Started

To use Reset, include the following source file in your web page with the link element:
<!-- Source File -->
<link rel="stylesheet" type="text/css" href="http://yui.yahooapis.com/2.2.2/build/reset/reset-min.css">

...
Note: The files included using the text above will be served from Yahoo! servers;
...
Building Up Explicitly

With reset.css in place, begin developing as normal...


1. in each web page link to and load the reset.css directly from Yahoo.
This will make the page x-browser friendly.
2. now develop and add your own css file.
This will make the page uniquely yours.

In the comments to his reset columns Mr. Meyer says [my paraphrase] that it is easier for most people to first level things and then add on explicit requirements later. Thus, I see the reset.css philosophy as vaccinating pages with redundent 'foundation' code to treat pandemic x-browser CSS ignorance.
I prefer education over enabling bad behaviour.

I'm not saying it's the answer to everything, but I also disagree with you regarding it being a bad idea to put it in its own CSS file.

We will have to agree to disagree.
1. while each individual load of seperate reset and page styles is miniscule on a large busy site the additional overhead is noticeable.
2. replacing one optimised required styles file with two separate somewhat redundent files serves little useful purpose. It may expose ignorance or sloth rather than a considered decision.
3. I view hot-linking styles similarly to hot-linking images. A bad idea, even with permission.
4. Further to 2 and 3: what happens if only one of the two styles files loads?

The reset plus approach is not 'bad'. But I see no reason (yet) to retract or modify: What a silly convoluted excessive advertise-your-incompetence idea.
:-)

Fotiman




msg:3333189
 7:38 pm on May 7, 2007 (gmt 0)


The Yahoo inference:
...
With reset.css in place, begin developing as normal...

Exactly. I don't understand your objection to this method. The point here is that you start by normalizing browser behavior so that they will behave in a more similar fashion than they would by default.


In the comments to his reset columns Mr. Meyer says [my paraphrase] that it is easier for most people to first level things and then add on explicit requirements later. Thus, I see the reset.css philosophy as vaccinating pages with redundent 'foundation' code to treat pandemic x-browser CSS ignorance.
I prefer education over enabling bad behaviour.

What bad behaviour? I don't view creating a clean foundation as bad behaviour.


1. while each individual load of seperate reset and page styles is miniscule on a large busy site the additional overhead is noticeable.

I really don't think so, as the shared reset.css file would be cached by the browser so subsequent calls to it do not need to be retrieved from the server. The alternative (including the equivalent code in the CSS for individual pages) will mean downloading that code over and over in each of the different stylesheets. Less efficient if you ask me.


2. replacing one optimised required styles file with two separate somewhat redundent files serves little useful purpose. It may expose ignorance or sloth rather than a considered decision.

One optimised file per page you mean. I say again, not efficient. I also don't see how it will expose ignorance or sloth.


3. I view hot-linking styles similarly to hot-linking images. A bad idea, even with permission.

I would tend to agree with you here. Which is why it's nice that the files can also be served locally on your own server (and the documentation explains that). At the same time, I do think that it's interesting that if many sites were using the "shared" library files, then caching might be improved because you may already have that file in your cache from visiting another site. Even so, I would tend to prefer more control over the files, which is why I would serve them locally.


4. Further to 2 and 3: what happens if only one of the two styles files loads?

Why would that happen? If it did, the user would obviously have bigger problems than a page displaying funny.


The reset plus approach is not 'bad'. But I see no reason (yet) to retract or modify: What a silly convoluted excessive advertise-your-incompetence idea.
:-)

Again, I see nothing incompetent about it, and in fact I think that not abstracting out the shared functionality is more incompetent. But we're each entitled to our own opinion.

[edited by: Fotiman at 7:39 pm (utc) on May 7, 2007]

Fotiman




msg:3333203
 7:55 pm on May 7, 2007 (gmt 0)

Let me just give a very simple, extremely trimmed down example of why I think the method of abstracting out some common functionality is better.

Suppose you have 3 pages, each requiring their own unique stylesheets. Now suppose these individual stylesheets look like this:

Page 1
body{margin:0;padding:0;}

Page 2
body{margin:0;padding:0;}

Page 3
body{margin:0;padding:2em;}

The first 2 contain some shared identical styles, each requiring 25 bytes. The third page has some overlap with the previous 2 and requires 27 bytes, for a total of 77 bytes that will be downloaded when each of these pages are visited.

Now, suppose instead that you had your reset css file which contained the rule shared by pages 1 and 2. If you included this stylesheet from all 3 pages, you will download the 25 bytes up front on whatever page you hit first (lets assume page 1). On page 2, that's 25 bytes that doesn't need to be downloaded. On page 3, that's another 25 bytes that doesn't need to be downloaded, and your page 3 css file could then contain:

body{padding:2em;}

So, you've saved yourself 50 bytes of download, and you only need to add 18 bytes for page 3. 77 bytes vs. 43 bytes.

This example doesn't take into account the extra bytes required to include the shared css file, but presumably the amount of style rules contained would outweigh it (obviously, that wouldn't be the case with this trimmed down example, but the point here was to show where the savings occurs in a multi-page environment). And obviously, the more pages that share this common file, the greater the savings.

sifredi




msg:3333244
 8:59 pm on May 7, 2007 (gmt 0)

You really have to ask yourself what purpose it serves. As I see it, it can serve one or more of these:

* to reset all browser defaults in visual rendering
* to disable deprecated tags
* to reset some defaults to gain positional control

Actually, both Eric's and Yahoo's file sticks to the third point. They are both resetting some values they feel appropriate, without explaining why.

As I see it, disabling all styles and then add a "generic" css file before dealing with the actual custom design would be the most secure way to gain cross-browser consistency and control. But also the most memory-consuming.

Eric has the font tag in his reset file, why? If he wanted to "reset" it, why no reset tags like b, i, s, meny etc?

It's also crucial to not over-style the greedy * universal selector. You still want the natural inheritage later on. But I really like the idea to "unstyle" deprecated tags to make clients stop using them in their CMS and such.

Here is another version that I use as a starting point:


* { margin: 0; padding: 0; text-decoration: none; font-size: 1em; outline: none; }
code, kbd, samp, pre, tt, var, textarea, input, select, isindex { font: inherit; font-size: 1em; }
dfn, i, cite, var, address, em { font-style: normal; }
th, b, strong, h1, h2, h3, h4, h5, h6 { font-weight: normal; }
a, img, a img, iframe, form, fieldset, abbr, acronym, object, applet { border: none; }
table { border-collapse: collapse; border-spacing: 0; }
caption, th, td, center { text-align: left; vertical-align: top; }
body { line-height: 1em; background: white; color: black; }
q { quotes: "" ""; }
ul, ol, dir, menu { list-style: none; }
sub, sup { vertical-align: baseline; }
a { color: inherit; }

You could also compensate the inheritage for IE6:

* html code, * html kbd, * html samp, * html pre, * html tt,
* html textarea, * html input, * html select, * html isindex { font-family: serif; }
* html a {color: black;}

[edited by: sifredi at 9:25 pm (utc) on May 7, 2007]

Webwork




msg:3333252
 9:12 pm on May 7, 2007 (gmt 0)

What an erudite place WebmasterWorld must be that it posts a thread about CSS global resets on its homepage. Way to go WebmasterWorld, SuzyUK, Robin, et al. ;0)

Now, will someone please explain the import of this to me - in simpleton's terms?

Robin_reala




msg:3333270
 9:34 pm on May 7, 2007 (gmt 0)

In simple terms, if you donít apply any stylesheets to a web page youíll still see that headings are bigger than normal paragraphs, that <strong> elements are bolded, etc etc. This is down to the browserís internal stylesheet. The w3 provides a default stylesheet for HTML4 [w3.org] but itís informative, not normative (suggested, not required). In the real world, different browsers have different default settings.

A concrete example of this is <ul>s. In Firefox <ul>s have default padding on the left to push the list items in from the side of the screen; in IE the <ul>s have default margin instead. Neither of these is the wrong approach but if youíre not careful you can reset one but leave the other as default, causing errors in your visual design.

If youíre interested you can find Firefoxís default HTML stylesheet (assuming youíre on Windows and have installed in the default location) at c:\Program Files\Mozilla Firefox\res\html.css.

[edited by: Robin_reala at 9:37 pm (utc) on May 7, 2007]

iamlost




msg:3333342
 11:21 pm on May 7, 2007 (gmt 0)


The point here is that you start by normalizing browser behavior so that they will behave in a more similar fashion than they would by default.

We agree!

Where we differ is that I build in the x-browser optimisation as I build each template style sheet rather than plugging in a one-size-fits-all reset and then building my cottage on a foundation fit for a palace.

You could arrive at the same end by starting with a complete reset list, adjusting attributes to meet design requirements, and deleting unneeded elements/attributes when finished.

As I mentioned 'reset plus' is not bad. I just don't like it.


What bad behaviour? I don't view creating a clean foundation as bad behaviour.

I said I prefer education over enabling bad behaviour. I did not mean that using reset was bad behaviour. I meant that using reset was encouraging (enabling) CSS x-browser ignoramuses to continue their ignorant (bad) behaviour without incurring display failures to encourage actually learning why and how.


I really don't think so, as the shared reset.css file would be cached by the browser so subsequent calls to it do not need to be retrieved from the server. The alternative (including the equivalent code in the CSS for individual pages) will mean downloading that code over and over in each of the different stylesheets. Less efficient if you ask me.

Your point has validity if many pages have different CSS: the reset is loaded once into cache and the page specific gets loaded as needed.

If, however, a template design is used most pages will share a singular css file so far fewer page-centric style calls are required.


One optimised file per page you mean. I say again, not efficient. I also don't see how it will expose ignorance or sloth.

Efficiency is relative to the specification.

It may expose that the webmaster was too ignorant or too lazy to do more than cut-n-paste CSS like far too many do with scripts.


...what happens if only one of the two styles files loads?
...
Why would that happen?

Browsers have been known to have cache problems. I like to minimise even rare problems especially when the solution is simple.

Those that hot-link to a reset (yes, it is silly but there is a lot of that about) are depending upon two sets of servers and two separate pathways to deliver one style. Stuff happens.

Fotiman: Your trimmed example makes your case clearly. Except when templates are used.

We obviously generally agree. More differences of style :-) and approach than disagreements of fundamentals.

sifredi: as I mentioned earlier the use of * { margin: 0; padding: 0; can have painful consequences with elements native to an operating system, i.e. form controls. Attributes can be removed but may not be able to be put back on by CSS. This is not a 'do not do that' situation, rather a 'be aware of a potential problem' reminder.

sifredi




msg:3333460
 4:48 am on May 8, 2007 (gmt 0)

iamlost:
* { margin: 0; padding: 0; can have painful consequences with elements native to an operating system, i.e. form controls. Attributes can be removed but may not be able to be put back on by CSS.

eh... could you point me to an example where CSS is not capable of redefining margins and paddings to objects after using the universal selector? In my world, the user agent either reads the CSS file and renders accordingly (sort of), or it doesn't (f.ex safari in forms). I honestly can't see how it could understand "*" but not it's equalient further down the inheritage like "input" or "submit". Maybe I'm wrong.

My experience is more that using a greedy * selector could be confusing the natural inheritage. Setting * { color: black; } for example, would cause problems when defining something like ul { color: red; }, since the ul's <li> elements will still be black.

Fotiman




msg:3333735
 1:38 pm on May 8, 2007 (gmt 0)

@iamlost
Ok, I think we generally agree. :-)

SuzyUK




msg:3333956
 5:54 pm on May 8, 2007 (gmt 0)

I think we all generally agree :)

I think they have their uses, but would not like to import an unnecessary stylesheet, I don't even like using a CMS default s/sheet, preferring to 'own' the template.. but I can understand the need for them

The Global reset is greedy, and that's a good point about the inheritance issue. Using it for purely margins/padding is perhaps not quite so bad, once you get to grips with the form elements - but it does seem to be a bad idea to use it for anything font related, inheritance being the issue

Yes I too am wondering why Eric chose to negate the font element but not some of the other deprecated elements, but I wonder if that isn't related to CMS editors, I know the one I use converts <b> to <strong> and <i> to <em> so perhaps the <font> is incase of copy pasting from WYSYIWYG's? - it's a good idea to negate them anyway and is just the answer I need for a site where one author obviously pastes from FP.

re: inherit & the font properties
of course if IE supported it properly then yes that would be the proper answer to the inheritance problem, and I presume is why Yahoo is using "normal"

@sifredi, I was just having a look at your sample too, but am not sure that your * html rules are a valid solution as IE7 is not still not resetting link color or some of the pre formatted rules, (inherit again?)

I bet we could make up a nice base between us all, allowing for the bits we know, use, don't care about ;)

I started to write out something but the very first thing I came across was line-height.. both previously discussed versions set it to 1 but as a preference I can't see any time at all I would like it set to 1 so I'd be tempted to set it at 1.2 or thereabouts so the 'most' case scenario was covered?

If I were to use one of these methods, I would not be using some of those deprecated elements - but if in an ideal world of a universal reset - would you want them taken care of?

Suzy

sifredi




msg:3334027
 7:08 pm on May 8, 2007 (gmt 0)

Maybe off topic here, but suzy: you an negate all variants of the font tag (in non-IE browsers) including stuff like <font size=5> and <font style="color: red"> if you put something like this in your code:


font
{
color: inherit !important;
margin: inherit !important;
padding: inherit !important;
font: inherit !important;
text-decoration: inherit !important;
border: inherit !important;
background: inherit !important;
bottom: inherit !important;
top: inherit !important;
left: inherit !important;
right: inherit !important;
position: inherit !important;
clear: inherit !important;
float: inherit !important;
height: inherit !important;
width: inherit !important;
letter-spacing: inherit !important;
text-transform: inherit !important;
outline: inherit !important;
overflow: inherit !important;
display: inherit !important;
visibility: inherit !important;
text-indent: inherit !important;
white-space: inherit !important;
word-spacing: inherit !important;
z-index: inherit !important;
text-align: inherit !important;
max-height: inherit !important;
max-width: inherit !important;
min-height: inherit !important;
min-width: inherit !important;
cursor: inherit !important;
}

looks like a joke, but it actually works.

[edited by: encyclo at 7:18 pm (utc) on May 8, 2007]
[edit reason] fixed code spacing [/edit]

SuzyUK




msg:3335124
 6:22 pm on May 9, 2007 (gmt 0)

thanks sifredi, it does indeed look like a joke, ;) but I get it..

OT, in regards to my application I've realised that the CMS converts WYSIWYG inputted <font> into <span> and it's attributes into inline CSS, which is nice for the valid code side... but actually makes it harder to control - it would be easier to target the <font> element in this particular case :o

anyway back to resetting...
slightly more complex, are the form elements, I can't see a way of "resetting" the fieldset and legend element properties - rather if you did want them on a level field as far as I can see there is going to need to be a compromise - because the form elements are generally left to the UA's to decide on how they render

While I generally agree that buttons, inputs etc.. should fall into this category [form controls], it's a bit disappointing to see that fieldset and legend have been lumped in that category

Anybody had any luck taming these beauties? I have a solution which I use which gets them close to similar x-browser, but it's not what I'd call a reset! - In fact the global reset of setting the margin/padding to zero on all elements could lead to a bit of fun with them without some x-browser tomfoolery

Suzy

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / CSS
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved