additions…

…web design…

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))
+248? 
"38em"
:"100%");}

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(
(parseInt(document.body.currentStyle.fontSize))<12? 
((12-(parseInt(document.body.currentStyle.fontSize)))*7)+100+"%"
: "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)))*((
(parseInt(document.body.currentStyle.fontSize))<12? 
((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 

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