Content defined by layout

The topic under discussion

How content can constrain layout

Since 1995/6, many web pages have had their overall layout controlled by the use of tables. Blocks of content that a designer thinks should be side-by-side have become the cells in a single row of a table. Blocks of content that the designer thinks should be vertically aligned have become equivalent cells in different rows of a table. Visual browsers typically render tables as rectilinear arrays, as they are recommended to.

Some people claim that this is wrong because it is inflexible. They say that if the layout were controlled by CSS (often called "CSS positioning") then dramatic changes to the layout of all pages could be achieved simply by changing the CSS. They claim that it wouldn't be necessary to change the pages themselves.

In fact, the layout of those pages is often constrained by much of the the content already developed for them. Often the layout changes that can be achieved just by changing the CSS are limited.

What this discussion is not about

This discussion is not about "CSS versus no-CSS". There is no doubt that making extensive use of CSS enables significant changes to be made to all relevant pages. This particular page uses CSS for both layout and other styling, and has very few presentation attributes in the HTML, which is valid 4.01?Strict. It just specifies images sizes, which is normal practice.

The example: the "3 column layout"

Consider a typical 5-box 3-column page, for example as used by news sites the world over.

There will typically be 5 boxes, each containing plenty of material. First, there will a banner across the top. Then there will be 3 columns down from the banner. Often these will be a left-bar, then an article, and then a right-bar. Finally there will be an administration box (footer) across the bottom, just below the longest column.

Obviously, details will differ within these 5 boxes. Some of the detail, especially in the banner across the top, may be achieved by the sort of "micro-formatting" that is not part of this discussion.

2 column versions of this basic theme are even more common across the web. Much of what is said below applies to them too. This current page is an example, and some of its content has been developed to fit the chosen layout.

5 box 3 column page format with sample content.

The design & development of such pages

It is typically obvious that pages using this 5-box, 3-column display were intended to be that way from the start. The contents of each of the 5 boxes will have been designed and developed for its chosen box.

  • If, for example, a search box is to go into the left-bar or right-bar, the input space will typically be small so that the input form will fit into the assigned width. But if it is to go into the banner at the top it is likely to be longer. It will rarely if ever go into the footer at the bottom.
  • Photographs & images (& flash) intended for the left-bar and right-bar will tend to have limited width, often just about what the CSS (if any) assigns for the width. (Sometimes such images are quite tall). Photographs & images intended for the banner may well be much wider. (Images in the footer, if there are any, tend to be icons & buttons). (The images in the sidebar of this page were developed for the chosen width of this sidebar. The width of the sidebar cannot be changed just by changing the CSS. Neither can it easily be converted to a horizontal site-navigation block).
  • Link-texts in the left-bar and right-bar are likely to have short, snappy, lengths, to appear as buttons. Contents of a particular side column are often of a similar width, and often not within the control of the CSS. They were often predetermined by the details of the content long before. It is typically obvious that the left-bar and the right-bar have been dictated to have a fixed, relatively narrow, width. (That applies to the link-text in the sidebar of this page. The "button text" was decided-upon to fit within a certain width).
  • Links in flexible content in the centre column are more likely to be longer. Quote-boxes, often floated to the right in articles, are far more likely to be in the centre column than in either the left-bar or the right-bar. (That applies to this page).
  • Often there is replication from one page to another of (say) the left-bar content. It is obvious that this replicated content was not intended to have centre place. (That also applies to this page). The contents of the footer are pretty predictable, and often standardised from one page to another.

The entire design & development process for such a page, and indeed for much of such a web site, has typically been based on the assumption that this will be a 5-box, 3-column display, with particular widths, at least for the sidebars, and often for all boxes.

The tableless version

The technique for making the content suitable for tableless 3-column rendering is fairly standard:

  • Put all the material that is to be seen in the banner across the screen at the top together in the document. Then surround it with (say)
mark-up.
  • Do the same with administration information to be seen in the footer at the bottom. So perhaps use
    • mark-up.
  • And do something similar with the contents of each of the 3 columns in between. Perhaps surround their content with, respectively,
    • , , and . Often, it is necessary to surround the set of columns with another .
  • Then use CSS to position and style those 5 boxes. Perhaps float the sidebars left and right. Or use "absolute positioning" for them. Probably the left-bar will be fixed width, and ditto the right-bar. But the main-content may be fixed width or variable width, depending on how flexible the width of the overall content is.

    • The development of the content will be on that assumption. The proximity of the content, and the tags used in the mark-up (at least the extra

    s), will be based on this design. It may be possible to deduce just from the mark-up of the document that it is a 5-box 3-column format, and even deduce the chosen widths of the sidebars!

    Summing up

    Two routes to the same destination

    It sometimes appears that the owners & overall designers of a web site have a grid-oriented vision, and then authors who favour CSS positioning deliberately avoid the use of tables in the mark-up, and instead choose to try to achieve exactly the same effect without using tables!

    Either way, the original design intention was based on a 5-box 3-column display. The content of each of the boxes was developed from the start on that basis. The mark-up needed a 2-level nesting (at least), for "box" then "item within box". This may be

    (or

    or

    ) within
    , or within . The mark-up can remain clean apart from this artificial structure.

    Differences

    With a table-oriented approach, the mark-up provides some key features of the final layout. It expresses certain design commitments for the page. With a tableless approach, the CSS has to compensate for lack of this assistance. The lack of maturity in the tableless approach and in browser support for CSS means that the tableless approach is harder to implement and often needs browser hacks.

    Is either approach the "proper" long-term approach? There feels something wrong with both methods! Neither of them conveys the "meta data" that the originators of the material know and that a UA may be able to exploit.