Tables for Layout: The Only Option fo...

Go take a close look at the real (non-demonstration) sites that have been designed with CSS layout and positioning. For the vast majority of them, depending on your hardware, you will not see their content displayed in your web-browser the way you would see, say, the content of a document displayed in your word processor. Instead, your web-browser will likely have blank strips on either side of a ribbon of content, which runs down the middle (or down the left side) of the window...

By contrast, you may notice that you can display a document in your word processor on a machine with an old 640 by 480 VGA display, or on a newer machine with a much higher resolution and it will always display your content over the full screen, utilizing whatever pixels your hardware happens to have on hand to throw at it. You can even display a text document in a command-line window (a DOS box) and have that text use the entire screen. It wont matter how many, or how few pixels your actual underlying hardware has, the content can be sized to take up your entire screen (or any portion of the screen you choose).

This, however, is not the case for web-pages that use CSS layout and positioning. The content remains a fixed number of pixels wide, regardless of how many pixels your hardware is capable of. The extra capability of your shiny new laptop is simply wasted, as blank strips on your browser-window. Why? Because the page is specified in pixels, and has to be written to look acceptable on hardware with lower resolution than your new laptop.

What does this have to do with your mayor? Simple. Those blank areas in your browser window are no less obvious, no less absurd, and no less ridiculous than your mayor would be, if he were strutting up and down your town's main-street completely naked (people who live in LA will just have to trust me on this).

As your word-processor and other utilities plainly demonstrate, all the problems with software utilities being restricted to a specific hardware limitation, such as a specific number of display-pixels, have long been resolved.

Apparently, the keepers of the CSS standard never got the memo.




Cascadism is my coined term, that metaphorically evokes cubism. It essentially relates (metaphorically) the visual effect a web-page viewer sees when an attempt is made to make a CSS-laid-out web-page variable sized, and it is shrunk beyond its designed minimum display pixel-count. This can occur, either when the user resizes the browser window, or when the page is displayed on a monitor with a lower-than-supported screen resolution.

This happens on almost all of the pages so designed, because, in order for the text not to look like mico-miniature fine-print on high-resolution screens, its size has to be specified the correct, hardware-independent way. The other elements, however, must be pixel-bound., so the text grows in relation to them, as the machine-resolution increases

The effect is that text, and other content elements are moved around and overlapped, causing them to be displayed in irrational and confusing ways on the viewer's screen. To the viewer, the screen vaguely resembles a cubist-art styled painting, with its jumble of otherwise-correct components (ok, so its not a very good metaphor ).




Designers who use CSS for layout may choose the safe route and go with the most reliable least-common-denominator: a standard VGA-resolution monitor, which is 640 by 480 pixels. The problem here is that many people have much higher resolution monitors. On those high-resolution monitors, that 640 pixel wide web page will look like a thin ribbon of cluttered content, running down the middle (or left side) of the screen.

Because CSS designers are forced to design for specific hardware limitations, they are forced to pick a representative piece of equipment that is a compromise between the various hardware-configurations. To avoid the "ribbon" effect they may decide on a slightly bigger-than-standard: SVGA resolution of 800 by 600. This will allow their hardware-bound designs to look perfect on 800 by 600 monitors, but have the tell-tale strips of unused space on monitors that are any larger. On displays that are significantly smaller, their pages will likely become "cascadist" in appearance. Especially on the quarter-VGA screens that you sometimes see in use on peripheral equipment, such as printers.

So, no matter how you slice it, even choosing a compromise-resolution of 800 by 600 doesn't really solve the problem. That decision still has the problem of making the content look like a thin strip down the middle of the much higher-resolution screens. The trend has been, and continues to be towards ever higher resolutions. This is also a problem for purists, who have a moving target when deciding what representative hardware they should use as a compromise for their web-site's pixel-bound layout designs.

If you use too low a resolution hardware model, you will end up with pages that look like content-ribbons, or zippers, down the middle of many user's screens. On the other hand, if you settle on designing for a hardware resolution that is too big, many prospective visitors will be taken to a jumbled cubist tangle, of text and other screen elements that make no visual sense at all. Or, just as bad--if you use the "everything-pixel" technique--even those with reasonably high screen-resolutions will be required to use the horizontal scroll bar to see the page.




The shame of all this is that there is absolutely no need for any of it. Not the empty-strips, not the cascadism, not the wasted screen-resolution. Most importantly, there is absolutely no need for the web-page designer to have to make the impossible design-decision of selecting a compromise hardware-based pixel-resolution. Standards that are REAL, and EVOLVED from practical use, already exist. These allow the design of web-pages that remain rational and ordered, no matter how small they are shrunk. If the window is shrunk to smaller than the sizes of its individual elements, a horizontal scroll bar will appear, allowing the viewer to scroll over very scrunched-up content; but the page-layout and text will remain rational, and orderly.

At the other extreme from the scrunch-scenario: using REAL, existing, WORKING standards means no tell-tale wasted-space bars for people who are lucky enough to own hardware with higher resolution than your exemplar.

The content is laid out on the viewer's SCREEN, not on one specific PIXEL-ARRAY that exists on only one particular example hardware-platform. In a world where there is no "standard" pixel-resolution, a standard that forces web-page designers to select one is simply not viable.




Is it any wonder that even the most insulting of CSS promoters --those who will absolutely insist that YOU use CSS positioning-- often use a much more rational mix of CSS and existing "evolved" standards for the actual productive pages of their own web-sites. Or worse, they'll pepper their pages with flash for the layout framework. Last time I checked, flash wasn't a part of CSS, or ANY universal web standard.




CSS has certain advantages within content displays and web-pages, and its advantages make it (imo) well worth the time invested to learn, and use it. But CSS for full page-layout simply doesn't work.




Because it takes us backwards, to the days when software had to be written for the limitations of one specific hardware-platform, it is quite frankly, a purely make-believe concept (at this time). While those who promote CSS-P will never admit that, just have a look at what they're doing for the REAL (mission critical/productive) parts of their own web-sites (or their client's/boss's sites).

The truth will set you free.






. . . . . . .
Resources

• CSS should not be used for layout Very telling statement from the article: "The reason that the order matters is that this layout, like all multi-column CSS layouts, is achieved with floats, and the way that floats get rendered depends on the order in which they appear. So we have not managed to separate content from presentation."
• CSS and DIV layout: The main pitfalls This is actually a discussion of pitfalls you should watch for if you do want to use CSS-layout.
• Ten reasons why CSS sucks A slightly edgier treatment, for those who like a little spice with their analysis.

It is always helpful to read considered arguments on the other side of a given position:

• Why tables for layout is stupid A fairly typical example of what passes for reasoned responses presented by those on the other side of this issue. You will learn a lot if you click on the logo in the top left corner to get to this company's "real" pages. Once there "view source". Notice how their pages that actually interact with the real world use... you guessed it! A rational mix of CSS and table layout.