A major problem encoun­tered in a web design is one experi­enced when, although the page's width is not fixed, its minimum width happens to be greater than the visitor's browser's window's width. This causes the nuisance of horizontal scrolling.

But what is the minimum width one should be designing for?

You might initially see this completely open-ended: whatever width you manage to slim your page down to, there'll be someone with a narrower window to ruin the effect — until you get to zero, which is absurd.

However, note that the user is already discouraged from narrowing her window too much, as toolbars and window furniture become less usable. So narrower windows must be increasing rare, and you should worry less about catering for them. After all, if your website's purpose is to present something that is intrinsically wide, the narrow-window visitor must already have accepted some rendering nuisance.

But the normally very flexible text also has an intrinsic minimum width. The text has a longest word within it and, in the absence of hyphenation, the width of that word (plus margins, etc) is the absolute limit. If the visitor is trying to view text containing that word in such a small area, then there's not a lot you can or should do about it. It's an extreme case without solution.

Nevertheless, you should do nothing to break your design until that point. A page of text might still contain several things that are instrincally wide, such as large images and tables, or program scripts, but it is important then to ensure that wide objects do not prevent the text's ability to fit the available space, as the ability to see those objects is usually much less important than to be able to read the text.

• Ornamental images can be scaled.

  An ornamental image is one whose absence doesn't defeat the purpose of the page (so its alt attribute is usually empty).

  (Obviously, if your site is an image gallery and nothing more, someone browsing without images is never going to be able to appreciate it, and there's little you can do about it. Such images are not ornamental, so we won't deal with that case here.)

  Because the image is ornamental, its displayed size might not matter. In a wide window, it can be displayed at actual size, because the space is available. In a narrow window, you just don't have that space, so you may as well allow the image to shrink.

  My specific advice here is to:

  • set the <img>'s width and height attributes to the exact image size,

  • set width and height in CSS to auto,

  • set max-width in CSS to a percentage of the space available.

  In the wide window, max-width will have no effect anyway, as the image's width is smaller than the percentage you've set. In a narrow window, max-width constrains the image, and the auto height ensures that its aspect ratio is maintained.

  For floating images, set a max-width of less than (say) 50%, which gives plenty of room for the text flowing around. For other images, anything upto 100% should be fine, although a little less might help some rendering engines that don't take account of margin, padding and border sizes.

• Don't put things that aren't tabular data into <table>s.

  Suppose you put some flexible text into a single <table> with a single cell. Then you shove a wide image into it as well. What happens? The image forces the cell (indeed, its column) to have a certain minimum width. The text, which might have been able to fit into a narrower column, now fills it out, even into parts accessible only through horizontal scrolling.

  So, even though the text could have been read without horizontal scrolling, the image inside the cell has taken away that capability, and ruined readability of the page in a narrow window.

  Without the <table>, it might not be so bad. The visitor will see a column of text fitting neatly into her window, then an annoying image which needs horizontal scrolling to be fully appreciated, then some more fitting text. And the annoyance might not even be a problem if it's only ornamental.

  Don't abuse <table>s like this.

• Break long words with soft hyphens and zero-width spaces.

  Within normal, but very long words, you can insert ­, ­ or ­ at appropriate places to advise the browser where would be the best place to split the word with an actual hyphen.

  However, the results can be unsatisfactory when hyphenation isn't supported. At best, the soft hyphens are ignored; at worst, they always appear, or appear as unrecognised characters. Fortunately, very few words are so long that they cause much trouble anyway.

  There are other long strings of characters (URIs, program mnemonics, etc) which need breaking, but not by hyphens. Ideally, these require zero-width spaces – ​ or ​. For example, the mnemonic SHMEM_​MODE_​COPYONWRITE, clearly contains points where you can afford to split the word when not in the strict context of actual program translation, i.e. after each underscore. Other examples could be camelcase names, such as Shared​Mem​Mode​Copy​On​Write, and URLs/​URIs.

  Again, there are pitfalls. If the text is copied out into someone's actual program, it might still contain the special space characters, and cause translation to fail. Perhaps user-select: none will eventually help to deal with that…?

  Also, if not fully supported, the spaces can worsen the appearance, though it might not be so important in such a technical context.

  An alternative to the zero-width space is the <wbr> element. It is widely supported, fails gracefully, and isn't copied out as part of the content. But, unhappily, it does not conform to any W3C standard.

  Yet another possibility is just to leave it all up to the browser. I've noticed recently that more browsers are breaking URIs after slashes by themselves, though I don't know how they decide whether this is right in each case.

  • wbr — Shows browser compatibility for <wbr>, ​ and ­

• Give wide objects their own scrollbars.

  CSS2 defines an overflow property to specify what should happen if the object is larger than the available space. The default setting is visible, i.e. allow it to spill out of its surroundings. You could override it with hidden, if seeing the whole object is not that immportant. Or you could try scroll – the object will get its own scroll bars, so it's all independently visible if necessary. Finally, the best option might be to use auto – scroll bars will be added as necessary: probably, in narrow windows; unlikely, in wider ones.

  Note that overflow might not be supported, even if CSS is, so it can only ever be just a hint to improve things. Also, when it is supported, there might still be a problem. Firefox, for example, does not try to keep the scroll bars visible when the bottom of the object is scrolled away in the containing area. So, if a long program listing in a <pre> block has scroll bars, you can scroll it horizontally only if you scroll the main window down to the bottom, even though you might be trying to view a part near the top.

  If overflow does not appear to work for some element type, say <table>, try putting it in a <div> of its own, and applying the style to that.

• Don't discard the ability to wrap content. Doing so gives an object an unnecessarily large minimum width.

  For example, you might think that your horizontal navigation bar should not wrap, for aesthetic reasons, so you set its white-space property, or remove its white space, or set it in a <tr>, so that it won't wrap. But why are you doing this? In your wide window, where you do your testing, it has ample room anyway, so wrapping was never a threat. In my narrow window, you can choose that I have either slightly unaesthetic two-line navigation, or hideously unusable horizontal scrolling. Choosing the latter would be a case of taking a positive action to worsen the browsing experience of a minority, for very little gain for the others (none, in fact).

CSS3 proposes media queries. (Indeed, these are already partly standardized in CSS2 and HTML4.) The idea is that parts of a stylesheet may be applied conditionally on the type and characteristics of the rendering medium. The medium ‘type’ is the feature already standardized – the <link> element in an HTML document, that specifies a stylesheet, can also specify the suitable media (such as print, screen, aural, tactile). If the browser's medium isn't suitable, it doesn't apply the linked styles. The same sort of condition can be applied to a CSS fragment using an @media rule. CSS3 enriches the syntax of the condition, allowing it to be expressed in terms of the width or colour depth (etc) of the medium. This then opens up the possibility of applying a width-hungry layout only when the width is available, and using a more narrow-friendly layout otherwise.

IE and Firefox support media queries based on media type. Opera and Safari go further, and support some expressions.

• Media Queries — A proposed method of applying style conditionally on the medium and its characteristics