This article was prompted by the growing crop of CSS “tips and tricks” articles that have surfaced in the last two years. Typical of these are the three column design making use of left and right fixed columns hanging on their margins; and the use of @import, instead of JavaScript, to feed appropriate style sheets to differently enabled browsers.
These ideas are very cool and their authors should rightly be heaped with praise, but I can’t help feeling we’ve been here before.
Remember when you figured out how to make a table of images display without the gap? Or how about when you worked out the browser’s table rendering algorithm and started using “educator” rows to guarantee correct display? Even more sinful, do you remember discovering those “hidden” (non-standard) attributes like marginwidth?
As web designers, we are naturally drawn to tricks, gimmicks, and workarounds. We need to keep our attention on what we are trying to achieve in long run.
Real world problems#section2
- I want my designers to use CSS. I don’t want them to hide behind WYSIWYG applications, I want them to truly understand what they are doing.
- I want universal, flexible layouts. Ideally, a line of text should be as long as certain number of characters, not some arbitrary pixel measure. I want my designers to create grids that are both intelligent and beautiful. I want my client’s information to be as useful on a 160×160 PDA screen as it is on a 1024×768 PC monitor.
- I need the team to spend less time on CSS hacking and more time on direct design implementation.
- I need flexibility in grid design. If the concept suggests a six-column grid, then I get a six-column grid. Ditto if it needs to be an eight column section on top of a four column section.
Setting practical restrictions#section3
In searching for the most practical grid-building technique, I’ve imposed some restrictions on myself. These are to do with defining the practicality of the solution for my chosen environment (the design studio) and the people who will use and develop these techniques (Dreamweaver-loving designers).
- Some browsers understand the
@importdirective but not the box model (iCab in particular is a fantastic browser in all but CSS2) so ideally,@importhacks shouldn’t be used. - If there must be filtering to alternate style sheets (often unavoidable) then they should be as similar to each other in structure as possible. In particular, if properties are applied to IDs then the same ID selector should appear in all the alternate style sheets to make changing/developing the grid easier for designers.
- Again in the interest of designer-friendliness, every box in the grid should be explicitly named, to allow the applying of typographical or border effects without having to add a selector.
Possible solutions#section4
I’d like to suggest a couple of design methods that go a little way toward satisfying the requirements listed above. Think of these as a bridge to that point two years from now when all designers are trained to think natively in CSS.
For starters, here is how a designer describes a three part multi column layout:
content stuff herecontent stuff herecontent stuff herecontent stuff herecontent stuff herecontent stuff here
In the designer’s head, he has just created the XHTML structure for a one-column top (news introduction?) and a four-column (main stories?) bottom section with a one-column footer. He wants the middle and bottom sections to happily float up and down the page in response to the user’s font size selection without any sections overlapping.
Simple enough, really; now why must he go any further?
He should be able to add any number of columns without the page falling apart and without having to go through serious brainy positional coding.
Another thing—it makes sense to write your DIV structure in the order that you intend the reader to read it, not some back-to-front thing to accommodate a weird backwards-compatibility glitch. The idea is to make creating structured layout as simple as possible.
Absolute v. relative positioning#section5
As far as I can tell, there are two ways to do this. Both make use of the basic “absolute” and “relative” positioning attributes. Where a lot of people get this wrong is that the CSS Box Model defines a position:absolute block as absolute relative to its containing block, and not relative to the page or window.
In our example, this means that a set of four absolutely positioned DIVs can line up inside a container DIV defined as relative, and still float up and down on the page in response to font-size changes — all the while retaining their position in relation to each other. Not only that, the layout holds together regardless of the number of columns.
In theory, we’re done. As ever in web design there has to be a bug and some hacking in response. I outline two methods to implement this grid below. Neither is perfect. One uses JavaScript to manually force a parent DIV to inherit its child’s properties (more later); the other has the simplest possible CSS definition, but requires a sniff to send IE5/Mac a different style sheet.
Method 1: CSS only#section6
Our first method is pure CSS and assumes that the designer or site editor has planned an element of copyfitting into the layout. In practical terms, this might mean knowing that the “Blog” section in the middle of the page is always going to be longer than the nav on the left — not an unreasonable request, in my book.
Here are the main containers defined:
#top-section {
position:relative;
left:0;
top:0;
}
#mid-section {
position:relative;
left:0;
top:0;
}
#bottom-section {
position:relative;
left:0;
top:0;
}
Nothing unusual at this point, except those of you who are familiar with the absolute/relative property will have worked out that these containers will not expand when filled with absolute DIVs.
For these sections to expand — for “mid-col-1” to start just beneath “top-col-1” and above “bottom-col-1” — the three container DIVs must either contain relative DIVs or their height must be calculated and applied by hand.
In this method, the design says that the largest column in the middle section is “mid-col-2” so we set mid-col-1,3 and 4 to absolute, and mid-col-2 to relative. Top and bottom sections contain one relative DIV each, so no problem there. This is what the style sheet looks like:
#top-col-1 {
position:relative;
padding-left:20%;
padding-right:10px;
}
#mid-col-1 {
position:absolute;
top:0;
left:0;
width:20%;
}
#mid-col-2 {
position:relative;
top:0;
left:20%;
width:40%;
}
#mid-col-3 {
position:absolute;
top:0;
left:60%;
width:20%;
}
#mid-col-4 {
position:absolute;
top:0;
left:80%;
width:20%;
}
#bottom-col-1 {
position:relative;
padding-left:20%;
padding-right:10px;
}
This works well in most standards compliant browsers, but not in IE5 Macintosh Edition, which is the browser I use every day.
The bug has something to do with the calculation of width percentages in a relative container. If you set mid-col-2 to “absolute,” the problem goes away.
Method 2: Passing the height of an absolute DIV to its relative parent#section7
If you choose to go with all columns set to absolute, now you have the problem of “bottom-section” overwriting “mid-section”.
The workaround I am currently playing with involves a small script. (It is currently on the clunky side, so for now I’m using the CSS-only method above.) The trick is to use the onload event handler in the <body> tag to trigger a little script that reads the height of “mid-col-2” and passes it to “mid-section.” This forces “bottom-section” to start further down the page where it’s supposed to.
The following scripting is bare minimum. (It would be more elegant to have a script that walks the document’s DOM tree, applying itself to every container of a certain type. In this way you might pass the height of the longest column instead of arbitrarily passing only “mid-col-2” and you could perform the transfer to any number of relative container DIVs.) If a clever JavaScripter wants to finish the job, I’d be obliged. In the mean time, here’s the little hack:
function inherit(objidParent,objidChild,objidGrandchild) {
if (document.layers) {
alert('sorry, no pretty layouts for netscape 4');
}
else if (document.getElementById) {
Parent = document.getElementById(objidParent);
Child = document.getElementById(objidChild);
Grandchild = document.getElementById(objidGrandchild);Parent.style.height = Child.offsetHeight + 'px';
Grandchild.style.display = 'block';return true
}
}
With this method, “bottom-section” is at first invisible to prevent slower machines from displaying the overlapping DIVs:
#bottom-section {
position:relative;
left:0;
top:0;
display:none;
}
After assigning the height of the child to the parent, the script sets the display attribute to “block” — completing the layout.
You could further refine this by calling the script every time you run
“styleswitcher” to keep the footer from losing its position on application of the new style sheet.
Moving on#section8
I wanted to achieve a grid system that would let my designers move more quickly and so produce fresher work. Ultimately, the only purpose of a grid system is to be broken. As we come up with these web design ideas, we tend to copy each other and everything tends to look the same. This is my main problem with Flash: the typographic animation routines are so cool, everybody uses them.
You can see a functioning example of this grid system on my web log donkeyontheedge.com, and yes, I guess it does sort of look like everybody else’s.
Good article, but one nitpick: id=”top-section”, isn’t that a style hint embedded into the HTML code? I thought we were trying to get away from that sort of thing.
This article would have greatly benefitted from a picture showing what the final product is supposed to look like.
I don’t like the Javascript hack at all. Javascript shouldn’t be used for anything more than enhancements; requiring it to make a page display properly is a big mistake. Too many users surf with Javascript turned off for us to rely on it so heavily. Designers must make sure that their design will display reasonably without the execution of any Javascript code.
The first example, however, looks very nice, provided it works in practice 😉
Greg you’re right. I think getting a designer to use CSS over tables and font tags is on major hurdle. Using id=”top-section” is like a trainning wheel, the designer can visualize what/where top-section will be. Once they get more accustom to CSS they can start using nonstyle hinted tags. Then again, what makes a good id/class name? Should random characters be used i.e id=”abcxyz” ?
I think a good ID/class name should tell what the object contains. i.e.:
The article ends with a link to a working example:
http://www.donkeyontheedge.com/ala.html
Better than a picture.
Slime http://www.alistapart.com/stories/flexiblelayouts/discuss/#ala-1301 wrote:
>This article would have greatly benefitted from a picture showing what the final product is supposed to look like.
The article ends with a link to a working example:
http://www.donkeyontheedge.com/ala.html
Better than a picture.
Slime http://www.alistapart.com/stories/flexiblelayouts/discuss/#ala-1301 wrote:
>This article would have greatly benefitted from a picture showing what the final product is supposed to look like.
The pure CSS (ie the best one 😉 ) suffers from a slight problem in that the position of the footer is reliant on the size of the middle 2nd column alone (since the other’s are absolute).
This means that if this is not the largest column then the footer will be placed too high in the document, and be over the other ‘absolute’ columns.
Not sure how to fix that. You could beef it up with br’s, which is an ugly solution. Or I suppose you could ‘floating’ the columns and ‘clearing’ the footer – but that negates the whole article. 🙂
I agree that id (or class) attribute names ought to reflect their content. More specifically they should add structural hints HTML isn’t capable of, like id=”nav_menu”.
if you visit http://www.donkeyontheedge.com/ala.html
and view source, you can see some good example of id names. and if you visiy with javascript turned off you will be treated to a view with no grid.
I would have thought there are better ways to achieve the same affect without absolute or relative positioning and certainly without unreliable javascript hacks. As people have already mentioned here, around 12% of users have JS disabled, so why would anyone want to create a site that depended upon JS to display it properly!
IMHO, a much better way would be the following:
#top {
margin:10px;
}
#colone {
float:left;
display:inline;
margin-left:5px;
width:30%;
}
#coltwo {
float:left;
display:inline;
margin-left:5px;
width:30%;
}
#colthree {
float:left;
display:inline;
margin-left:5px;
width:30%;
}
#footer {
margin-top:30px;
padding:10px;
clear:both;
}
That gives a header and footer that can be any height, and of course 3 columns, the footer is not dependant on any one column for its proper display. I only tested it on a PC including Opera6 and Moz/NN6/7 and I assume it should be fine on a MAC too (*I hope!*).
The only issue is that the third column will collaspe when you move your browser in to around 400px wide, but I don’t see that as a major problem.
>>Typical of these are the three column design making use of left and right fixed columns hanging on their margins; and the use of @import, instead of JavaScript, to feed appropriate style sheets to differently enabled browsers.
Why those are “tricks” but your js method and absolute positioning is not, I don’t understand. They are both ways to do a layout.
@import inside a link is vastly preferable to js to load stylesheets. Why absolute positioning is inherently better than margins, I have no idea. -If it works better, great, but nothing inherently better about it.
Also, a better way to achieve your particular goal would be to have a basic layout using a linked stylesheet, then dynamically load an advanced stylsheet and your js for advanced browsers using createElement, etc.
One of ALA’s most popular CSS articles was titled “Practical CSS Layout *TIPS, TRICKS* & Techniques:”
http://www.alistapart.com/stories/practicalcss/
Dug’s references to “tips, tricks, and gimmicks” were introduced in the editing process as we tightened the article prior to publication. Nothing derogatory was intended toward other means of creating CSS layouts — such as the use of float and @import — which have often been covered in ALA and will continue to be.
Each approach has advantages and disadvantages.
We’ve often discussed @import and float in these pages. We’d never presented an article exploring absolute and relative positioning. Dug’s piece gave us the chance to do that.
Finally, someone writes an article addressing the problems of using absolute positioning on pages which require footers!
Everybody is *always* talking about how great absolute positioning is, but no one ever wants to admit that most professional sites these days require footers with legal information, which make absolutely positioned divs an unreasonable proposition in most cases.
I think it is pretty unbelievable that with how great CSS1 and CSS2 are supposed to be, no one built in the ability to keep absolutely positioned div somewhat within the document flow. For instance, if you have 3 columns (divs) all absolutely positioned within a container div, you should be able to insert a footer div after your container div in the code and have the browser render the footer div at the bottom of the longest of the three columns. It is simply ridiculous that this cannot be done.
The javascript solution is a good one for now because it’s really all we have… if we want to use absolutely positioned divs. I do disagree with the author’s statement that “having the second column always be the longest is a reasonable request” though. We’re not just talking about blogs here. I couldn’t imagine submitting site templates to a client and telling them that they *have* to always make sure there’s always more content in the second column than the rest. The best solution, as the author states, is to figure out which div is the longest (using the DOM) and apply the footer div using that length.
Someone had also mentioned that they think creating columns with floats is a way better solution. While it’s easier to insert a footer if you just use floats, using floats presents a whole new set of problems, hacks, and workarounds. Floats, except very simple ones, do not act reliably across browsers, and if you put a lot of content in a floating div, often times it will get cropped in some flavors of IE.
I for one would love to see a *sensible* solution in CSS-3 for arranging block elements horizontally. The problems with this absolute-positioning technique (the struggle with ‘clearing’ elements that follow it) have been gone over in depth; and it feels to me that alternative float solution, effective though it can be, is just as much an abuse of a layout technique never intended for it as the dreaded table layout.
Furthermore, I think people’s objections to table layouts aren’t to do with the table algorithm itself (which is to my mind an extremely effective and robust solution to grid layouts – far more so than these float- or positioning-based techniques) but simply to do with semantics: using the word ‘table’ to describe what obviously is not a table. So, why not ditch the semantics and experiment with combining the CSS display table properties with div elements?
Consider this: a table layout is the only one in which the elements are aware of each other’s position and size and scale accordingly. Floats aren’t, except inasmuch as they have a nasty tendency to climb over each other at narrow widths. Absolute positioned columns aren’t, and often have insurmountable overlapping problems because of it. Sometimes we need layout blocks that are aware of their surroundings. This is one of those times.
Float and positioned techniques work great for plenty of situations and have their unique and powerful advantages. But so do tables, and it’s for grid layouts exactly like this that the table algorithm *shines*. So why not call it by another name and use its strengths, instead of going through all this unreliable hackwork just so you can feel proud you didn’t use the word ‘table’?
Also, I should note that earlier versions of Opera (less than 7) don’t allow the ‘display’ property to be changed with scripting. So using the js workaround for the absolute-positioning layout means that earlier Operas will never show the bottom region at all. Better to use visibility: hidden, which those versions of Opera do allow to be toggled.
When I use NN6.2.3 to tab through Dugs site, I can only tab through the links in the relative divs. I cannot use the keyboard to tab through the absolute position divs. Similarily, I can only tab through the menu at alistapart.com – I cannot tab through the float divs which contain the articles!! Somebody will come up with a hack for these problems one day.
My point is that we will have to continue to deliver hacks until the browser suppliers deliver to us what Dug *requested* in his article.
If we look back we can see how far we have come. CSS has delivered us the opportunity to separate presentation from content which is why I do not agree with Alun when he suggests using tables for layout. Thats a step back. That would be a nightmare from an accessibility pov although I would be able to tab through all the links on a webpage. Remember those days when you had to meticously define cells in tables. Suppliers have delivered us CSS warts and all and someday they will deliver what we want. Dug has offered us another hack until that day and should be encouraged. Thank You Dug.
Personally, I don’t like JS but its the best hack so far. At the same time, I don’t think its too foolish to assume that a sites content column should be longer than its navigation columns, thereby pushing down the footer. Afterall, If a client doesn’t want JS this is the only solution for now.
Lets look forward to the day we won’t have hacks. For now the most I can look forward to is somebody like Dug coming up with a tabbing hack until the suppliers come out with a newer better browser.
What about server-side browser detection to serve alternate stylesheets such as:
http://www.alistapart.com/stories/phpswitch/
or
http://www.zopelabs.com/cookbook/990728167
Is part of the aesthetic to have everything happen “on the page?” Could part of the aesthetic be to serve the entire page – as it should be – and have it work in all browsers or devices – without any *visible* hacks?
Perhaps server side detection could be used to position the div’s properly as well.
I’m not suggesting a return to table semantics (table, tr, td); those are inappropriate to layout elements which are not tabular data. What I am suggesting is a reuse of the table layout *algorithm* (not tags), because the same things that make it great for rows and columns of tabular data also make it great for a grid of large content regions. As seen here.
If you could do the same thing with divs as you can with table elements (try applying display: table-row etc.), then you keep the same separation of style and content with the strengths of a gridded table layout solution. I don’t see any more accessibility problems than you’d face with an absolute-positioning or floated solution, especially since you could turn off the table arrangement with the flip of a stylesheet for platforms in which it was inappropriate. Which, I might note, would likely be the same platforms for which a 4-horizontal-column arrangement of positioned divs would also be inappropriate.
Table-style layout doesn’t *have* to be bloated and backward: when you stop using spacer cells and inline widths and nesting and cellpadding and the rest of the cheesy hacks we’ve been trying to get rid of for years and no longer need, then you’re be left with a simple, elegant arrangement of content regions: defining their position in relation to each other, not by an unreliable collection of margin/width/positional offset correlations.
Looking at the absolute-positioned layout described here I see codework no more or less meticulous or clean than would be needed to use a table-style layout. There’s container elements for column blocks of content, and elements containing those columns and defining (or attempting to define) their vertical positions as a set of rows. Sounds a lot like
It doesn’t seem to me to be in any way a step back to use a highly effective and robust positioning technique if it were divorced from the markup that makes it so unfashionable.
Well, the problem with server-side detection is that when you save the document, the saved document that is assumed to be “portable” is not, it stays browser-specific.
I am sure, at some point, I am wrong in my thinking, but I’ll ask the questions anyway.
When a saved document is said to be “portable,” should it also be considered that relative links from the saved page will not work? It may be portable, but the saved page is out of context from how it was meant to be delivered – via the web, by way of server, in a particular browser, at the moment whent he page was reqested.
How much should we ask the page to do itself?
Is the work of presenting the page finished at the moment it is finished loading? Does server side detection accomplish the task just as well.
Or is the issue how to best impress upon the makers of web browsing software the need to adhere to an agreed upon standard… does making hacks and workarounds actually not serve this cause.
If the page, at the time it is viewed, is presented in a way that adheres to a standard, is still functional to the user (but still uses browser specific markup), would this also make browser manufuacturers reconsider how they design their product?
If they knew that pages saved using their browser could only be viewed using their browser – and not easily shared across a company, or repurposed into other applications – would it force users of their browsers to ask them to change.
Is the use of hacks (within the page) counter-productive to the cause of promoting standards compliant, non-browser specific web pages?
“Someone had also mentioned that they think creating columns with floats is a way better solution. While it’s easier to insert a footer if you just use floats, using floats presents a whole new set of problems, hacks, and workarounds. Floats, except very simple ones, do not act reliably across browsers, and if you put a lot of content in a floating div, often times it will get cropped in some flavors of IE.”
http://www.xs4all.nl/~apple77/columns/
I am still working things out, so don’t pick on me. So far, it looks very consistent on all mainstream 5+ browsers – only Konqueror seemed to mess up the 5 and 4 column layouts (3 columns inside one). No hacks (except just the @import).
Oh yeah, another thing. Avoid DIV soup wherever possible. I know my examples don’t, but there is not much to markup either (yet).
Mike. I think half the problem is that neither absolute positioning or floated DIV are the proper way to achieve the layouts designers want. If you go the CSS2 specs ( http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-display ) you’ll see that there are more display types than just in-line or block. I’m wondering if these other types would let us create layouts without using float:x or position:absolute etc.
Unfortunately, not even Mozilla supports any of these, so I haven’t been able to play around with them.
I imagine the code might look like this:
#top {
display: block;
}
#leftNav {
display: run-in;
width: 20%;
}
#content {
display: run-in;
width: auto%;
}
#rightInfo {
display: run-in;
width: 200px%;
}
#footer {
display: block;
}
Of course, I’m not to sure what would happen if you put a whole lot of text in, the fact that it wraps. Quite a few times I’ve had a float layout that works OK, but then falls apart when you add content. It would be nice to have some options to control how wrapping in-line content within a block affects it’s width.
Then again, it maybe of no use all for layouts. W3C don’t always have the most clearest descriptions, leaving things to be interpreted 3 different ways.
—
Kris. Nice layouts, I’ve seen a few nice floated layouts lately that seem to work well, and even across a lot of browsers. But there is only one problem with all the layouts I’ve encountered; the order of the content quite often makes no sense. While that maybe OK on smaller sites, it’s a bit of a problem for those of us who work on large .gov sites that also need to meet accessibility guidelines. I realise that it’s possible to use hidden links etc to each section, but it still feels like too much of hack.
—
I’ve been working on a new layout for http://www.stats.govt.nz (yeah, site is horrible at the moment, the idea is to overhaul the whole thing). I’ve got 3 versions: A basic table layout, very clean, no nested stuff; a floated layout, having a few problems getting it to work on all browsers since it’s quite complex, and the content is out of order; and an absolute positioned one, that’s working OK so far except for the lack of footer.
At the moment, the table layout is by far the best. It’s code is leaner, it works in all browsers, it keeps the columns in sync which looks nice, the content is in the right order, there is no chance of content overlay (which has to be considered when designing a site in which you have not control over the content entered).
The only bad thing about the table layout so far, it doesn’t degrade fully, and it’s a hack, not the correct way to design a layout. The former being the biggest problem.
When are W3C going to take a few clues and give us something we really want? I understand what they are trying to do. But there are still big problems with CSS at the moment. It shouldn’t be this hard an complex to get a simple layout to work with no problems.
Oh well, the search for the holy grail continues I guess.
“But there is only one problem with all the layouts I’ve encountered; the order of the content quite often makes no sense.”
Justin. Content first. They definatly make sense (to me). I put them up with no regard to layout at all, just structure and order. There was one point though when I was forced to let the order be dictated by the intended layout; it resulted into one subcolumn (that can still contain something else than basic navigation) that neede be placed before the main content. This, to ensure I could still use floats.
Lateron I realized that it may also be worth examining other types of positioning a little better in order to structure content completely independant of any layout i have in mind. All goes well, just not perfect; but when is?
It also greatly depends on the type of content some elements contain what is logical to place upfront. My examples reveal very little content and are therefore also very hard to structure semantically, hence the divsoup. But that will change once i start working on better examples.
Even though I don’t really agree with the javascript hack (though I’ve been very tempted to do similar things myself), here’s the code to go through each node in the DOM:
function fixHeights() {
var divs = document.getElementsByTagName(‘div’);
for (i = 0; i < divs.length; i++) { if (divs[i].className == 'fixMe') { changeHeight(divs[i]); } } function changeHeight(div) { var child = div.firstChild; div.style.height = child.offsetHeight + 'px'; } I'm not exatly sure how your layout works, this requires that each absolute positioned div needs to have a content wrapper inside it if it has more than one child (unless you modified it to go though the siblings and get the largest height, which isn't to hard after I think about it). The div to fix need to have the class 'fixMe', and the 'fixHeights()' goes into the onload in the body tag. It should work on IE 5.5 and NN6.2., although, I haven't tested it.
Alun David Bestor: Yes! I must have missed your post before. I totally agree. The way tables work are great for layouts. It’s fact that they were never designed to do it which is the problem. I’ve also thought about all the table types for the display properties, they seem like the best hack at the moment IMHO. But I thought they weren’t supported in any browser, like the rest of the display types other than block and in-line?
Yes, hacking is bad, and i’m willing to simplify design to some extent… but simplification can be taken too far.
speaking of which, here’s a hack that will solve the problem of having to use javascript to sniff for ie 5. it will allow you to deliver different stylesheets or just different classes/ids to ie 5 mac.
http://www.sam-i-am.com/testsuite/css/mac_ie5_hack.html
Instead of using the JS hack, is it possible to detect the USER-AGENT via SSI, PHP, or VBscript? Could we not route a separate stylesheet to IE5 Mac (or other non-compliant browsers)? I’ve been looking, and haven’t found a good “table of user-agent-detection” scripts for SSI. Any thoughts here?
There was an article posted on macromedia.com that discussed how they did this exact thing, different style-sheets for different browsers.
This seems much more elegant than a JS hack, especially because the browser will only get the code it needs. Thoughts?
I believe another argument against the server side method (besides the prior stated ‘portable document’ reason) would be file maintenance. If one wanted to make various media style sheets, they would need to make n x the number of files (n being number of different browsers). Same idea for having site ‘skins’ like AlltheWeb.com has. One would need to make a multiple versions of each file thereby increasing workload.
I did a bit of playing around with display: table-row and display: table-cell last night. Go to http://www.washboardabs.net/examples/layouttest.html to see an example in action, using content culled from my own site and Dug’s.
The good news: They’re great for grouping divs into robust synchronised columns in Mozilla and Opera 7. The bad news: IE as of version 6 doesn’t support them, so we file it under interesting style exercises for another 3 years.
An interesting note: the test document uses alternate stylesheets, one with a float layout and one with a display: table-cell layout. Neither is set as preferred. The table-cell layout comes first in the source and is the default for Mozilla/Opera. But the float layout ends up being the default for IE6, and since it doesn’t have a builtin switcher menu it never sees the table layout it can’t handle. Hmmm… *rubs chin cunningly*
And let’s try that again, this time with the magic of http://…
http://www.washboardabs.net/examples/layouttest.html
http://www.donkeyontheedge.com/ala.html is quite a nice site to look at but it think 4 columns is perhaps a little too much. I’m not too sure how this sort of layout will be any good on a PDA as surely all the columns will not linearize and, in fact, overlap. Has anybody tested this layout on a PDA?
I’m also not too keen on nesting loads of DIVs as it reminds me of the old nesting tables method. But I suppose, for really complicated designs, you have no choice? I can’t change the text size from being tiny either!
Interesting article nevertheless.
Justin,
I usually find myself going back to a clean (no nesting) table layout because I know exactly how it’ll appear in just about every browser. I’d really like to use a pure CSS approach, but it’s quite difficult to get it to look exactly as I want. I’m not talking pixel perfect, but having the layout naturally flow as you would expect it to. When I do use tables, I still set colors and fonts with CSS.
I think, at least for myself, it’ll just take time to get used to CSS. It’s certainly more complex, but I’m looking forward to make my sites more accessible ’cause I’m visually-impaired and there are *tons* of sites that won’t let me do something as simple as changing the font size.
Well, if n is 50, then, yes, that’s a lot of work–but if it’s only one browser we’re talking about, and only a few lines, then it’s trivial. The ‘comment’ hack looks pretty doable, but oh how the hacks are stacking up (IE 5 Win, IE 5 mac, Opera “be nice to Opera” hack…)!
Does Opera 7 fix some of their bugs?
I would like to create a layout that is similar to ALA’s but I would like to keep the menu fixed, so it doesn’t disappear when you scroll down in the content. Is there any way to do this, with a strict DTD and a CSS or is it necessary to use an iframe?
I have recognized that the layout mentioned above isn’t very common these days? Is it only me that finds the disappearing menus irritating?
this stuff is such a headache that i want it all to go away. far away.
” I would like to create a layout that is similar to ALA’s but I would like to keep the menu fixed, so it doesn’t disappear when you scroll down in the content. Is there any way to do this, with a strict DTD and a CSS or is it necessary to use an iframe?”
#fooBarMenu {
position: fixed;
top: 10px;
right: 0;
width: 30%;
…
}
It’s behaves the same as position:absolute; except it says where it is when you scroll. Can’t quite remember which browsers support it.
Mozilla and Opera support fixed positioning great. IE (as of 6) doesn’t, and reverts to regular old static positioning rather than absolute which might have been useful degradation.
Most fixed solutions that don’t involve frames use javascript fired on scrolling events to continually set the menu position to appear on screen at all times.
Alun David Bestor: Sorry, I mis-read you post as suggesting a return to table tags. A CSS table layout *algorithm* is probably the best solution for a grid layout of the future.
It is also a valid point that the absolute positioning/float hacks are as meticutous as the table hacks of the past. The only advantage absolute positioning/float hacks offer over table hacks is *accessibility* in most cases.
However, I have a situation of a *totally* colour-blind person who wishes to tab through the links. The CSS markup is used to define the different links states e.g. bold for unvisited, normal for visited, border for focus. If I switch off the CSS he can tab through the links but he cannot differentiate between the link states.
The point I was making is that each hack is a step forward to the day we won’t have hacks. Keeping the same codework of hacks in a central repository like a stylesheet is better than having the hacks in with the content. I realise this is not always possble, but its something to strive for.
I wish you the best in offering us a table layout hack
Goodness, you go away for the week-end and Jeffrey publishes your little piece and then zap, hearty helpings of the best feedback in the world:-)
A chap called Janos Erdelyi sent me a script what must have been only a few minutes after publishing. Since then, he has re-worked it a couple of times:-) Thanks Janos.
I’ve put his script in a new version at http://www.donkeyontheedge.com/ala155.html
This page also has the stupid
manipulation removed. Some of you pointed out that the ‘inline’ definition caused the line of links to cross the whole page. In any case, the reason I was attempting the links this way was to get a useful nav display at the top of the page with javascript turned off or indeed in lynx (http://www.donkeyontheedge.com/i/lynx.gif). It now seems to work a wee bit better…
I share everyone’s frustration about the table tag (Alun, Chris) thing. How can browsers have this algorithm built in and yet not offer a hook to it through css? Of course, there are times when I want my columns to come one after the other, not side-by-side.
[nav] [importantcontent] [moreimportantcontent] [addenda] [footer]
becomes
[nav]
[importantcontent]
[more importantcontent]
[addenda]
[footer]
which for a Lynx user, works better. If there was a way to tell table tabs “most of the time I want you to behave like a table, but sometimes…” I’d be there. Hopefully, another couple of years and we’ll have a CSS device to do this. Of course at that point, we’ll still need to worry about degrading;-)
I’m surprised people haven’t picked up on Alun David Bestor’s comments. They hit me like a bolt of lightning.
His point: table layouts work well at laying out elements on a page. All these float techniques, positioning types and talk of grids are an attempt to reproduce the success of the table layout. So why not just use tables?
Well, we know the answer. They are semantically poor. The HTML table element has a specific purpose – the laying out of tabular data – and should be used for that purpose. We want to structure our information in rich, meaningful HTML – how it looks should be left to the CSS.
And this is his point: why not use the table rendering powers of CSS? In CSS2. *any* element can be defined to display as a table, a table row, a table cell. We can structure our information meaningfully, and render it visually with the robust and familiar table algorithm.
I just did this for a 3 column layout. It is here: http://home.freeuk.net/bigbrownbear/testing/3coltable.html
One limitation of the technique is that COLSPAN and ROWSPAN do not seem to be represented in CSS. This means that the header and footer need to be broken out of the table structure and positioned separately. If this weren’t necessary, I’d define BODY as the table element, and position everything within the grid.
I’d be interested in feedback on this approach. Am I wrong in thinking it is within the spirit of standards-compliance?
Oh – some feedback already: you say the page looks like junk.
Ah. You must be using Internet Explorer. Doh!
—
dr bruno
Oh – I didn’t see page 2 of the comments. Looks like everyone *is* talking about tables – and I look like a chump. Plus ça change…
all this talk about javascript hacks and using tables for layout seems a little silly. in time css will do everything we want it to. check this out
http://www.w3.org/TR/2001/WD-css3-multicol-20010118/
“…
I believe another argument against the server side method (besides the prior stated ‘portable document’ reason) would be file maintenance…”
I handle this by using conditional branching within the css file and setting a content-type header of text/css.
samp:
<%if(b.isIE6()){%>
top: 21px;
<%} else if ( b.isWin() && b.isIE55() ){%>
top: 20px;
<%} else if ( b.isWin() && b.isIE5() ){%>
top: 19px;
<%} else if ( b.isGecko() ){%>
-moz-user-select: none;
<%}%>
Eventually I’ll get around to replacing the <% %>‘s with custom tags, but for now it works. I have everything in one file. Works very well for me.
Well, don’t think we’ll be seeing that too soon (outside of Moz perhaps), but it’s great to have something to look forward to.
You MUST see this: http://iht.com/articles/77397.html
They accomplish VERY nice columns and reflowing with Javascript and CSS. Degrades nicely, too. Not sure how it acts in a standards-based browser without JS. A very cool way to show long articles, takes some getting used to reading, though.
Garrett: how are you passing the user-agent variables to the script? It looks like VBscript, I would likely be using PHP (similar approach). Is the variable being set elsewhere in the script, or as a global variable somewhere else?
I’ve been looking for a good table that shows how to detect all the various user agents, but can’t find one that covers everyone (like IE 5 mac for example; alistapart/phpswitch/ doesn’t cover them all I think). Can you give me any pointers? Thanks!
display: run-in, display: table-cell and all that kind of stuff are cool, but only a few browsers are able to render it correctly.
The “more portable” solution is to use the float property, as proposed by Peter. It avoids many of the problems raised by the Javascript or pure CSS solutions proposed by this story. But it also has its own problems, since IE has some bugs in float placement…
I’ve never understood why any *designers* would decide to use liquid layouts. In the same way that we make design decisions for our viewers on what colors the text and backgrounds will be, what (default, at least) fonts and sizes we’re offering, and what layouts we’re providing, why wouldn’t we want to decide what length of text to provide?
There is an ideal character length for text to be the most legible. Leaving this up to a % of the screen width totally removes our control of how legible our content is. Yes, we can hope the user knows enough to not size their browser too wide for the text to be easily readable, but aren’t those decisions *why* we are hired as designers?
I appreciate the need to discuss how to do multi-column liquid layout formats, but I’d like to also discuss why and when we should do liquid layout and when perhaps fixed layout would (not only be easier, but) be better.
Dave bug: A lot of layouts are more than one or two columns wide as we know. On lower resolutions, it’s still necessary to make things like sidebars narrow so everything else can fit on. A well-designed liquid layout will work around this problem.
I think you’re also forgetting that not all design elements follow the rule you’re talking about. Only large blocks of text. Even in the main content of a page, you still get elements that may need a lot of space, like graphs and tables.
CSS has properties like max-width and min-width. These would be very useful in making liquid layouts that don’t cause readability problems. E.G. “P {max-width:400px;}”. Unfortunately, I have only found these to work in Gecko based browsers.
I do understand where you’re comming from though. I know of a few CSS based sites that I have to re-size my browser if I want to read without going crazy. But then I’m wondering if this is a bad thing. And I think it is, only because you average user doesn’t know/understand.
I’m not trying to be condescending to the user but if there is justification for usability experts and designers (and the overlap) then it is due to the fact that users cannot, will not, or simply do not adjust their situation for optimal usability/legibility/comprehension.
I agree that there is *some* room for liquid design. Specifically (as you said) when you’re not dealing with a column of text. But I don’t think even max and min-widths satisfy the requirements for optimal textual column width.
Textual columns should change width (as well as leading) based on font size, if they change at all. If you have sidebar columns that don’t ever contain lines of text (which I think is a rarity in the blog/news/brochure site world) it *might* make sense to have them stretch. Though stretching the navigation or other content far away from the textual column’s content usually doesn’t make sense anyway.
Now, I do believe there is a place for liquid design in online applications, in the same way that I think offline applications should fill their space. I just don’t think 95% of the situations people are discussing liquid layouts deserve them. (I could get into *why* I think people continue to discuss liquid layouts, but that’s a tangent.)
Dave bug: I try to get my lines of text to wrap in the region of thirteen words (probably down to who trained me).
Aren’t the design decisions we make about fixed/liquid layout less about line length, and more about the fact that there is no standard user agent or no standard user platform or device?
Dave: One word (or is it 2?): white-space.
Your right in that a lot of sites won’t have wide elements in the content area. But a liquid layout still means you can increase the amount of white space around the content to make it more readable (and look better to).
I can think of a few other examples. Tabbed navigation across the top of a page is the main one I can think of. The text is usually bigger, has more padding, and generally you don’t want any text wrapping going on.
Another example are the headers for the posts in this forum. I think it they look much nicer and easier to read on one line, rather than wrapped.
Don’t forget, the only reason that it’s better to keep text blocks narrow, is that it means you don’t get confused as to where you are. With element that only contains a few lines, this isn’t so much of a problem.
Would having a id tag for EVERY tag be a good decision for layout rearrangement purposes?
Abraham,
Sounds like overkill to me, but I went through that phase too. If you design your site intelligently from the get-go then there’s no need for giving every character its special place in a .css file.
I used to give every paragraph a unique ID and put it in a
was just as good because I could specify how I wanted
to format the text.
A bonus is that your files will be much smaller than before.
Any page layout method which relies on Javascript is pointless since web user stats at sites such as http://www.thecounter.com/stats/ show consistently that 11% of users have Javascript disabled. As more and more security scares abound, like the recent IE/Outlook Express malicious URL exploit, the figure can only increase.
Gary,
I’d be curious to hear some feedback about this page: http://www.cognima.com/ with Javascript enabled/disabled (but with CSS turned on, of course).
Thanks
In regards to this quote from the article:
“Nothing unusual at this point, except those of you who are familiar with the absolute/relative property will have worked out that these containers will not expand when filled with absolute DIVs.”
That is totally incorrect! Relative elements DO expand to contain their absolute contents. I just ran a test, and Moz, IE, and Opera (in win) all do exactly that. Here is a demo page:
http://users.rraz.net/mc_on_the_rocks/testpage/abs.rel.test.html
Kinda blows away the point of the article.
In regards to this quote from the article:
“Nothing unusual at this point, except those of you who are familiar with the absolute/relative property will have worked out that these containers will not expand when filled with absolute DIVs.”
That is totally incorrect! Relative elements DO expand to contain their absolute contents. I just ran a test, and Moz, IE, and Opera (in win) all do exactly that. Here is a demo page:
http://users.rraz.net/mc_on_the_rocks/testpage/abs.rel.test.html
Kinda blows away the point of the article.
Unless I’m missing a stylesheet link in Big John’s example, those elements are neither absolutely nor relatively positioned: there’s no ‘position’ property for either of them.
I have attempted three times now to build sites for clients that use CSS positioning, and each time have had to retreat because the technology doesn’t stand up to the client’s expectations. We can jaw all that we like about having “fluid” design and not worrying about pixel-perfection, but as it turns out, that’s what clients want.
I was so incredibly excited at the prospect of working with CSS to lay out pages, and I have been so incredibly disappointed by the fact that (1) browser manufacturers randomly interpret standards but more importantly (2) the standard writers haven’t got a clue about how real web sites are built and maintained. The fact that you cannot say “I want this column to stretch from top to bottom, no matter the page length,” “I want a footer of yea height at the bottom,” or address any of a plethora of similar everyday layout needs is depressing. Almost as depressing as NS 4.7 was to anyone with a logical bent working with table layouts.
Some things in the CSS standards are inexplicable: who thinks padding is outside of the box? What’s the point of margin and padding if they largely do the same thing?
Nice article, but rather than get involved in a whole new world of hacks, I’ll have to keep working in tables for awhile, even if it means giving up some of the tremendous advantages of CSS such as z-index and far better background support. Not all of us have the luxury of building “blog”-style sites. My corporate and entertainment commercial sites all rely on pixel-perfect layout–and no amount of appealing to the client’s better side is going to change that. Another dream dashed.
The issue always seems to be placing content in a center row made of multiple columns with maybe a header row and a footer row. But what about complex designs with more than three rows? A piece of cake with tables, but we are at the preface of a new design era.
I challenged my self to this issue a couple months ago and found a solution that I am willing to accept. Yes, it too uses JavaScript, but you have to pick your battles. If 12% of the population has JavaScript disabled and you are concerned about that, what about the 10% of the male population that is color blind to the color red? Have you designed your page with that disability in mind? Feel free to see my examples and tutorial at http://www.spinwebdesign.com
Turning off JavaScript is a user preference and that is something you can somewhat control by instruction users that your site requires it. But how do you address color blindness? My rule of thumb is to code to the default installation of the browser. This means at an 800×600 resolution, most browsers allow you a 760×420 workable space because of the default tool bar layout, JavaScripts is enabled, cookies are accepted, etc… If the user is smart enough to alter the default settings, I hope they are smart enough understand the consequences. (Of course, the exception to this is the managed PC in a corporate environment where the end user may not control these settings.)
My solution addresses the box model hack (http://tantek.com/CSS/Examples/boxmodelhack.html) however, does not address the overlapping div problem Dug spoke about. I had though about fixing it, but have been to lazy to address it yet. My solution also addresses issues with column widths when mixing fixed and dynamic width’s together.
Hey, as designers we need to keep pushing the envelope in hopes that the browser makers will continue developing for standards. CSS3 can’t come soon enough for some of us, but it is probably coming way to fast for them.
T.J.
The variables in viewing a page are:
– the text font size can vary at the whim of the user – they might have a 300dpi screen or a 75dpi one, they might be partially sighted, whatever;
– the browser width might be 10000px or 100px – they might be on a wallscreen or on a PDA.
The only constant is that image sizes are a fixed pixel width.
All the CSS “I don’t need a table” column layouts here seem to miss the fact that the content of the columns plays an important part in determining the width.
If I used a table to lay out a page, then I can persuade it that
– a column must be at least the width of any image
– a column has to be big enough to display the text it contains – there’s a width below which the text runs into the next column, so it can’t be shorter than that
– a horizontal scrollbar will at some point be required if the columns are all at minimum width and still too wide to fit within the browser
– one or two columns should share out the ‘spare’ width available.
Setting pixel widths, percentage widths and so on just doesn’t cope with this. If your browser is narrow, the suggested layout in this article doesn’t work; if your font is large, ditto.
I think that our role as designers/developers should focus on making content accessible. While clients want pixel perfection it’s fairly easy to disuade them given some of the inherent problems with that goal.
First explain to the client that it is nearly impossible to get exact pixel perfection for every user agent. Part of this is due to how each user agent calculates screen width and margins. Another issue is that some user agents do not rely on the visual placement of elements on the screen (ie. screen readers, magnifiers, etc.). A pixel perfect site is lost to the visually impaired. And the last thing you want to do is make your site unusable to a large cross section of the population (visually impaired, elderly, physically impaired, mobile users, and those with older equipment)
Second explain to the client the cost and time involved to develop such a site. Money talks. The faster the site is up and online the faster they are making money off of it and the less money they are paying you to fidget with it.
Third, along with money talks, discuss on going maintenance and changes to the site as technology changes. Discuss how your design will be easier to migrate to a new technology because of how purposefully forward looking you’ve structured it. Compare how much it might cost for a pixel perfect site versus a more liquid site. These costs should include bandwidth, time to update content, etc.
Fourth only designers care about pixel perfection. The average user will hit a site with ONE user agent. They won’t hit a site with one and then return with another to see how far off the margins are. If the site is designed to look reasonably similar between the major browsers then 99.8% of the viewing audience will never notice. They might hit the site at home on IE/mac and then two days later hit the site from work with Mozilla – but 3 pixels difference one way or the other they won’t notice and won’t care should they notice. Their focus will be the content of the site – could they read it, was it usable. If it’s not legible and not usable they will go elsewhere (clients will not want users going elsewhere).
The main point I would make is that flash doesn’t work for everyone and tables are absolutely horrible to use both from a developer stand point and a user standpoint. Tables don’t reflow well for all screen sizes, they throw off most screen readers, most developers set them at fixed widths which cause the user to scroll if they have a smaller display, and they can slow down page rendering times and add unnecessarily to page bloat (especially when nested).
Clients and developers are going to try to say – well we’re really only targeting male users 18-35 with IE5+. And that’s great, target all you want. In reality the site will get hits from Grandma shopping for her 24 year old grandson, or some guys wife who shares the same interests he does, or some guy in Canada who has control of only a pinky finger, or this guy I worked with at my last job who had only a finger and a thumb on his right arm (and could handle customer service calls better than anyone in the call center). As soon as one of those people hits the site and it’s innaccessible to them, they’ll remember it and pass it along. Slowly that target audience will be dissuaded from visiting.
Using properly structured html to create usable accessible content and then style it with CSS is really the best way to go. If you have the ability to use server side parsing XML/XSLT/XHTML/CSS is a great way to go (I use that now) because it gives you some more flexibility before sending to a client.
P.S. Usability studies show that more than 75% of users prefer liquid layout to fixed. 20% +/- sites use liquid layouts. Line length in printed material has an optimal reading length for a fixed font (somewhere less than 4 inches). Line length on a screen does not follow the same rule. The longer a line length on the screen the faster a user can read it. Users prefer shorter lengths (4-5 inches) but as far as usability longer is better (8-10 inches).
I recently recreated a fairly complex intranet site using XHTML and CSS. The goal was to recreate it as closely as possible to the original fixed width table formatted and review the outcome. The outcome was that I had a site almost identical to the original, that reflowed properly as I resized the window or changed font sizes. The site also displayed almost identically in Opera/Moz/IE5+. Code was easier to read and there was less of it (20% reduction in HTML). Lastly I needed no “hacks” to get it to display properly. (no scripts, no broken tags, no workarounds). It can be done. I’d agree with T.J. as developers we constantly need to push the envelope. Part of that means not giving up on the “impossible”. Part of that means pushing back against clients and to do things correctly.
man that was long! Sorry! I just go off sometimes.
Michael–
I agree with your sentiments, but the biggest obsticle for me thus far was been clients who don’t want to be “the experiment.”
I’m building a site right now that is a test so that I don’t have to spend the “learning curve” on my next client’s site. It’s going well (and I’m able to do somethings in CSS that a table-based layout would puke on), but some things which should be simple (I cannot get background colors or images in DIVs to show up in IE Mac 5.x, for example) aren’t. One thing you can generally say about tables is that they look pretty much the same no matter what browser they’re in…though I suppose I’m building in the hacks I’ve learned over the years and don’t even think about them any longer.
My frustration is that CSS is based on standards that still fail because the dorks in the programming cubes find it interesting to add in more “features” no one cares about rather than building the core of their product correctly.
But my frustration also stems from the fact that the people who draw up the standards fail to think about what might genuinely might be useful, usable and in-line with the way the web is used and built. All of the end users “think outside of the box,” so why don’t the standards folks do the same? Ivory towers are lovely to look at but none of us live in them.
One point: designers care about pixel perfect because they have to. Someone has to. Perfection may never be reached, but striving for it, whether in a liquid layout or a rigid grid, is our job. Not one of us should be entirely satisfied to say “good enough” if there’s the chance to make our work “perfect.” This includes accessibility, of course, and I certainly don’t advocate style over substance or over-designing sites simply because we can. Style WITH substance is a beautiful thing and adds up to something greater than either element by themselves.
Finally, and this is now so far off the article’s topic that I *almost* feel bashful, I am surprised and perplexed in seeing so many examples of things that only work in the Gecko engine or on a Mac. I like Netscape 6.2 here on my windows machine, and my CSS works beautifully in it, but I use IE 6 as my “daily browser and ensure that whatever I do works flawlessly in it, too. I design and build using a Windows box. Why?
http://www.upsdell.com/BrowserNews/stat.htm
Yes, I know we should take stats with a grain of salt. But the numbers are overwhelming, and where there is smoke there is usually fire. Designers and builders who dismiss IE 5 or 6 on a PC from their world are committing the sin of hubris. As much as Apple commercials tout those four people who have switched from a Windows machine to a Mac, that’s not the way things work in the real world.
I do agree with you to an extent.
The problem with today’s stats is that because of the developers adding in those “features” we have browsers that masquerade as other browsers. So while our stats say 99% IE it could be 70% IE 25% mozilla/netscape 5% Opera. So the feature that allows other browsers to surf sights designed specifically for IE actually does a disservice because it helps to reinforce the fact that site developers should be developing for IE only (well the logs say that 99% of my visitors are IE, why bother with the other 1%).
Stats also don’t really tell you how the browser is being used or what other applications are being run. For instance a screen reader running over the top of IE won’t show in the logs, javascript being turned off won’t show, using a different style sheet for all pages won’t show, font size won’t show. To me stats have always been about who is accessing what (what content is important and how they get to it). While I get it that the stats might show “the majority of users are accessing using MSIE on Windows”, I do have to take the stats more generally today than I did a year ago.
That’s what made me start to work more toward just designing against the standard and avoiding work arounds and proprietary calls. Then again I work on substantially different sites than probably the majority of people here. My goal has been to set up a framework of HTML CSS and Javascript that uses the standards to allow developers to very quickly create pages without worrying about where an image is going to fall exactly. The developers focus on content, and allow the CSS to do placement.
My personal opinion is that the more developers focus on standards use the more the browser makers will focus on standards support (instead of e-mail, javascript debuggers, themes, colored scroll bars, etc). If “features” get ignored maybe they’ll stop fidgeting with them and work towards more consistent standards.
And yes the standards bodies could work a little harder to being more clear about a standard. This would keep three different browser manufacturers from interpretting one standard in three different ways.
Roger,
Just wanted to jump in on two points.
“but some things which should be simple (I cannot get background colour or images in DIVs to show up in IE Mac 5.x, for example) aren’t”
I agree, it *is* monumentally frustrating that some *very* simple things can appear impossible with CSS. Luckily, the background color and image thing in IE Mac 5.x isn’t one of them. In most cases, Microsoft’s spec means that attributes will not be applied to a DIV unless a width is specified (at this point I switch to google expecting to be able to give you a link to follow and of course can’t, perhaps someone will fill you in) and this is probably what’s giving you grief.
“designers care about pixel perfect because they have to. Someone has to. Perfection may never be reached, but striving for it, whether in a liquid layout or a rigid grid, is our job”
Again, I quite agree that is our job to strive for the best. Otherwise, what’s the point, and as you say, “good enough” is crap. Where I’d like to adjust the debate is over the use of the phrase “pixel perfect”.
It seems to me that people are increasingly interchanging “pixel perfect” with “perfect”. In most of my design work online, the pixel position of an object is, largely, not that important. Of course, there are cases where a single pixel mis-alignment can spoil the layout, but you know, those are generally the cases where CSS makes it *easier* to achieve pixel perfection.
Check out the small arrow graphic that points to the “contact us” button at http://www.cognima.com/ I wanted this arrow to line up exactly (to the pixel) with the top of the button. This was simple to achieve with the stylesheet. Again, in this example, I sort of don’t care *where* in terms of x,y position the button goes on the page, just that it is under the last column. By defining it as a background graphic, not only can its position be controlled, but it nicely goes away when in a text browser, avoiding the need to display “alt” information like “this is an arrow” and so on…
i hnow hundreds of people that use netscape 4.7
I really want to use css instead of tables, only I can’t.
I’m trying hard to find a way to position a div inside another div, and align it at the bottom.
I have some space at the bottom of the page, and I would like to have a footer at the bottom.
The whole thing is placed in a column with a fixed width.
Normally I would do something like this:
and I’m trying hard to do something like:
only it doesn’t work.
my .footer is currently position:relative; bottom:0px;
can it be done? – if yes, then how?
please save from falling back to my old habits
I think this is a critical point. We need CSS to enable a second, following container div to be aware of the actual height of the previous container div (meaning the heights of the block elements nested within that first container). Without this, it is much too difficult to get footers positioned where they ought to be. If tables can do it, you ought to be able to do it with CSS.
And no, I don’t think going back to tables is a satisfactory solution (although I udnerstand why some people might do it).
Mike Davidson worte:
>I think it is pretty unbelievable that with how great CSS1 and CSS2 are supposed to >be, no one built in the ability to keep absolutely positioned div somewhat within the >document flow. For instance, if you have 3 columns (divs) all absolutely positioned >within a container div, you should be able to insert a footer div after your container >div in the code and have the browser render the footer div at the bottom of the >longest of the three columns. It is simply ridiculous that this cannot be done.
Interesting topic and I like the basic ideas around the approach. It looks great on the example web site, as long as you don’t use NS4 or Mozilla.
That is why all of the div positioning stuff won’t ever be used by me. You can’t position things reliably unless you add hack after hack after hack and test browser after browser. So why bother? Tables work just fine for layout no matter what they are linguistically intended for.
Another problem with the desire to make an XML-like structure is that when the marketing department wants to add this or add that to a page, then you have to create another div with another id…Now you’re losing the simplicity and structure and hacking some more. And of course it never fails: then the page breaks.
It’s fun to try, though.
Janus: What you need to do is give the footer element the following CSS properties:
.footer { position: absolute; bottom: 0 }
This will take the footer element out of the flow of the page and fit its bottom to the bottom of the container element.
You will also need to give the container the following CSS property:
.container { position: relative; }
This tells the footer element to position itself relative to the bottom of the container element, NOT relative to the bottom of the page itself.
However, because the footer element is out of the document flow and doesn’t occupy any room, the content above it in the container div will try to flow beneath it. What you’ll need to do is give the container element a bottom padding greater than or equal to the expected height of the footer element; this will keep the content before the footer from flowing beneath.
Further note: because absolutely-positioning an element makes its width ‘shrinkwrap’ to fit the size of its content, you might want to manually set width: 100% to make the footer fill the width of the container element again.
…and all that so we can pat ourselves on the back for not using tables. I really want to use CSS for layout, and I *do* on almost every project nowadays, but as Peter puts his finger on it still has ludicrous shortcomings.
CSS-3 had better have some timely solutions. Another 3 years down the track, I don’t want to have to listen to the W3C lamenting the self-inflicted rise of counterintuitive hacks and illogical techniques for presentational layout, just like they have the rise of counterintuitive hacks and illogical techniques for semantic markup.
Another alternative is to make your footer the same width as your central column, or at least make the width of the content inside the footer the same. It doesn’t stay at the bottom of the page – it sits underneath the main column – but at least nothing important is hidden.
Why do people continue to assert that Opera is so standards-compliant? My web pages always look great in IE6, Mozilla 1.0 and Netscape 7.0, but they look terrible in Opera 6. Again and again Opera is the odd guy out. Opera 7 finally renders my pages as they look in the other main browers. But I don’t know what people are thinking when they say Opera has had great standards compliance since v5.
My web pages are composed of validationg XHTML 1.0 Strict and CSS2.
My page looked great in IE5 and 6, and Netscape 4.7 and 6 etc etc. But looked diferent in Opera 6. The reason wasn’t a bad browser, but bad design on my part. I since added a couple of tweaks and it is almost identical (bar things IE doesn’t support like dotted borders).
So Opera is very standards compliant, if you tell it enough information. If you don’t, then it goes to default rendering, which is different to how you are used to, obviously.
Just because it is valid code doesn’t mean it is telling the browser everything it should be. My code was also valid HTML and CSS, but still had problems until I included extra defining properties.
Jeremy wrote: “Why do people continue to assert that Opera is so standards-compliant? My web pages always look great in IE6, Mozilla 1.0 and Netscape 7.0, but they look terrible in Opera 6.”
Could you give us some links to these pages, perhaps?
Diane wrote: “That is why all of the div positioning stuff won’t ever be used by me. You can’t position things reliably unless you add hack after hack after hack and test browser after browser.”
And table positioning, of course, was plain as day and worked perfectly in all browsers from the start, right?
“So why bother? Tables work just fine for layout no matter what they are linguistically intended for.”
Why DO tables work just fine for layout? Because you’ve learned to master them. How will the web ever evolve if “designers” continue to say “Oh, I’ll never use this new technology, because it doesn’t work exactly like the old, stupidly complicated and incorrect one I’ve spent lots of time learning.”?
And why bother? Yes, if you only care about how pages LOOK in old (pre Netscape 4) and current GRAPHIC browsers, if you don’t care about low-bandwidth and other future devices, if you put appearance before content and accessibility, why bother indeed?
Why does he insist on using those damned tables for layout in his commercial projects? Why does he use pixel sizes?
Answer: he’s not as dumb as his followers (or writers)!
topico
Congratulations on the idea of bubbling up the size of an absolute element. What a pity it is necessary. Why didn’t the CSS designers take on board the notions of visual interface structure that one sees in GUI layout managers? Not that AWT (say) is perfect, but it’s a lot less time-consuming if one simply has to specify the topological relationships between the elements rather than the precise geometry. Or perhaps we should use VML and SVG and give up on HTML altogether 🙂
Looked at the example site listed in the article. It breaks under Opera 7.0 Beta 2. My experience with Opera suggests it will also break under all Opera 6.0 browsers. Columns overlap.
I’d rather use the @ import style methods than JavaScript. Scripting is a last resort.
topico wrote: “Why does he insist on using those damned tables for layout in his commercial projects? Why does he use pixel sizes?
Answer: he’s not as dumb as his followers (or writers)!”
Like, could you, like, you know, um… “elabberate” a bit, kindathing? I, uuuh, I think I’m stupid.
Of course, it would be best if Zeldman answered your question himself.
I really agree with Alun’s table layout.
My problem is (and I’m sure a lot of designers have this) that I want to have a grid and each column should be fill with a background-color – UP TO THE HIGHEST COLUMN.
With a ‘blind table’ I have no problem. For the other solutions I have to use a JS hack as above (IE & Opera are too slow – Mozilla is fast), but it’s greater hack and overhead to do.
Maybe the w3.org should define HTML tags like and also the CSS display types ‘div-row’ and ‘div-column’. … Where are the problems?
ROBERT
Last August Zeldman wrote up a short rant about what he thinks of table layouts in 2002, and why, in a number of cases, they still have a right to live.
Enjoy: http://www.zeldman.com/daily/0802d.html#livedandlovedlikefrank
– Henning
I visited your site and your source code is different than what is explained. Please explain.
The problem – do create a grid with Alan’s solution – I prefer it. But only to display the content on a PC. What happens when I want to display the content on a mobile phone (incl. another style sheet!)?
On a PC screen I have the ‘menu-navigation’ on the left – so I have to write it at first in Alan’s ‘div’ (or td). On the mobile phone I want to have it on the bottom – or after the content. But how should I define the style sheet with Alan’s solution?
With the absolute/relative solution it is possible (with newer mobile phones and if they have implemented it!). But the solution HOW-TO-DO it, is not very friendly and takes some experiments with different browsers, etc. and -> some other things are not working as I want:
I want to have that the left navigation should have the FULL background to the bottom as the main part on the right. With blind tables no problem. With the absolute/relative display I have to use the JavaScript. But to slow – also on my fast machine (only Mozilla does the one-and-only job very fast).
Hello,
we are having the same problem in my company, where we need to industrialize much content because we now use XML technologies and database drivent content,
the content needs to look very “hand made” though, so we are struggling … we have web designers that do very pretty hand made content, but the STEP from that content to industrialization is tricky, we don’t know who is most productive to adapt both worlds, if a Web Designer has to do and learn CSS and “blackbox” html, or if the programer have to take the designed content and try to simplify it,
I wonder to know, how you and your team do that… We work a lot with templates now, but we want to be able to change those easily, we want content to be pretty enough, etc…
So I was thinking of a method:
– the creative designer designs a very good looking illustration
– the tech designer sets a complete and enumerative page with all the “design objects” and their respective css/html
– the programmers take and integrate all this and industrialize the process …
The second step is confusing for us … so if somebody is having the same problems, please tell us how to handle …
Have a nice day, bye!
Hire a proffesional.
The person must be able to communicate with the designers. He should listen to what their goals are and teach them how to achieve the desired result, explaining how and why, citing technical references.
The other concern is the separation of business logic and presentation. The programmers must also work with the designers so the objective and procedure can be realized and a division of labor is decided early on.
when business logic and presentation logic are separated, more flexibility will be gained. The result will be a more extensible system.
> So I was thinking of a method:
> – the creative designer designs a very good looking illustration
> – the tech designer sets a complete and enumerative page with all the
“design objects” and their respective css/html
KPOCHA,
I guess I would agree with Garrett above…
However, I think the real problem is the definition of “creative” as in “creative designer”.
An interactive page such as a web page is an application, and the person that applies creative flair, understanding of production restrictions, understanding of user behaviour and so on is an application designer. The term “web designer” should probably never have been coined.
I expect an application designer to think in terms of “design objects” because that is the only way his ideas will become reality.
It’s hard to bill clients for tasks that they don’t understand or perceive to be valuable. The reason there is so little quality client-side scripting (for example) out there is because it’s impossible to sell to a client (he’s seen the pretty photoshop layout, why does he have to pay extra for javascript development?). In practise, your “creative designer” and your “tech designer” are the same person.
As Garrett says, hire a pro;-)
Best
-dug
ps
Happy new year all
There’s this really irritating bug in IE6 that makes some pages laid out with floats repeat the last six or so characters on the page a couple of lines below the proper end of the page. This maddness does something like this:
Copyright 2003, A List Apart
t Apart
Anybody else experiencing this? Both my CSS and XHTML validate and here they are:
#header {
padding: 0 0 0 0;
margin: 0 0 0 0;
float: left;
display: inline;
width: 100%;
height: auto;
}
#col1 {
padding: 0 0 0 0;
margin: 0 0 0 0;
float: left;
display: inline;
width: 220px;
height: auto;
}
#col2 {
padding: 0 0 0 0;
margin: 0 0 0 0;
float: left;
display: inline;
width: 420px;
height: auto;
}
#footer {
padding: 0 0 0 0;
margin: 0 0 0 0;
float: right;
display: inline;
width: 100%;
height: auto;
}
The problem was the comments. Take all comments out, bug fixed but bigger headache for colleagues! Maddness..
Greetings,
I have been currently working on the url site above which I entered in for “Your Url”. Anyhow I am fairly new at css and my problem is this, when I create a page layout in css within a certain resolution then the page is viewed in another higher or lower resolution the page looks different and is out of wack. How can I fix this so it will look the same at all resolutions……
Thanks for you time,
Lekeno
Just implemented this code for the account managemene site of Citysearch.com. PDA is functional, WOW!!!!
Compatible with Windows IE5.0+ NN6.0+
– Doesn’t work in MacIE5 and not sure how to fix it yet.
– Main Nav buttons display in opposite order of code? very weird.
Any thoughts on the Mac issue would be welcome.
Back in article 119 there was demonstation of how to use DIV and SPAN in place of the usual table format within Forms. Unfortunately there was no comment button at the bottom of the article for me to ask the following question, so forgive me if I use this article which is based roughly on the same subject 😉
In most forms the writer usually likes to employ some form of validation and check on compulsory entries.
Now this is normally done with reference to the “name” elements in the table within the Form, my question is, how can this be accomplished using the DIV and SPAN method??
I think the article was very informative; I being a navice at this has a resolution problem! My site does not show properly at a higher resolution and I don’t know what to do? Can anyone help me please?
Thanks
This is not about coding. This is about peole who care. And Dug, welcome to the club. Your article has brightened my day. For all of us that we are not hardcore coders, your approach is a really cool way to get our stuff done right.
Thanks from Southern Chile.
what’s the difference between SPAN and DIV?
I’m building a page accoring to the XHTML Mobile Profile. Is it possible to use the “top” and “left” attributes for a div?
I’ve used this techique, but finded some trubles on IE.
I’ve coded a webpage, that has only div’s , and it works like i want to on mozilla, opera and netscape but on internet explorer doesn’t show the background of the forms divs, should be white.
heres an example
http://www.t6m.com/cssbug/
and css is on
http://www.t6m.com/cssbug/Event/scripts/real_event.css
feel free to look
thanks in advance
I read this article and all I could find on the net about CSS, tables replacement by DIVs, and so on … To my minf this is too prematured to use such techniques with all browsers having problems with the standard. That’s why I don’t understand why you are all crazy about CSS. CSS is good for formatting, it’s not yet for layouts.
I tried all the techniques to build a 3 columns layout. Each time when reducing the window width, the 3rd column goes under the 2nd one. I can’t even imagine producing a site where my visitors would say : this is not serious.
So I will stay with tables until something serious comes up in browsers. This day, I will convert.
I have read this article and CSS Design: Taming lists. Great info and very informative, but now I’m looking beyond for a new solution. I have my list of links on the left hand side of the web page, common. I’m got some content in the center of the page, and I want to wrap the bottom across the bottom of the content. We’ve all seen it before, and I know it can be done with pretty pictures: a nice bar on the left that bends at the bottom and juts to the right. Now the question, how do I do his with CSS?
Well, I like Firebird for it is much lighter then mozilla/netscape but on the other hand it has the exactly same problems rendering my website. I don’t know if the problem is with IE/OPERA (for it displays correctly and the same in both) or with Firebird but since IE community is the largest and I personaly am using OPERA 7.11 I won’t switch until the rendering of CSS is improved.
I do have all of them installed for experiments and I try really hard to get standard, and I am (according to XHTML transitional validator), but MOzilla/Firebird always position my divs a bit lower then it is supposed.
http://exp.hicksdesign.co.uk/
I just wouldlike to ask: Is this frame effect Standard?
You see, I wanted to use that effect for same time now…
Can you give me some light?
Keep up the good work!
May Peace Prevail!
TEYATA OM MUNI MUNI MAHA MUNAYE SOHA
http://exp.hicksdesign.co.uk
I just wouldlike to ask: Is frame effect Standard?
You see I wanted to use that effect for same time now…
Can you give me some light?
Keep up the good work!
May Peace Prevail!
TEYATA OM MUNI MUNI MAHA MUNAYE SOHA
I read that the
position: absolute
doesn’t mean that the position (right: left: top: bottom:) is relative to the entire window, but it is relative to the innermost block containing the element! Is this right?
I thought the
position: absolute
made these distances (right: left: top: bottom:) relative to the entire document, an the
position: relative
made these distances relative to the innermost block element!
Was it wrong?
if so, the html (with CSS) below should work fine, but it doesn’t!
——
css:
.container
{
background-color: Green;
padding: 5px;
}
.content
{
background-color: Red;
padding: 5px;
width: 200px;
right: 3px;
position: absolute;
}
html:
—–
as you can see, the .content div overlaps the border and goes outside the .container! what’s wrong?
thanks.
Mattia
Hi,
I have a fixed layout of 760 width. I’m using CSS2 to place the buttons in the top nav whose link’s and text come thru server side. Now it requires a line to stretch in the end and only appear when there are less links on the top navigation. As it is dynamic, the line also needs to stretch acordingly hence i don’t want the width for the line to be defined. Just now my code has it. Below is the code for both the HTML and CSS. Browser supported are IE5.0 and above and Netscape 6.1 and above. Please help as soon we are entering to UAT and i still don’t have a fix for it.
HTML :
CSS:
.button {
color: #ffffff;
background-color: #99cc00;
height:15px;
font-family: Arial, Verdana, Helvetica, sans-serif;
font-size: 8pt;
font-style: normal;
font-weight: bold;
text-align: center;
text-decoration: none;
padding: 2px 5px 2px 5px;
display: block;
float: left;
border-top: 1px solid #99cc00;
border-right: 1px solid #99cc00;
border-left: 1px solid #99cc00;
border-bottom: 1px solid #009900;
}
.button:Hover{
color: #ffffff;
background-color: #009F00;
height: 15px;
padding: 2px 5px 2px 5px;
text-decoration: none;
font-weight: bold;
border-bottom: 1px solid #009900;
border-top: 1px solid #009900;
border-right: 1px solid #009900;
border-left: 1px solid #009900;
}
.button1{
color: #009900;
background-color: #ffffff;
height: 15px;
font-family: Arial, Verdana, Helvetica, sans-serif;
font-size: 8pt;
font-style: normal;
font-weight: bold;
text-align: center;
text-decoration: none;
padding: 2px 5px 2px 5px;
display: block;
float: left;
border-top: 1px solid #009900;
border-right: 1px solid #009900;
border-left: 1px solid #009900;
}
.padding{
width: 2px;
float: left;
background-color: #ffffff;
border-bottom: 1px solid #009900;
padding: 0;
margin: 0;
height:20px;
}
.bBottom{
border-bottom: 1px solid #009900;
float:left;
height: 20px;
width: 29.5%;
overflow: hidden;
}
.vertical6{
padding: 0;
margin: 0;
height: 3px;
overflow: hidden;
}
Thanks
a
no entiendo nada !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! buaaaaaaaaaaaaa
Anu, try taking out the width parameter in the bBottom class. Leaves a samll tail in Moz Firebird when I do this.
I do write some tosh. The small tail was, of course, the padding at the end of the buttons. I made the following work for me, you will need to modify the Hover to suit.
body {
margin:10px 10px 0 10px;
padding:0;
background:white;
}
.button {
color: red;
background-color: #CCC;
height:18px;
font-family: Arial, Verdana, Helvetica, sans-serif;
font-size: 10pt;
font-style: normal;
font-weight: bold;
text-align: center;
text-decoration: none;
padding: 2px 5px 2px 5px;
display: block;
float: left;
border-top: 1px solid blue;
border-right: 1px solid blue;
border-left: 1px solid blue;
border-bottom: 5px solid black;
}
.padding {
width: 5px;
height: 18px;
padding: 2px 0px 2px 0px;
float: left;
/* background-color: #ffffff; inherit ‘body’*/
border-top: 1px solid white;
border-bottom: 5px solid red;
margin: 0;
}
Don’t need to call the bBottom class.
Here is a slight modification of Justin’ script. I’m far from a Javascript/DOM expert, so here is my attempt to get it right.
The difference in this script is it looks for a div element with a class named ‘container’. Inside the container you have your children div elements. The script calculates and sets the height for the container div, then goes finds the children div elements of the container and sets their height as well.
In the body element put onload=’balanceContainer()’ and thats it. It should work in IE 5.5+ and any Mozilla browser. Works in IE6/Mozilla 1.4, but haven’t tried it in Opera/Konqueror/Safari yet though.
=====================
function parseContainer(div) {
var tLength=0;
var nLength=0;
var childNode;
var children=div.childNodes;
for (i = 0; i < children.length; i++) { childNode=children.item(i); nLength=childNode.offsetHeight; if (nLength > tLength) { tLength=nLength; }
}
div.style.height = tLength + ‘px’;
/* Parse again -> Insert offsetHeight to all children */
for (i = 0; i < children.length; i++) { setSubContainer(children[i],tLength); } } function setSubContainer(subdiv,length) { if (subdiv.tagName == 'DIV') { subdiv.style.height=length + 'px'; } }
How about this… Setup three main divs called top, middle and bottom. The top div is absolute at the top of the page/screen, the middle is relative to the bottom of the top. The bottom is relative to the middle.
So the middle and bottom divs are relatively positioned vertically.
Within the middle div (container), create the column divs (1 to 4). The column divs are relatively positioned horizontally. If we assume that each column div is evenly spaced then they would be 25% of the width of the container div.
Is what I’ve described above impossible to do with divs, CSS, and without tables? Is is possible for a div to automatically expand in the way that table cells do. If divs can expand the way table cells do, then do relatively positioned divs, automatically readjust their based on other elements within a document… specifically other divs?
I’m hoping the answers are yes, yes, and yes. If not please explain.
hmm isn’t all this suposed to be geared towards accesibility? some areas of info on this page (i.e. samples/examples of code) are spread all over the place. Just thought i’d let you kno and ask if anyone knows why.
http://webforums.macromedia.com/dreamweaver/messageview.cfm?catid=189&threadid=735071
I just discoverd that the topic how to get a DIV to expand its container DIV or other element is discussed here aswell. I posted the similar on the Macromedia forum this friday . One partial solution is to float the child DIVs but then I had to REMOVE absoulte positioning on those DIVs. Can you belive that! Flexibel layout consepts are something I have to deliver. And pushing the child DIVs around with padding and borders is not good.
What is the Übersolution to follow folks?
Erland FLaten, Lillehammer Norway.
You can find an other solution at: http://www.s7u.co.uk/layouts/3cols.html
This one works ok without the use of javascript!
>>An interactive page such as a web page is an application.
if this is the case why dont we have a browser that works like the adobe acrobat interface, removing navigation into a side bar.
If you could somehow declare to a user agent what is your navigation or even a site index, ‘footer’ information and all that other standard stuff it’s display could be removed from the ‘web’, ‘pda’, ‘mobile phone’ screen.
Why do we need to write an ‘application’ every time that we want to publish something? I thought the browser was supposed to be the application.
i don’t know how to search ALA to see if the issue has been raised and it does kind of relate to my last point.
Taking a wedge of text and shoving it in both a html page without formating and a pdf file with formating the resulting file sizes were 12k and 16k.
I guess the extra code needed for the layout in the html and css would bump it up 2 or 3 k, and still would do well to get close to the amount of control you have laying out the pdf, and you have control of font face and sizing and printing.
Is it not the case that pdf could be a viable alternative to html – especially for sites that are no more than a company brochure. For dynamic sites I dont know, I believe you can have forms in pdf? but I dont know how they can be generated on the fly.