Michael Eriksson
A Swede in Germany
Home » Software development » Webdesign | About me Impressum Contact Sitemap

Use a flexible design

The “flexible vs. pixel perfect” conflict

Possibly the one single issue where the gurus of web design and the major corporations disagree the most: Should a website use a flexible design that looks good over a wide range of browsers—or should it be a study in inflexibility that makes assumptions about the user’s environment, in the hope of hitting a pixel-perfect ideal?

This page sets out to give an explanation of why the latter is a bad idea: A good designer knows to make a design where minor color deviations only have a marginal effect, where the layout looks at least decent in any reasonable resolution and browser, where the pages degrade gracefullye when the browser is configured to disallow a particular feature, etc.


I use the “pixel hunters” as a basis for the discussion—those who produce sites “Optimized for a resolution of 800x600. Best viewed with Internet Explorer 6.” (with variations). The same principles, however, apply to less extreme positions, with a general thinking similar to that of a bimbo of seventeen going to a party: Spends an hour trying to get the make-up perfect (typically ending up with too much), puts on shoes so high that she cannot walk in them without looking silly—and is unable to hold a man’s attention through an informative and interesting discussion (just like most of the pixel-perfect sites are lamentably lacking in content that would make them worthy of reading).

Why an inflexible design is bad

The attempts are doomed to fail

There is simply no realistic way for the implementers of a website to guarantee a particular result—except on the few computers they can directly control.

Consider e.g. that:

  1. Different browsers will display pages differently. This includes not only wildly different ones (e.g. Opera and IE), but also, often, different revisions of the same browser version (5.4.2 vs. 5.4.3) and the identical browser on different platforms.

  2. Even a user with the “right” browser and screen resolution need not see the intended result, e.g. because he does not have the browser window maximized (I very rarely do), browses in “full screen mode” (F11), has a side-bar activated, ...

  3. The impression created by the chosen color scheme will vary depending on what other colors are present on the screen—even the color of the frame of the physical screen. In a previous version of this site, e.g., the background normally looked baby-blue to me, but suddenly turned into an odd purple when a side-note was visible in the browser window.


    My side-notes have a different background color than the main text. Because color perception contains a large relative component, the presence of a side-note can affect how other colors on the page are perceived.

  4. The physical characteristics of the screen (e.g. brightness, contrast, color calibration, DPI) can affect how colors interact and how details are displayed. A too small font or an unfortunate color scheme might be legible on one display, but not on the next. A particular color might be OK on one screen, but too bright on another. Etc.

Negative effects on imperfectly matching environments

A common side-effect of attempts to achieve perfect appearances in one particular environment is poor to disastrous appearances in other environments. Examples of this include unreadable text when colors or fonts do not match, a page needing excessive scrolling on a smaller screen, various elements of the page over-lapping and interfering with each other, and even pages becoming entirely unusable when another browser is used.


What looks good is extremely subjective, where one man’s preference might be another man’s deadly sin. I, e.g., almost feel a physical pain when I see some combinations with very dark background and light text, and thoroughly dislike match-ups of several very bright colors. (Thank you, Opera, for your user modee.) Some others, in particular those with a background with DOS-terminals, prefer white text on a black background; others yet like color explosions.

Correspondingly, it might well be that the user deliberately circumvents the design provided by a website, e.g. by overriding the style-sheets—as is his good right. Interestingly, in my case, the likelihood that I want to do such overrides correlates positively with the amount of effort put in by (poor or management pleasing) designers. Those who keep it simple and conventional seldom go wrong.

Physical limitations of the users

Many users have physical limitations that force them to override the site design to be able to use the site at all. Many older users prefer to increase the font size (or replace the font entirely) or make all text bold. The color-blind might positively need to alter the color scheme (and even if they do not, their perception will deviate from the designers intentions)


There are websites (e.g. http://colorfilter.wickline.org/e) available that can translate webpages, images, and similar into a version equivalent to what a color-blind person sees. It pays to make sure that a site is at least readable after such a filtering.

Attempts at preventing user changes

It is my suspicion that many websites deliberately try to prevent users from adapting their surfing to their own preferences, and that this is one of the reasons (although likely not the main reason) why Flash, PDF, and similar non-HTML technologies are so common. Over the years, on a number of occasions, I have also seen questions like “How can I prevent users from [doing something that they have every right to do]?” in forums on web development.

Let it be clearly stated: The user has the right to control his own browser and computer, including how websites are displayed, what websites are allowed to do on that computer, and so on. The presumptuous view that the designers have the right to enforce what the user does, how he views a page, etc., is completely disjoint from reality (excepting behaviours that can be harmful to the site). By analogy, consider a user who buys a sofa, and is given the restrictions: You may not use the sofa for anything but sitting. You may not use the sofa when watching a TV channel not approved by us. You may not keep the sofa in a room with a wall-color other than green. We reserve the right to review and re-arrange your home so that the sofa can be enjoyed like we intended it to be.


Similar statements about lack of self-perspective and user-friendliness apply to many commercial software companies and the DVD industry.

Flash and the like

Whereas the above deals with normal web design (HTML, CSS) the same principles apply to Flash and other non-HTML technologies—and, as can be concluded, one of the main reasons to avoid them, is simply that they interfere with the user’s right to and benefits from controlling his own surfing experience.

Why a flexible design is good

In a nutshell, it removes most of the problems discussed above (although it certainly is possible to screw up the design in other regards).

To be a bit more explicit, a flexible design that does not aim at perfection in detail:

  1. Requires less maintenance. If a new browser, with a slightly different display, is introduced then the world keeps turning, without any need to change the page.

  2. Does not deteriorate unacceptably when the viewing conditions change.

  3. Makes it easier for a user to adapt his experience to his needs and wishes.

  4. Tends to be better usable by “special needs” users (although this can vary considerably).

  5. Does not annoy and alienate users at the rate that an inflexible design does.

Recommended tests

Disclaimer: At the time of original writing of this portion (2010), I was an Opera user and well familiar with the then feature set, which contained a few goodies not or only rarely available elsewhere. Since I abandoned Opera, it has been considerably reworked, I have no clue as to what non-standard features are currently available, and I do not guarantee that the recommendations mentioning Opera work today—nor do I rule out that other browsers contain similar functionality by now. However, as another good test is to view a page with an older and/or less popular browser, installing and using an old Opera version for tests might be very beneficial...

A few short tests that can detect many problematic cases with little effort:

  1. Watch the page in Opera with “fit to width” on and off. The page should remain identical or near identical. In particular, watch out for a horizontal scrollbar: If one is present in “on” mode, something is likely very wrong—and the presence of one in “off” mode (or in another browser) is at least a warning sign.

  2. Watch the page with different zooms in Opera: The readability of the page should decrease because the size of the contents is too large/small—not because the page display is worsened. (Just like watching a painting from a too short/long distance becomes harder without the painting, it self, changing.) A zoom change of at least 30 % in either direction should leave the page in good condition, with greater changes yet being tolerable.

  3. Use your browser of choice to increase/decrease font-sizes from what your design is based on. Similar numbers as for zoom apply. (Note that zooming and font-size changes are different things.)

  4. Watch the page in at least three sizes: Full screen, roughly standing A4, roughly standing A5. (The Ax formats might be made somewhat wider, if e.g. a side-wise navigation bar is present.)

    Note that the exact sizes are not important, what matters is that a sufficiently large range is tested.

  5. Turn display of images on and off: The page should still be at least semi-decent looking, and all functionality/navigation should be fully accessible.

  6. Run the page through a few contrast and color-blind checks.

I suggest combining several of the test settings above, not just to run them independently.

In addition, testing of the kind described on my pages about validation and my own manual checks is recommended.

What not to do

Since the first version of this page (2009), it has become ever more popular to try to achieve superficially similar effects with absurd techniques, often using terms like “adaptive” or “responsive” web design. (But terminology in the area tends to be inconsistent, confusing, or outright contradictory.) Such an approach could involve trying to find out what characteristics the browser has and to deliver a different design (or, even different actual contents) based on this; equally, it could involve using JavaScript to dynamically change the page to fit the browser. At an extreme, I have heard of those wanting to know how much battery charge a smartphone had left in order to optimize the page...

With rare exceptions, this is exactly the wrong thing to do and it is contrary to the type of flexible design discussed above. Moreover, it leads to unnecessary page bloat, slower pages, more development efforts, and can even bring on exactly the problems that it purports to solve.