Here’s the CSS snippet in question.

* {
	padding:0;
	margin:0;
}

The aim here is to save time when dealing with the minor cross browser differences caused by varying default values for these properties.

Who Benefits the Most?

The people who would benefit the most from using this technique are those who are just starting to build entirely CSS styled sites and are in danger of developing the very common conditions of ‘class-itis’ and ‘div-itis’ instead of directly styling and positioning semantic elements. Cameron summed it up perfectly:

The most oft-cited reason for not using semantic HTML is the perceived control that can be achieved by using tables/a lot of divs. By removing this “mystery” dimension from the size of elements, it could help people to become accustomed to styling semantic HTML.

Correct Usage

This technique was added as an afterthought to the original post and as such was not accompanied by any details regarding exactly what is required of the developer if they use this approach. Firstly, it is important to remember that this rule cancels the padding and margin of every single element; something which has already been found to have the negative side affect of hiding the drop-down arrow of a select form widget in Firefox. That problem is very simple to fix, (re-apply padding to select select { min-width:1.5em; } – thanks Bryan) but it does bring up a good point — care should be taken when applying this rule to a page which contains forms as usability must remain paramount whenever styling forms.

Examples

That brings me to the second point regarding correct usage; following the declaration with your own global padding and margin rules. If we look at this unstyled test page, and then the same page with the rule applied, you can see just how drastic an effect this declaration has.

Now that you’re comfortably in control of the padding and margins in every CSS able browser, it’s time to do something useful with that power. You could stick in something like this:

* {
	padding:0;
	margin:0;
}
body {padding:5px;}
h1, h2, h3, h4, h5, h6, p, pre, blockquote, form, label, ul, ol, dl, fieldset, address { margin:20px 0; }
li, dd, blockquote { margin-left: 40px; }
fieldset { padding:10px; }

View test page 3

This will basically replicate the original layout of the page in Mozilla, only it will be cross-browser; no differences on lists or other troublesome elements in IE or anywhere else. That’s effective, but it’s far from exciting. What about if we replaced all the values with relative units (% or em)?

* {
	padding:0;
	margin:0;
}
h1, h2, h3, h4, h5, h6, p, pre, blockquote, label, ul, ol, dl, fieldset, address { margin:1em 5%; }
li, dd { margin-left:5%; }
fieldset { padding: .5em; }

View test page 4

Hey now, that’s a bit more like it! Now we have the basis for a site whereby all side margins are controlled by browser width and all vertical spacing is controlled by font size. Quick, simple and highly usable — this could easily be used as the basis for a solid but highly flexible fluid layout. All you need to do now is add the columns .

Have something to add? Comments are open as always…

Thanks to Russ for saving me from having to type out the elements used for the test page.

The first thing most people will notice on the new home page is the addition of the Recent Entries table. The table format allows me to show all the relevant details of more new posts in less vertical space than the old ‘heading and excerpt’ format. If any Wordpress users want to see how I went about manipulating The Loop, I’ve attached a heavily stripped down version of the code below. It’s very simple, but that was my plan this time around – to stop ignoring the bleeding obvious methods in favour of more elegant, but essentially unnecessary solutions.

<h2>Latest Entry</h2>
<?php 	$cow=0;  // create our counter
 		$cowsleep=6; //tell it when to stop
if ($posts) : foreach ($posts as $post) : start_wp(); ?>

<?php if($cow==0) { ?>
	<h3><a href="<?php the_permalink() ?>"><?php the_title(); ?></a></h3>
	<?php the_excerpt(); ?>
	<a href="<?php echo get_permalink(); ?>">Continue reading <?php the_title(); ?></a>
	<hr />
<?php } ?>
<?php if($cow==1) { ?>
	<table summary="Recent journal entries from all categories">
		<caption>Recent Entries</caption>
		<thead>
		<tr>
			<th scope="col" class="title">Title</th>
			<th scope="col">Date</th>
			<th scope="col">Comments</th>
		</tr>
		</thead>
		<tbody>
<?php } ?>
<?php if($cow!==0) { ?>
		<tr>
			<td><a href="<?php the_permalink() ?>"><?php the_title(); ?></a></td>
			<td><?php the_time("M j, Y") ?></td>
			<td><?php comments_popup_link(__('0'), __('1'), __('%')); ?></td>
		</tr>
<?php } ?>
<?php if($cow==$cowsleep) { ?>
		</tbody>
	</table>
<?php } ?>
<?php $cow++; //increase counter value by 1 ?>
<?php endforeach; else: ?>
			<p>Sorry, something's gone awfully wrong... </p>
			<?php //custom error reporting ?>
<?php endif; ?>

The problem I over-intellectualised the most was clickable dates — month and year names that point to the archive of that period. As soon as I remembered the most important part of permalinks, (they never change) I whipped up a quick and messy solution in a minute.

<a href="<?php echo get_settings('siteurl');?>/journal/<?php the_time("Y") ?>/<?php the_time("m") ?>/" title="Archive for <?php the_time("F") ?>"><?php the_time("F") ?></a>
<?php the_time("j") ?>,
<a href="<?php echo get_settings('siteurl');?>/journal/<?php the_time("Y") ?>/" title="Archive for <?php the_time("Y") ?>"><?php the_time("Y") ?></a>

All I have to do is include that script where ever I want a post date to appear and it will do the rest using nothing more than the the_time() function and the domain name. Not very portable, but considering I would never intentionally change the URL structure it shouldn’t be a problem.

Mini Posts

Part of the reason I wanted to get more posts onto the home page is that I would like to start including mini-posts amongst the more lengthy articles. The quickest way I could think of to account for excerpt-less posts was using Scott Reiley’s highly versatile get-custom plug-in. By adding the custom field of short and assigning it the value of true, I can check for this on the fly and change the mark-up accordingly.
Here is a quick example; changing the text of the permalinks.

<?php if (c2c_get_custom('short')=="true") { ?>
	<a href="<?php echo get_permalink(); ?>" title="Permanent Link">Permalink for <?php the_title(); ?></a>
<?php } else { ?>
	<a href="<?php echo get_permalink(); ?>" title="Read entire article">Continue reading <?php the_title(); ?></a>
<?php } ?>

Minor Tweaks
There have been a fair few minor changes, including ditching the graphic submit buttons and reverting to the trusty submit input element. Hopefully you like the new alterations -- let me know if there’s anything else you would like to see changed. In other news, I finally have a post for the Lab section of this site; hopefully I'll find the time to finish it off later in the week.
]]>
			http://leftjustified.net/journal/2004/10/13/ver15/feed/
		10
		
		
		
		http://leftjustified.net/journal/2004/10/07/css-negotiation/
		http://leftjustified.net/journal/2004/10/07/css-negotiation/#comments
		Thu, 07 Oct 2004 06:25:48 +0000
		Andrew
				
		

		http://leftjustified.net/journal/2004/10/07/css-negotiation/
		Jay got me thinking about something  - most CSS/XHTML related articles and tutorials are very specialised; they only give you a detailed look at one part of the picture and then it’s up to you to put the pieces together. This isn’t always a good thing though, as it is left to the individual to experiment in search of combinations that not only work, but also allow relative freedom in future development.

I would prefer for this to be a massive investigation with all sorts of graphs and demonstrations, but there's no way I can find the time for something like that. Instead, I offer a walk through of how I start every new CSS styled site and my preferences for CSS hacks negotiation.]]>
			Fight the Power Default
A big part of dealing with cross-browser differences is accounting for the default property values of elements in each browser; namely padding and margin. I use the following declaration in every new site I design; it has saved me many hours of nitpicking.

* {
    padding:0;
    margin:0;
}

It doesn’t seem like much at first, but wait till you look at your mildly styled form in 11 browsers to find the positioning identical in all of them; or your button-style lists are perfect the first time, every time.

EDIT: following the interest this technique has generated, I have posted a more detailed description of how this technique may be able to help you — Global White Space Reset.
Keep it all valid & legacy friendly?
Support for CSS across current common browsers is varying to say the least. It’s up to the needs of each site to draw the line in the sand in regards to support for legacy browsers. My general preference is to give Netscape 4 no CSS, allow some minor style differences for IE 5.0/PC and to damn IE 5/Mac to hell; sorry old school Mac users. 
Inviting CSS to the party

<link rel="stylesheet" href="/style/main.css" type="text/css" media="screen,projection" />

This method has a couple of advantages:

it does not suffer from the FOUC phenomenon, unlike @import.
Using a comma-separated list for the media attribute locks out NN 4.7. Step one of CSS negotiation complete.
Adding projection to the media attribute will cause Opera to use the stylesheet in full screen mode (hat tip)
Our specification of a definite list of supported media will allow more flexibility if developing a handheld stylesheet in the future. (A future where all mobile UA’s have at least Opera’s level of CSS support.)

Build for the Best, Test with the Rest
The title from a post on any web development forum – “My CSS only works in IE! ”; – and it only ever will while you’re building in Internet Explorer. We’ve all heard it shouted from the rooftops (blogtops?) about how important it is to test in the most standards-compliant browser available when designing with said standards. Well DERRR! That’s like baking a cake and trying to taste it with you nose – it would be a similar sensation, but it’ll still be horribly wrong.
Beating Sense into Internet Explorer
There are only two methods I consider when delivering IE specific declarations in CSS:

Star selector hack for a one off fix

* html foo {bar:none;}

Delivering an extra stylesheet to IE/PC via a conditional comment

<!--[if IE]>
<link rel="stylesheet" href=" IE.css" media="screen" />
<![endif]-->

While both methods are valid, using conditional comments is the method I prefer as it allows all hacks to be kept totally separate. Some people are of the opinion that the mixing of code and comments is inherently wrong. They are correct, but this is war, damn it! Use IE’s own weapons against them, I say.

Step two of CSS negotiation complete – IE provided for without harming the innocent.
The Final Touches
You’ve built your page, it looks great in Mozilla/Opera/Safari and you’ve added a bit of correction for IE6 in your IE only file. Things probably don’t look quite right in IE 5 or 5.5/PC and depending on the differences; you may wish to add extra alterations for either or both.

My favourite method is using Tantek’s IE5 and IE 5.5 band-pass filters in the IE only stylesheet to import a separate file for that browser only.

Here’s a quick example of both filters:

/* IE5 */
@media tty {
 i{content:"";/*" "*/}};
 @import 'ie5.css'; {;}/*";}
}/* */

/* IE 5.5 */
@media tty {
 i{content:"";/*" "*/}}@m;
 @import 'ie55.css'; /*";}
}/* */

Having so many style sheets may seem a little crazy to many, but doing it this way means only users of the browsers that need to be hacked have to suffer the extra bandwidth load – all the more reason for them to upgrade. Also, when the day comes that IE 5 gets put in the NN4.7 basket you can just edit/delete the extra files and go about your day.
]]>
			http://leftjustified.net/journal/2004/10/07/css-negotiation/feed/
		56
		
		
		
		http://leftjustified.net/journal/2004/08/31/responsible-forms/
		http://leftjustified.net/journal/2004/08/31/responsible-forms/#comments
		Tue, 31 Aug 2004 10:39:45 +0000
		Andrew
				
		
		
		

		http://leftjustified.net/journal/2004/08/31/responsible-forms/
		many great articles about styling forms with CSS, so there’s no point in me discussing that any further. There is one aspect of form styling that sometimes gets lost in the rush — the ‘why’.]]>
			Don’t do it for the Design
The following post may fall into the bleedin’ obvious category for many of you, but I think it needs to be reiterated. One mistake I often see is forms that are altered to meet the designer’s tastes rather than styled in an attempt to simplify the experience for the user. Tiny little search fields might look cool but they are a nightmare interact with.
Do it for the People
Forms are something that I use daily, so when it came to making my own I gave some serious thought as to exactly what I would want when filling it out. I believe balancing the point where the design hat comes off and the usability/accessibility hat goes on is what makes a web designer; as such I consider ease of use and reliable functionality paramount when dealing with forms.
Real World Examples
An example of finding the balance came up today on the webstandardsgroup list. Someone was seeking help with a bug in Mozilla / Firefox whereby the dropdown arrow for a floated <select> was disappearing depending on the width set in the CSS. As the designer, it’s your responsibility to make sure the changes you have made to default widgets don’t cause such bugs to be triggered; if they do then the design is what must be sacrificed — not the usability.
Using the :focus pseudo-class to indicate the currently active field is a good practice, but watch out that you’re not doing more harm than good. In my opinion, if background colour changes are going to be made to the active field then the active colour should be lighter than that of the normal state. The user is reading the text in that field, so why make it harder for them? One great looking site I came across yesterday suffers from this common mistake (Ed: not anymore…). If you take a look at the comment form or the contact form in a modern browser you’ll see you would have seen what I mean. Setting the background of the current field to a darker colour decreases the text contrast and also decreases a site’s People Friendly Factor.
So what’s your opinion? As always, comments are open and I’d like to hear some different takes on the matter.
]]>
			http://leftjustified.net/journal/2004/08/31/responsible-forms/feed/
		20
		
		
		
		http://leftjustified.net/journal/2004/08/17/begging-on-the-corner/
		http://leftjustified.net/journal/2004/08/17/begging-on-the-corner/#comments
		Tue, 17 Aug 2004 11:42:22 +0000
		Andrew
				
		

		http://leftjustified.net/journal/2004/08/17/begging-on-the-corner/
		
			Ideally I’d love to work within a team on a full time basis, but if you’ve got any freelance work I’m accepting all offers. If you’d like to see more of my work (my portfolio isn’t entirely up to date yet) or discuss any possibilities, please feel free to drop me a line via my contact form.

]]>
			http://leftjustified.net/journal/2004/08/17/begging-on-the-corner/feed/
		8