The term du jour circa 2003, liquid layout, appears to have replaced with the term responsive design (2014) which, as we see it, is liquid design with a media query. Good to see the world is moving forward.
Well, it's not exactly crossing the Rubicon. But it was a great feeling. We had an relatively easy time converting our pages because we were able to avoid the most critical problems that many designers encounter since we are not a pixel-perfect site (though in 2004 we did a 5 layer, pixel perfect, CSS liquid layout). We've provided some notes to remind us what we had to do. If you find them useful - even as a 'what not to do guide' - then read on.
The pages work and work well. But..
As of April 2003 we started to migrate the site to our CSS controlled (a.k.a 'table-less') layouts. We have a resonable migration scheme (with some overheads) so we can take our time. The benefits are too great - at least on our site.
Our decision to include NS 4.x also caused some problems - but surprisingly few once we made one draconian decision!
We created five NEW styles to layout the three central columns, the banner and the footer, we called these l-c, (center pane) l-f, (footer pane) l-l, (left hand menu pane) l-r (right hand menu pane) and l-b (banner pane) which was initially just an empty placeholder. Pages a defined to render in strict order: l-b is first followed by l-c, l-l, l-r (but only for some browsers) and finally l-f.
We decided to leave our top logo plus navigation bar as a table. It's really not significant at this stage (slapping it in a empty 'div' would have done absolutely nothing - though it proved to be essential when we moved to CSS pop-up, drop-down menus). Whether that disqualifies this as a table-less design is in our view moot. 2013 Update: Conversion to div (table-less) format in l-b circa 2004 for CSS pop-ups.
We used the glish.com 3 column layout as a starting point (which is both very simple and very effective), ripped out our three central layout tables replacing them with simple divs and clicked the refresh button!
Left Hand Menu:
.l-l {
position:absolute;
top:60px;
left:6px;
width:110px;
z-index:1;
}
Absolutely positions the left hand menu. This is a global definition and works for every browser in our list including hoary old Netscape 4.x. NOTE: The NS 4.x infamous 'width' limitation is only inside 'tables' and since we are 'table-less' we have no problems. Ah! to be on the side of the angels for a change!
We had previously changed all our left/right hand menus from tables into 'div's as part of our revised use of CSS so we now have nested 'divs'. However since not all our pages have been changed to the new layout this is necessary to allow for continued use of the current styles/layout. When the site is fully converted we only have to change a very small number of files (we use Apache SSI's) to remove this nested definition and in the meantime it is harmless on all tested browsers.
Finally those still awake may have spotted that our normal left hand menu 'div class="n-l"' uses an attribute of 'fixed'. When we tried 'fixed' in both nested 'divs' ('l-l' and 'n-l') MSIE did not like it at all (very bizarre results) but all the browsers that support 'fixed' (Opera/Gecko) use the second (nested) definition to give a 'fixed' attribute. We also have a minor casualty in that the hover effect 'div.n-l a:hover {color:black;}' was lost by Opera in nested divs. Sigh.
2013 Update: We still use fixed size fonts (10px, 12px and so on) in this div rather tham the em strategy of the central pane due to the strict width limits. We see no alternative.
Center Pane:
.l-c {
margin:0 160px 0 125px;
padding:4px;
font:10pt Verdana,Helvetica, Arial sans-serif;
border-width:0 1px;
border-style:solid;
border-color:silver;
[width:100%;]
}
This is a normal 'in-line' element - position:relative is the default. The margin definition controls the variable page width by fixing the left and right hand margins (they are subsequently overlaid with the l-l and l-r divs) leaving anything else for the central pane. This 'div' is browser-specific. Some browsers need the 'width:100%;' and some choke on it.
The page actually worked perfectly well without the 'width:100%;' until we came to resize in Netscape 4.x when all kinds of bizarre things happened. Adding the 'width:100%;' attribute fixed NS 4.x. Then we re-ran the tests and MSIE took 100% literally! So add for Netscape, leave it out for MSIE and don't care for Opera and Gecko.
2013 Update: In 2007 we changed our font strategy to use em units to make it easier for accessibility users. The font definition in the div is now 1.0em (and we also added a line-height:1.3em to open up the text). All class definitions used in the l-c div define their fonts relative to this base, thus, 120%, 80% and so on. The net result is that if the user has modified their style sheet to use a larger font type we do not override this change by using explicit font sizes. The negative consequences, which are not a problem on our site, is that the site owner has much less control over the look and feel of their site. This is offset by the greater control exercised by the site's users, which can only be positive.
Top Banner:
In the first phase of conversion we left this as a table and let the 'l-c' div flow normally (postion:relative is the default) under this table. When we moved to CSS menus we had to place the banner in a position:relative div for Gecko and Opera browsers only (the only ones that support CSS menus) as shown below:
.l-b {
height:45px;
padding:5px 5px 0 5%;
}
Essentially the div just positions the logo image inside the page and provides a bit of space. We left the MSIE implementation as a table because we we could not get the javascript positioning to work with pop-ups when using the div. So we have natural flow from 'l-b' through 'l-c' to 'l-f' with the two side menus being absolutely positioned. Worked great except we noticed that our CSS pop-ups did not pop-over the right menu div. To fix this we needed to give the 'l-b' div a higher z-index which in turns means that the div must be absolutely positioned (z-index only works with position:absolute). So we modified 'l-b' as shown:
.l-b {
height:45px;
padding:5px 5px 0 5%;
position:absolute;
left:0;
top:0;
z-index:9;
}
This works well for Gecko but not Opera which seems not to like the fact that the google adds are placed last and continues to place the pop-ups under them. One day life will be perfect. But it also had the unfortunate effect of sliding the 'in-line' 'l-c' div up under the banner! So 'l-c' was modified as shown here:
.l-c {
margin:45px 160px 0 125px;
padding:4px;
font:10pt Verdana,Helvetica, Arial sans-serif;
border-width:0 1px;
border-style:solid;
border-color:#336;
[width:100%;]
}
Addition of the top margin (45px) clears the banner header and means this div continues to be 'in-line' and importantly the following 'l-f' (footer) div flows to the bottom of the page as normal.
Right Hand Menu:
.l-r {
position:absolute;
top:60px;
right:6px;
width:150px;
[visibility:hide;]
z-index:2;
}
There are always casualties. This style absolutely positions the right hand menu with the 'right' attribute. This is a browser specific definition. Unlike the 'width' attribute Netscape 4.x does not have a buggy implementation of 'right' - it DOES NOT HAVE ONE. We're talking a serious NONE.
We experimented briefly with 'left:92%;' etc. but it was just too messy and not accurate enough. We made a decision to start de-committing NS 4.x support from the site in late 2002. Sensible display but no new work. The quickest way out was to leave everything untouched and use 'visibility:hide;' to make the right hand menu invisible in our browser specific style sheet for NS 4.x. The right hand menu is there for everyone else except NS 4.x users. End of an era. Sad really.
2013 Update: In 2002/3 Netscape was one of, effectively, only three browsers (MSIE, Moz/Gecko, NS). Our default handling for browsers not in our core group - including those using cloaked Browser IDs - now uses the old netscape styling.
Footer:
div.l-f table{
width:100%;
padding:4px;
}
.l-f {
margin:0 160px 0 125px;
}
.l-100 {
width:100%;
margin:0;
}
<!-- HTML footer fragment -->
<div class="l-f">
<div class="l-100">
<!-- footer table with no width - see selector -->
</div>
</div>
These two crummy footer lines took the longest time - ain't that always the case. We had a footer which stretched 90% of the page and was nicely (well in our view) spread out in three columns.
We started by wrapping our normal footer table in a null 'div' (border:0;). Worked perfectly except for short pages, when one or other of the left or right hand menus sat on top of it. We found a couple of articles that suggested that use of 'clear:both' in the footer div would place the footer below the longest absolutely positioned menu - we could not get this to work so we clearly have something that fights this fix - but we have no idea what it is.
The obvious solution is to place the footer inside the central pane. But to keep the 'stretched out' look that we cherish (!!) there is a width="90% attribute and MSIE does nasty things with width inside a 'div' - it just blew the central pane to bits (kept wanting to write a whole screen width). Take out the width and we get the table 'scrunched' up in the middle of the page. So after hitting the web (seems almost nobody is using complex footers in 'table-less' designs) and a lot of experimentation we ended up with a nested 'div' solution and relative positioning - flows from the end of the 'l-c' div (both 'l-l' and 'l-r' menu divs are absolutely postioned). In spite of all this work NS 4.x still 'scrunched-up' the footer. Sigh.
