zahnster

When I started at Zenbe, I was pretty excited, because I knew it meant that I would be getting my hands dirty with some complex development issues. My history in web development has been mostly creating smaller, marketing-oriented websites, where you don’t really have to worry about frequent code evolution or long-term maintenance. Once you create the site, it’s up, and maybe there will be text changes here or there, but for the most part the code base (especially things like the css) are left alone.

But what do you do when your product is a complex web application? How do you best maintain your stylesheets when your app is constantly growing and evolving? It’s a lot more challenging than you might think, but there are several things you can do to keep your code optimized and maintainable.

In order to organize my thoughts, and perhaps throw some inspiration on the subject, I’m starting a series of posts each featuring a different thing you can do to best optimize and organize your css to face the challenges of a frequently evolving web application.

More >>

Clearing floats have always been an annoyance for us as web developers, because it requires us to use empty markup. It wouldn’t be that much of a problem, except that using floats for complex css layouts has become somewhat of an industry standard.

Not too long ago a new trick came along which had many css developers feeling lighthearted - a way to clear floats without markup. It was a simple, reliable css method that’s been around for ages - the overflow property. Simply by declaring this (usually to auto or hidden), you are able to extend the parent div over the floated divs, and effectively clear your divs - something you have previously needed an empty block level html element to accomplish.

More >>

I’ve always been a big supporter of hackless CSS. 99% of the CSS problems I’ve experienced have to do with rendering order and browser assumptions - for instance, when you set a float to something in Internet Explorer, by default it does not depreciate that element to inline; however that practice is followed in Firefox and Safari. It’s by learning these differences and putting catches in that you can successfully develop anything hack-free.

However, there’s one thing that I have never been able to get around without filters, and that’s font-sizes.

Font sizes can be called in three ways - using pixels, ems, or percentages. Setting your font-size in pixels is optimally ideal (although I could get into many fights with some of my college teachers about this) - we’re web developers, we live in pixels. We’re familiar with them, and we know how big a 10px font looks on the screen. Besides, ems and percentages are too relative to the browsers - 1em in Firefox is not the same as 1em in Safari.

So why not just use pixels? Well, technically you can, and it works cross-browser, cross-platform. However, there’s a catch - if you set a font size to a pixel amount in IE - it’s stuck at that size for life. Even if you adjust the font size in your browser settings. It’s a total accessibility crutch for close to 80% of the web viewing market.

So, if we want to develop accessible websites, what do we do? In college, I was taught to use ems, and it was all very defended: they’re fonts, after all. Set your font and get over the minor inconsistencies. It might have worked in Advanced Web, but in the Industry you have clients and designers breathing down your neck - they don’t understand why the font is slightly bigger in Safari, and they don’t like it.

So what do we do? The only real solution is in IE filters - sometimes they’re just a necessary evil. Luckily, the font-size problem is only in IE6 and below, so one simple star filter can allow you to set browser font-size in pixels, but in IE, use ems.

html { font-size: 10px; }
* html { font-size: .8em; }

For the rest of your font adjustments, feel free to use percentages or ems - everything will be relative to that base font-size setting.