Frequently Asked Questions About Screen Resolution
The term resolution when used in this FAQ refers to the monitor size in pixels, e.g. 800x600. Technically “resolution” is a measurement of dots per length unit (e.g. 96dpi), but since “everyone” use the term “resolution” while meaning the former we’ll use it in this FAQ as well.
Can We Drop 800x600 Now?
No.
There still is and will be people who use 800x600 resolution, either because of hardware limitations, sight impairment, or personal preference. Even if everyone used a higher resolution that doesn’t mean that the browser viewport (the area in which your Web page renders) is as wide as the available screen area. The higher resolution people have, the less likely it is that they browse maximized. The browser window is basically more or less the same width regardless of the screen resolution, it’s just that the user has more available screen space for other things at the same time.
Some users also like to have a sidebar open while browsing (which can take up hundreds of pixels). Others might want to browse with two windows side by side, which means that with a resolution of 1280x960 each window can only be 640 pixels wide.
There are also some PDAs that have a 800x600 screen resolution, and use CSS “screen” media for Web pages.
What’s The Optimum Width You Can Use for 800x600 or 1024x768?
There is no consensus on a holy optimum as far as we can tell. Because of scrollbars, borders, snappers, etc., and because the browser window might not be completely maximized, you should probably subtract 20–50 pixels.
Which is The Most Common Screen Resolution?
As of early 2007, and according to the statistics we’ve seen, the most common screen resolution is 1024x768. But this information is not very useful; what is more interesting to know is the browser’s viewport width. Your Web page renders inside the viewport, not on the entire screen.
Different CSS for Different Resolutions with JavaScript?
It is possible to get the available width with JavaScript, apply different style sheets on load and on resize, but this is not a very good approach, both because it relies on script (which can be disabled or blocked by firewalls, etc.), doesn’t perform very well, and can be done much simpler and more performant with just CSS using a fluid/elastic hybrid layout. Changing the layout when the window is resized can also cause usability problems since the user can loose track.
If you want to have a different layout on handhelds then JavaScript is not an option, because most mobiles don’t support JavaScript in the first place. You should use CSS media queries instead (e.g. media="handheld").
Fixed vs. Fluid?
Fixed width means that the width is specified with a measurement that doesn’t adapt to the browser width nor scale when text is resized (most often specified with px). Some designs “require” a fixed width to some extent, mostly because of heavy use of images, or are just simpler to implement using a fixed width. However, with wide browser windows the site becomes relatively narrow, and with narrow browser windows the page is too wide, resulting in a horizontal scrollbar. Additionally, since the user can resize the text, the line length becomes too short at large text sizes, and too long at small text sizes. If you have only done fixed width layouts in the past then we encourage you to take a closer look at the alternatives below.
body { width:760px; }
Fluid width means that the width adapts to the browser width (either using the keyword auto or using percentages). With this type the user has control of the line length: simply resize the window. The typical argument against fluid width is that people who use wide browser windows may get too long line lengths. This might not necessarily be a disadvantage however; in some cases long line length results in faster reading, or is just preferred or even needed because of certain types of reading disabilities. People who prefer shorter line length can always make their windows narrower.
body { width:95%; }
Using a fluid maximum width on images is very useful to make sure images don’t break the layout or cause a horizontal scrollbar in a fluid (or elastic) layout. As the column gets narrower, the image will scale down, and the height of the image will stay proportional (given you don’t use the height attribute in the markup; if you do, try height:auto in the style sheet).
img { max-width:100%; }
Elastic width means that the width scales when the text is resized in the browser. This has the advantage that the line length doesn’t get too long, regardless of text size. The disadvantage is that it may become wider than the viewport, resulting in a horizontal scrollbar.
body { width:60em; }
A hybrid is a combination of the above, for instance using an elastic maximum width and otherwise fluid (referred to as fluid/elastic hybrid).
body { max-width:60em; width:95%; }
Different situations and audiences require different approaches. However, a fluid/elastic hybrid has the all the perceived advantages of both fluid and elastic while at the same time avoiding the disadvantages (except in the case where long line lengths are preferred), which is thus a good choice in most cases if the design allows for it. If not, you can still use a fluid/fixed hybrid, with fixed minimum/maximum width and fluid in between, which at least avoids the horizontal scrollbar in the range where it is fluid.
More specifically, fluid and elastic works well when the column is mostly text. If you e.g. have a fixed width sidebar (with mostly text), then as text is resized the line length quickly becomes too narrow (long words might not even fit, which might be a problem with languages that have many long words). If you have a column with only or mostly images (and you don’t want to scale them), then fixed width might be best; otherwise you might crop the images or waste space if the column is wider than the images.
For IE6 you can either just fall back to fluid or fixed, or you can use [post=2041241]expressions[/post] to simulate support for min-width or max-width. (Those properties are supported in IE7.)
Further Reading
