…web design…

more min/max-width in IE6…

This article is an extension of the min/max – making IE/win work article I wrote most of more than a year ago. Many factors have changed, but my site still uses the same solutions – in upgraded versions.

When I make sitewide design-changes, I normally want IE6 to play along even if its CSS support is “poor” – to avoid using stronger words. IE7 isn't much better, but it's usually quite manageable with more regular CSS workarounds than its predecessor.

The only available workarounds for IE6 lack of CSS support, is emulation through Javascript in one form or another. I choose to use IE-expressions in order to get the most seamless CSS-emulation in that old bugger, simply because they tend to perform better than regular Javascript in most cases I deal with.

If anyone got a more well-working, pure Javascript, solution, then by all means use it – I certainly wouldn't mind using one myself. However, I'm not proficient enough in Javascript to create a script that out-performs my IE-expressions, and I'd rather spend time learning to write proper, cross-browser performing, scripts for more important tasks than to make an old and dying browser behave.

making 'em' based max-width work in mixed layouts…

This is a funny, but often quite useful, use of 'max-width'. As layout-combinations based on “fixed”, “fluid” and “elastic” are used more and more, my “conditional elastic” should fit right into the mix – and it works just fine in all new browsers.

Let us say we have a multi-column layout with one or two fixed-width side columns and a fluid-width main column, and would like to declare 'max-width' for the fluid main column – also in IE6. No problem if we declare 'max-width' in 'pixels', but now we're mixing in 'em' again and are creating a fixed/fluid/elastic layout with mixed units.

The fluid main column on this page has been given such a font-size dependent 'max-width'. The idea is of course to make the most out of available space, while keeping lines of text short enough to make them easy to scan and read.

Declaring 'max-width' in 'em' gives us an average maximum number of characters, and I've opted for max 70-80 characters pr. line with the suggested font-family: “Georgia”. Resizing fonts in your browser on a reasonably wide screen / browser-window, shows how it works – now also in IE6.

getting user's font size preference:

Detecting IE6' user-defined font size isn't a problem since it's the only browser that readily reveals this information. However, calculating max-width for the fluid column based on window-width minus the width of the fixed-width column(s) divided by font-size, adds an extra layer. Luckily: the fixed-width columns give us fixed numbers, so we just keep them out of the 'em' calculation and add them at the end.

the regular 'em-based max-width' calculation:
* html body div#content div {width:expression(
(document.documentElement.offsetWidth) >((630/12) 
* parseInt(document.body.currentStyle.fontSize))

What we have is (630/12), which is exacly '630px' (≈ '38em') at medium font-size for the fluid column. That's a suitable 'max-width' in my case.

We then add 248px of fixed-width columns and other fixed horizontal space, and check if the browser-window is wider or narrower than this total – '878px' at medium font-size for the entire page.

The result is either a fixed "38em" if the browser-window is wider, or a fluid "100%" if it is narrower. If we got our numbers right, then IE6 should handle our 'max-width' close enough for comfort.

Important: any author-declared font-size on body, means complete failure in IE6.

The above is of course just one way to solve such a case, but it is a well-working solution for most mixed-width layouts. The procedure can also be used to smoothen out cases where margins, paddings or borders on fluid columns – or whole pages for that matter – are declared in pixels. Percentages can also be mixed in with a bit of care, making such unit-mixes work just fine even in IE6.

solving the problem with too small fonts in IE/win…

On my own site I've added a slight “font resize correction”, to prevent the more ignorant IE/win users from ending up with a much too small font size because they have accidentally set “font size” too low in their own browser.

We may talk about “relative font-sizes” and “respecting user preferences” all day, but at the end of the day some IE/win user may comment negatively about the “much too small text” in our web documents, without realizing that they have actually chosen that small text size in their own browser.
I've grown a bit tired of repeating myself on the subject, so I've chosen to do something about the problem and actively counter-adjust font-size in my documents.

This “font resize correction” affects all present IE/win versions (including IE7), since ignorant IE/win users often just upgrade their browser – not their skills and knowledge about how it works.

the (mostly) unobtrusive mouse trap:
html body div#wrapper {font-size: expression(
: "100%");

The above is simply reducing the effect of “smaller than normal” font size settings in IE/win by changing the convertion-factor for font sizes in the page when “smaller than normal” font size is set in that browser – without interfering with the browser itself. It's the near perfect mouse trap for catching ignorant IE/win-users in their act, without disturbing them or anyone else all that much.

Never mind the name; I think 'mouse trap' sounds just right on this site .

Again: any author-declared font-size on body, means complete failure in IE6.

I may elaborate on this mouse trap at a later date, once I have given it a thorough, sitewide, live testing to catch any potential drawbacks.

the tailor-made IE-expression I use on this site…

When I use the mouse trap described above, I also have to account for it in my 'max-width' emulation. Otherwise the 'em based max-width' won't measure up correctly for “smaller than normal” font sizes.

As mentioned: this “font resize correction” affects all present IE/win versions (including IE7), but I only have to take it into account when emulating 'min/max-width' in IE6 (and 5+/win). IE7 supports CSS 'max-width', and doesn't need further help.

Probably many ways to solve this, but I've opted for the very direct way of including the font size detection/correction in the max-width emulation, making the IE-expression look as follows.

conditional elastic with mouse trap:
* html body div#content div {width:expression(
(document.documentElement.offsetWidth) > (((630/12) 
* parseInt(document.body.currentStyle.fontSize)))*((
*7)+100 : "100")/100)+248? "38em":"100%");
height: 1%;}

Yeah, slightly more complex than the regular 'em-based max-width' calculation, but not by much. It will of course only work as intended when the actual “font resize correction” is acting on the page-wrapper, so the '(mostly) unobtrusive mouse trap' and the 'conditional elastic with mouse trap' expressions belong together in the same IE/win-only stylesheet.

You can use the '(mostly) unobtrusive mouse trap' completely on its own, but not the 'conditional elastic with mouse trap'.

Once more: any author-declared font-size on body, means complete failure in IE6.

Yeah, I have repeated that message about not declaring font-size on body a few times. I mean it.
I also mean it when I say that font-sizes in percentages work most consistant across browser-land today, and that using percentages is the best way to assure that the IE-expressions described above will work as intended.

having an IE/win only stylesheet…

Some are looking for IE-expressions in my stylesheets, without finding any. No surprise, as they are placed in four IE/win-only stylesheets – one for each layout-version on this site.

I use the @import hack to keep these stylesheets invisible to other browsers, and that explains why there are no “conditionally commented stylesheet links” in the page head. All IE/win versions get the same stylesheet(s), and are separated at CSS level.

testing – testing – testing…

I'll give the solutions described above time to settle, before adding more detailed information. In the mean time: anyone can test their performance since they are already included on this site and tuned for each of the four layout-variants I use at the moment.

Don't worry: I have already written every detail down, but I always find it best to check and re-check the actual solution quite a few times before releasing all details about it. Anyone who know something about Javascript can interpret my expressions directly anyway, and probably improve on them too.

There's only one reason to do anything for IE6, and that is to prevent that old bugger from holding us back even longer.

I do use IE-expressons to fix IE7 too – when necessary, as its CSS support is not up to much when compared to other major browsers.

This article, with its examples, is delivered as is. This very page proves that the examples work as described, since they are direct copies of what's behind it – in IE/win.

Now, remember that IE-expressions depend on Javascript support, and that font size on a web page – any web page – can be ignored in IE/win.

That's it – for now.

sincerely  georg; sign

Hageland 19.nov.2007
last rev: 02.dec.2008


IE6 is dead, so we may as well dance on its corpse before it rots.
— Georg

If anyone is in need of a new, weak, browser to play with, then IE7 is probably the best choice today.
— Georg

If one still insists on staying behind even after having tried the above, then IE8 will come handy.
— Georg