Re: Hair loss and Netscape Blues !!

"Steve Acton, Aggregates UK" <Steve.Acton@rmc.co.uk> wrote:
	Developing my first site using tables for page layout

On my knees, I beg you,
with tears in my eyes, I *implore* you,

    PLEASE don't do that!

Your layout will work just fine in *your* browser on *your* screen;
it's a pretty safe bet that it will not work in *my* browser on your
screen, or in your browser on my machine.

You can specify the width of a table, column group, or column
in two ways, both of which are wrong.

    nn (pixels)

	The trouble is that
	(a) The number of pixels per unit length varies from screen to
	screen.  I have two machines on my desk both of which have
	about 89 pixels per inch.  On a colleague's Windows box, images
	are nearly twice as large.  If you use pixels, you are measuring
	with a rubber ruler.

	(b) Different people like to have their browser windows at
	different sizes.  If the number of pixels you specify is less
	than the size they have chosen, you'll be wasting screen real-
	estate, which is not really excusable in a web page.  If the
	number of pixels you specify is more than the size they have
	chosen, information will be lost off the edge of the window;
	with a bit of bad luck your hapless viewers will never even
	know it was there.  That is very bad manners indeed.

	(c) What fits on a screen may not (in fact probably WILL not)
	fit on a printed page.  I am heartily FED UP with documents
	where the last two or three words per line are lost from the
	printed page.  If the information you are presenting is worth
	having, it is worth printing, and fixed width tables (unless
	the width is rather narrower than you think) don't print worth
	a tinker's curse.

	(d) You have no idea what fonts your viewers will have available.
	In particular, you have no idea what size they will be.  Even if
	someone has fonts with the same names as the fonts you expect,
	and the same "point" size, you should be aware that the number of
	screen pixels per character point varies and is not known to you.
	Let's put some numbers behind this:

	    Width chosen to be 72 characters
	    at 6 characters per inch in your chosen font/size
	    = 12 inches

	    Screen has 72 pixels per inch,
	    so set width to be 864 pixels.

	(Ignore the fact that one of my machines has a screen that is
	A4 size/shape, so that much width simply isn't physically available,
	and that I can only print on A4 paper.)

	Now let a viewer have a font which is also 6 characters per
	inch for his display, but he has 89 pixels per inch.

	864/89 = 9.7 inches = 58 characters.

	OOPS!  Now your text doesn't fit into the width you specified.
	This is not rare.  This is not exceptional.  This is *COMMON*.
	And of course the numbers can go the other way.  The point is
	that after all your careful layout, what your viewer sees will
	probably be less like what you see than you can imagine.

    pp% (percent of available width)

	This is much better.  It solves the wasted screen real-estate
	and text-lost-off-the-right-margine problems.  However,

	(a) You have no idea what the available width is, so you are
	still measuring with a rubber ruler.

	(b) is fixed, but there is a related problem.  10% of the width
	you like, with your fonts, on your screen, may be enough to be
	useful.  10% of the width your viewer has, with her fonts, on
	her screen, may be very little.

	(c) is fixed

	(d) Font availability and resolution still vary all over the
	place, so you have very little idea where the line breaks will be.
	Note for example that I tell any browser that will listen
	"do not let font sizes go below 12 points".
	
Now what is the point of trying to control your layout using tables?
Surely it is to control your layout.
But I have now explained that you can *not* control your layout the way
you expect to; people with the same browser, screen, and tastes as you
will see what you see, but most viewers will *not* see what you see.

Don't forget, some people browse the web using Lynx, and some people
browse the web using Emacs.  And some people use audio browsers.

By far the best approach is to control layout using CSS.
That will mean that browsers that are not CSS-aware can just display
the text legibly, while browsers that _are_ CSS-aware can do a much
better job of controlling layout (you can specify absolute sizes in
inches or millimetres, and you can specify relative sizes in terms of
the size of the font the viewer is seeing, amongst other benefits)
than tables can ever possibly do.

	All works fine in IE 5 but in Navigator 4.75 it's a disaster !

There are plenty of people still using Netscape 1 and 2!
There are also people using IE 4, Opera, ICab, Lynx, Emacs, and Amaya.

	I've read that Netscapes' implementation of CSS is patchy to say the least

What you should have read is that Netscape 6 has recently been released.

	Examples of what's going wrong include:
	-	correct rendering of cell bg colours

That is *going* to happen anyway.  Don't forget, some browsers cannot
display colour, some can display colour but not the colours you want,
some can display the colours you want but have been told by your viewers
not to.  For example, my browsers have been told very definitely *not*
to use any colours other than black and white, because I am fed up with
idiots who think that yellow on white is cool.

The single most important thing to understand in Web design is that it
is not desk-top publishing and *cannot* by the nature of the medium give
you the level of control you want.

	-	incorrect cell dimensions

Even CSS cannot fix this.  "Correct" dimensions might be "exactly the
physical size I mean" or "holding exactly the amount of text I mean".
Neither of them might even be possible.

Have you tried your pages in an audio browser?

The web design books I've studied all say pretty much the same thing:
if you really need control of positioning, use PDF.

Received on Tuesday, 12 December 2000 16:56:40 UTC