The trick is to pass a variable on the end of the CSS file like so:

<link rel="stylesheet"
href="http://www.stefanhayden.com/style.css?version=1"
type="text/css" />

When a browser looks to see if it has anything cashed it compares file names. If you have “style.css” in your cashe then it’s not going to download it again. But if the browser compares “style.css?version=1″ to what the new HTML is “style.css?version=2″ then the browser thinks they are different files and needs to download the new CSS file.

Basically, when we are relaxed, our brains are more flexible and more likely to find workarounds to difficult problems. In contrast, when we are frustrated and tense, our brains get a sort of tunnel vision where we only see the problem in front of us. How many times, in a fit of frustration, have you tried the same thing over and over again, hoping it would somehow work the seventeenth time around?

Another explanation: We want those things we find pleasing to succeed. We’re more tolerant of problems with things that we find attractive.

Ordinarily I think this issue goes totally unnoticed – there isn’t a lot of info out there on the web about it (at least that’s what I thought at the time – I’ve since found a number of sites covering the topic). Most of the time our buttons have text like Save, Submit, Go – that sort of thing. 

I was flummoxed by this for a while. I was, after all, declaring my padding explicitly, and IE seemed to be rendering it. Rendering it and then some more depending on how much text was in the box. How could I trick IE into behaving like a nice, normal, standardsy browser?

I searched and searched the inter-tubes until I found a simple solution in the comments of a site that, I think, was in Portuguese. Unfortunately I didn’t make a note of where it was so I can’t give credit, nor could I understand anything that was written other than

 overflow: visible;

Now there were other folks on other sites advocating all manner of other, additional style declarations – setting width to auto or to 1% - none of which worked for me. But as soon as I popped that declaration in on my inputs IE’s buttons fell in line.

If you’re experiencing the same issue you might consider adding this to your style sheet.

 * html input { overflow: visible; }

Non-IE browsers will ignore it and, really, you aren’t telling them to do much of anything anyway (inputs don’t generally overflow you know). 

If you find that this doesn’t solve all of your IE button width related issues then I suggest you pursue some further reading.

In our case we have block elements, tables being the main culprit, explicitly set to 100% width inside a container div which will scroll vertically as it needs to. The problem is that IE calculates what “100%” is before it applies the scroll bar. So when the scroll bar is applied IE’s “100%” value is now wider than the actual viewing area. This causes the element set to 100% to be partially covered by the right-hand scroll bar and for a horizontal scroll bar to appear.

After tying to find a solution using conventional CSS or JavaScript to get the offending elements to behave we turned to using IE style expressions. This is essentially what we did.

element_selector {
width: expression(this.parentNode.offsetHeight >
this.parentNode.scrollHeight ? '100%' :
parseInt(this.parentNode.offsetWidth - XX) + 'px');
}

So we’re telling the element that if it is not taller than it’s parent then it should be 100% otherwise it should be the width of its parent minus a specific value (XX): in our case the padding plus the width of the scrollbar.

I’ve successfully applied this technique in a few different places and it hasn’t bothered me since (especially since they are hidden in an IE specific stylesheet behind conditional comments. This isn’t to say I’m a fan of CSS expressions – they shouldn’t be necessary – but in this case they’ve proven to be the simplest and most reliable solution to an annoying IE problem.

Floated elements are removed from the document flow, and other elements flow around them. This is great, and very useful but the catch is that removing an element from the document flow means that as far as its parent is concerned it no longer has height. So if the tallest element in your layout is, or might at any time be, floated you’ve got a problem.

So we need a way to prop the parent open. Any designer worth his salt will likely figure out this first, ugly method and immediately be ashamed. I know, because not so long ago I found myself in this very position and this is what I did.

<div>
    <div style="float:left;">Floated Content</div>
</div>

I know. Shameful. But there’s a better way. In fact there may be yet an even better way in certain cases, but I’m going to focus on the way that I’ve been employing to great success.

It should be noted that I did not come up with this technique. It was created by Tony Aslett, of csscreator.com and found its way to me via Position is Everything. I fully recommend reading the PiE article as I’m not going to delve into the specifics.

So here’s the CSS I use

.clear:after {
    content: ".";
    display: block;
    height: 0;
    clear: both;
    visibility: hidden;
}

And the modified markup

<div class="clear">
    <div style="float:left;">Floated Content</div>
</div>

Ta da! Look at that pristine markup. Again, if you want to know how and why this works read the PiE article, or if you don’t care just use it and be glad.

PS – In addition to self-clearing floats I find this technique very useful for ensuring that absolutely positioned elements with scrolling content don’t lose their bottom padding (which drove me nuts for a while).