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,
emor 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 😉
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.
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!
Well, I've been on a much-needed week-long holiday on Cyprus. Totally off-line. 🙂
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.
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.
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 🙂
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 🙂
Clear examples of fixed, elastic and liquid designs for comparisons?
This input section is a simple but really nice idea of inpu preview on-the-fly.
Nice job 😉 (wow, even some emoticons!) 😀
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 […]