The struggles of having an elastic layout

For the moment, I’m working on a fairly big project where the interface design will be elastic. What do I mean by elastic? Basically, there are three ways one can choose to design the interface’s relation to the visitor’s resolution and web browser window size:

The layout is fixed in pixels and won’t take any consideration to the resolution or the window size.
The layout flows to fill the whole window, no matter how wide or narrow it is. This layout can be set in pixels, em or any other desirable unit.
This is, in my opinion, the best one. It isn’t fixed, but it also stops from getting too wide for, for instance, wide-screen users. You can specify a maximum width and a minimum width and then you let it flow between those two values depending on window size. The units for this type can also be either one that suits best: pixels, em, percentages etc.

Since I want my font to be scalable, and consequently the width and height of some elements resizable to go with that, I’ve chosen to use the em unit for most cases. This is to make it work in the different versions of Internet Explorer in Windows, since they can’t handle user resizing of a pixel-based font (as opposed to Firefox, Opera and Safari, amongst others).

It’s really invigorating to create something that’s so scalable and flexible, and I really do believe this will help targeting more end users and will make the web site become more usable and accessible for them. All the people involved in the project who have seen my HTML prototypes have really liked it and they think it is a great approach.

But naturally, creating a this isn’t without gripes. My biggest annoyance is web browser bugs, where number one on that list is rounding errors. If I have, for instance, a background color on an element and the font is resized, some elements will have a different height in Firefox than in Internet Explorer. This is because the em unit calculates the elements’ boundaries depending on what fontsize is used, transforms it to pixels to render, and inevitably this leads to different rounding sums. Firefox definitely seems to be the worst at this.

The key to solving this is to find a certain unit where all (read: most) web browser seem to agree on the rounding for different sizes. So, for the moment, I’m on top of things and I really like the web site I’m working on. But it’s an everyday control task, to make sure that it’s consistent.


  • Looking forward to you posting the address for a look-see once the project is complete!

    I tend to allow the type and quantity of information to dictate whether a fixed-scaleable or elastic-jello solution is best, or my mood πŸ˜‰

  • Tommy Olsson says:

    The traditional definitions are:

    Fixed: using pixels

    Fluid: using percents

    Elastic: using ems

    A fluid layout adapts to the browser window size, while an elastic layout adapts to the font size. The best solution is usually a hybrid between those two.

    With a fluid or elastic layout, you shouldn't attempt to create a design that requires pixel-perfect alignment, because there will always be some special case where rounding errors wreak havoc.

    Since 16px seems to be the most common default font size, you can alleviate the problem by making sure that your em-based sizes will round to an integer based on 16. In other words, use 0.75em (12px) rather than 0.8em (12.8px). It's not fool-proof by any means, but it will work for a majority of your users.

  • Robert Nyman says:


    We'll see…

    I'm not that keen on outing what I work with, mostly because some of my stories might be from that assignment and I don't want to point finger at them.

    I like your preferences for choosing a layout type… πŸ™‚


    A bit weird when you don't link your name anymore (also some time since I saw you here)…

    Fluid doesn't necessary have to be percentages, for instance, the side columns can have a fixed pixel width and the main column can be fluid in the sense that it has <code>margin: 0 auto;</code>. But yes, it usually involves percentages in some sense.

    Since I'm not the one behind the design, I can't really make that call about pixel-perfect design. But of course I affect the ones responsible for that the best I can. However, I've also seen errors in Firefox like where a container element has the same height, specified in <code>em</code> as it's block element child, but when changed to certain font-sizes, there's still a gap between the container bottom and the child's bottom boundary.

    The number tip when it comes to choosing what <code>em</code> value to use is a good one, it might come in handy. Thanks!

  • Tommy Olsson says:

    Well, I've been on a much-needed week-long holiday on Cyprus. Totally off-line. πŸ™‚

    Fluid doesn’t necessary have to be percentages, for instance, the side columns can have a fixed pixel width and the main column can be fluid in the sense that it has margin: 0 auto;.

    That sounds a fixed/fluid hybrid. Fluid means that the design adapts to the window width. A fully fluid layout is usually not desirable, because it can become too narrow or too wide. A constrained fluid layout (with min-width and max-width in ems) tends to be better.

    Also, a hybrid where sidebar are specified in ems (elastic) and the main column is constrained fluid tends to work best for content-heavy sites in my experience. A graphics-heavy site has other needs, since images are inherently pixel-based. There are ways around that, but cross-browser support is iffy.

  • Robert Nyman says:


    Welcome home, then! πŸ™‚

    And most layouts, in my opinion, are usually hybrids of some sort. And that's normally to what I refer when I say elastic: being sort-of fluid but within certain limitations.

    Image-wise, I think it works pretty well setting them in <code>ems</code> or percentages, where the original value corresponds to the image's original size.

  • Funny you're mentioning scalability issues. Yesterday I've spent a good three hours building a navigation using visual goodness such as rounded corners on the bottom left and right part of the entire navigation area, not per item, and some borders/gradients making things a bit more interesting.

    Weird how you've found Firefox to be the most problematic with rounding errors when using <code>em</code>'s. When using percentages, I've found Firefox and IE to be exactly the same with Opera being the one pissing me off time and time again.

  • Robert Nyman says:


    I'd might add that <acronym title="Itnernet Explorer">IE</acronym> can act pretty erratic when having 100% width on some elements…

    Opera has wrecked many things for me too, so I share your pain. πŸ™‚

  • Opera… It aint over 'til the fat lady sings… and she usually has a frog in her throat πŸ™‚

    IE and percentage widths within a layout confuse me – it seems to differ in its interpretation to other browsers in so much as it always relates percentages to the whole page width, whereas every other browser I've tested relates them to the element your styling – unless I'm missing something?

    IE differs from other browsers – hey, that's news πŸ™‚

  • Robert Nyman says:


    Yeah, Opera's usually the frog in the throat… πŸ™‚

    <acronym title="Internet Explorer">IE</acronym> is pretty good at displaying a behavior that isn't expected nor in line with other web browsers'.

    If you want to do some reading up on <acronym title="Internet Explorer">IE</acronym>, I recommend Position Is Everything's Explorer Exposed page.

  • Thanks Robert πŸ™‚

  • Mauricio says:

    Clear examples of fixed, elastic and liquid designs for comparisons?

    BTW: Nice site robert, lots of nice useful readings here, most of them are useful for repairing wrong concepts in mind and fix the correct concepts, at least about CSS and JavaScript. Need some more time for reading all the sections!

    This input section is a simple but really nice idea of inpu preview on-the-fly.

    Nice job πŸ˜‰ (wow, even some emoticons!) πŸ˜€

  • Robert Nyman says:


    Thank you, I'm glad that you like the web site!

    A good reading about different types of layout can be found in Fixed vs Liquid vs Elastic.

  • […] The Struggles of Having an Elastic Layout – Robert Nyman […]

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.