Archive for the ‘CSS’ Category

IEPNGFix 2

Thursday, July 17th, 2008

If you’ve launched a large site recently, you may find yourself surprised at the amount of traffic IE6 drags in. In some cases, as much as 18% of our user base for large sites has been using the lil browser that could. It’s even more shocking considering these are cutting edge, community based sites. This breeds one (okay, maybe more than one) unfortunate drawback - lack of transparent PNG support in IE6. I don’t know about you, but I simply can’t live without transparent PNGs.

Fortunately, there are several work arounds. Even more fortunately, there is an updated version of a well known PNG fix - IEPNGFix 2 - and according to Angus Turnbull, it now supports background position and repeat!

via Ajaxian

Self Clearing Floats

Friday, June 6th, 2008

The ‘clearfix’ or self-clearing method as published at Position is Everything, is my favorite method for clearing floated elements. My only quarrel with it is that it requires you to add the class ‘clearfix’ (or whatever you have renamed the class to) to the parent container of the floated elements. While this is not such a big deal if you only have one or two containers that require the class, it can quickly get unwieldy in a document that has multiple containers embodying floated elements that need to be cleared.

My preferred method is to add the necessary clearfix rules to each element as needed in the external CSS file. It helps reduce ‘classitis’ and keeps the HTML document from getting cluttered with extra class names that have no structural meaning.

For example, if there were, say, 5 divs that needed the clearfix technique, we would apply the following rules to our style sheet:

#div1:after, #div2:after, div#3:after, div#4:after, div#5:after {
	content: ".";
	display: block;
	height: 0;
	clear: both;
	visibility: hidden;
}

And we’re done! Well, that is if we don’t plan on supporting IE6 or IE7. Those two browsers require some additional rules to cooperate because we need to trigger hasLayout for the auto clearing to kick in. Fortunately, that’s pretty easy to do:

#div1, #div2, div#3, div#4, div#5 {
	min-height: 1%;
	display: inline-block;
}

min-height alone will do the trick in IE7, but it’s older sibling needs more help, which accounts for the display: inline-block; bit. The above should be included in our separate IE style sheet so that only IE 7 and below see it. This will keep FireFox 2 from chucking up errors in the console when it doesn’t understand the inline-block; rule we’ve applied to the global clearfix class, plus it has the advantage of keeping our IE hacks, filters, patches etc. from overriding anything in our master style sheet.

But, wait there’s more! If we don’t want to use the clearfix method and we STILL want a self-clearing element, we can also apply overflow:hidden; to the element shrink-wrapping the floats. One thing to beware of here though is that negative margins won’t work. I first discovered this handy trick courtesy of Jonathan Snook’s Top CSS Tips write-up.

In a similar fashion, setting overflow: auto; also seems to work. This technique can produce unwanted scrollbars if not used with care, so be on the look out for that. Alex Walker covers this technique in some detail in his article, Simple Clearing of Floats.

Ultimately, there are lots of options for clearing floats - usually the task at hand dictates the best technique. Call me old fashioned, but I still like to include a rule in my master style sheet that will apply to a non-semantic element in the HTML document, just in case I need it. You’ve all seen this guy before:

.clear {
	clear: both;
}

I keep him around in case the parent container of the floated elements experiences unwanted vertical margin collapsing. I generally use this pretty sparingly, but on a large site, it could turn up in the source code here or there, causing someone to poke me in the ribs and ask why it’s there. Now you know. And unless I’ve been misled up until now, knowing is half the battle.

Sometimes as front-end developers, we have to use a little necessary evil. When that happens, learn to forgive yourself and move on: your therapist will thank you.

Explorer 6/7 Text Float Line-Height Bug

Friday, April 4th, 2008

I’ve run into a rather odd Explorer bug of late. The issue has to do with floated or positioned text and line-height. Explorer has many well documented bugs regarding text, positioning and floats, which you can brush up on at PIE. Chances are you are already quite familiar with that list. After some Googling, I still couldn’t find a definitive answer to my problem though, so I’ve decided to document it here.

The bug

When text is floated or positioned in Explorer, the line-height seems to be reduced to the point of the text being cut off. This quirk is most notable when a larger, seriffed typeface is used, but can also be quite noticeable with Arial in particular. Below is a screen shot of what it looks like in IE7 and you can also view the HTML file from whence the screenshot came. Sometimes, this bug goes unnoticed if the cut off portion of the text is very minimal, but if you were to look really closely, you would notice it. In fact, in some cases, I didn’t notice it myself until it was pointed out to me by the all seeing eye of QA4U.

Explorer 6/7 Text Float Line-Height Bug

Workarounds

So far, I’ve found three workarounds:

  1. Increase the line-height to an arbitrary value until text is fully visible.
  2. Wrap text in a floated container.
  3. For positioned text, add padding.

While option 1 works, it requires some fudging. Generally, you have to increase the line-height to equal the size of the font. So for example, if the text size is 32 pixels, the line-height should be at least 32 pixels, but you will have to ‘eyeball’ it to get it to look right. The drawback that I’ve found to this method is that the increased line-height can create vertical spacing issues with other layout elements, not to mention you will need to adjust every single header or paragraph that has floated text.

Option 2 works brilliantly and doesn’t require any jiggery-pokery with line-height settings, but the drawback here is that it means an extra div in your markup which might not be desirable to you.

Option 3 has the same potential drawbacks as option 1. You might be able to get away with adding arbitrary padding to the text in some designs, but other designs may be more strict, so it’s clearly not an across the board solution.

In my case, I had dozens of headers floated left and links floated right, so method two won out, which is the solution I provided on the example page. It also had the advantage of me being able to reproduce the design I was coding more closely, which pleased the designer, so the extra divs didn’t cause any premature hair loss.

Conclusion

This is certainly not an exhaustive list of workarounds or fixes, just three quick methods I found of sidestepping the issue. If anyone knows of a fix that does NOT involve altering the structural layer, why the bug is occurring in the first place, or both, I’d love to hear about it. Happy coding!