TABLE-based layouts are as elastic as CSS-based
A 1st problem is that most available editors, because unable to handle TABLE intermediate elements (THEAD, TFOOT, TR, COL, COLGROUP, etc) and selections, and short of more synthetic views and tools, are forced to put a lot of FONT, WIDTH, etc, tags on low-level elements (TD, DIV, SPAN, etc) across the document.
As a result, a 2nd problem is that many people assume that a TABLE layout MUST be peppered with plenty WIDTH, HEIGHT, BACKGROUND, PADDING (and FONT etc) tags; e.g. ChangeProposals/NoLayoutTable states:
Device independenceThis is full false. There is no reason at all to put a lot of WIDTH in TABLEs, oppositely, you can put less of them than in CSS-based layouts. Details to follow.
It is relatively easy to make pages written with CSS-based layouts work well on devices with differing screen widths, such as mobile phones, automatically. In general, table-based layouts are much harder to do this on, as they tend to use precise dimensions, and often break in odd ways if things are resized unexpectedly.
Versailles, Tue 22 Mar 2011 19:16:00 +0100, edited 19:17:50