A major problem encountered in a web design is one experienced 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 width and
height attributes of the
<img> 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>.
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
SharedMemModeCopyOnWrite, 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>, ​ 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.