PDA

View Full Version : Old dogs and new layouts


David
16th Jul 2004, 10:29 pm
They say that you can't teach an old dog new tricks and just recently I'm beginning to appreciate the veracity of that particular saying.

Now, I'm an open minded sort of person and I have a natural curiosity for all things new. I'm also never happier than when I'm learning new skills. None of this, however, is any help when approaching that most vexed of topics: CSS layout.

I am convinced of the fact that CSS is the right way forward for the page layout of web pages and I will even concede that tables were just a convenient interloper - a handy tool that never was designed for that purpose.

I have a number of web design projects on at the moment and one of them is a very simple site for a friend of mine who wants to advertise a house in Italy. That's just background. I decided that it would be a good idea to work this site up entirely with CSS - it's a simple site - can't be THAT difficult.

I start from first principles and I design a simple layout:
http://www.websitearchitecture.co.uk/watson/postimages/limoni/page.gif

...and here's the relevant CSS:
#wrapper {
width:80%;
position:relative;
background-color:#DAEDFF;
border:2px solid #466C91;
margin:2em auto 2em auto;
padding:8em 2em 2em 2em;
}
#head {
position:relative;
width:100%;
float:both;
}
#content {
position:relative;
float:right;
width:auto;
}
#nav *{
position:relative;
float:left;
width:100px;
}
.title {
padding-bottom:2em;
}

It all looks perfectly logical. Here's the relevant HTML:
<body>
<div id="wrapper">
<div id"head">
* <img src="images/title.gif" width="290" height="33" alt="" class="title" />
</div>
* <div id="nav">
<ul>
<li><a href="index.html">Home</a></li>
<li><a href="gallery.html">Photo Gallery</a></li>
</ul>
* </div>
* <div id="content">
<p>The hamlet of Montefiorile is in the heart of the Tuscan hills, surrounded by woods, olive groves and Chianti Classico vineyards which provide the wonderful foods and wines of the area. Scenic walks in the woods can be followed by a refreshing swim in the hamlet’s pool.</p>
* </div>
</div>
</body>

So far, everything is looking fine and dandy. The page previews correctly in Dreamweaver and IE displays the page just as you would expect given the clear and logical code:

http://www.websitearchitecture.co.uk/watson/postimages/limoni/ie.jpg

"Hey, this CSS layout stuff is fantastic", I'm thinking to myself, "so much better than tables - so much more control".

And then, "Hmm, I wonder what it looks like in Moz?"

http://www.websitearchitecture.co.uk/watson/postimages/limoni/moz.jpg

"Oh dear - I spoke too soon. Ah, but Opera..."

http://www.websitearchitecture.co.uk/watson/postimages/limoni/opera.jpg

I don't have an emoticon for crying - I looked for one and I'm going to get one soon because I'm going to need it.

Now, we've had this argument before. I say, "IE just does what you want, it's logical and it's forgiving - the kind of browser you wouldn't mind taking down the pub on a Friday evening." And Francis says, "Ah, yes but it's wrong - it's no use having friends who flatter you, you need friends who tell you the truth!" - or was that my Mum?

Anyway, you can't tell me that in this particular case, IE is wrong. The code is simple and logical - by-the-book even. And IE just does what it says on the tin. But Moz is that "sign everything in triplicate" sort of friend, the stickler - the one that gives you a tin of pink paint when you asked for green just because the label was incorrectly printed.

I feel you are sensing my frustration.

Needless to say, a table layout version of the same page looked identical in all 3 browsers. So, I have 3 options:
1. Stick with tables (give in and avoid the whole object of the exercise)
2. Stick with what I've got (IE looks fine so f*** the others)
3. Or spend days tweaking, trawling through forums and generally beating myself up about it.

Hmm, tough choice.

francis
17th Jul 2004, 10:27 am
Originally posted by David@Jul 16 2004, 10:29 pm
Anyway, you can't tell me that in this particular case, IE is wrong. The code is simple and logical - by-the-book even.
Sorry, I can!

Firstly, you're missing an = on <div id"head">, so your XHTML won't validate. Secondly, although it validates (don't know why), the specs for CSS 2 and 2.1 for floats (http://www.w3.org/TR/CSS21/visuren.html#floats) have no mention of "both" as an option. You can have left, right, none or inherit.

Now, onto floats. Floats should, by the book, behave like this. It's the spec, it's how they work; things can and should expand out of a floated area. IE does get it wrong. See Meyer's article on floats (http://www.complexspiral.com/publications/containing-floats/) that will explain. From memory, IE gets floats right if you don't assign a width to them, but we've just been there with Bentley.

Still, not to worry, a fantastic way of clearing floats (http://www.positioniseverything.net/easyclearing.html) appeared a month or so ago. Have a read of that and all your troubles will go away! Using one of Meyer's examples, adding this:

<div style="clear:both;"></div>

Just before your last closing <div> does the trick.

Floats != easy.

As you've got Moz's web developer's tool bar now, under Miscellaneous, there's links to W3C docs. There's only CSS2 on there which has been superceded by CSS2.1. Until the next version of the toolbar comes out, you'll have to get specs by going through the W3C site (I emailled the developer who said 2.1 shortcut is coming in the next build).

David
18th Jul 2004, 12:10 pm
OK, I admit to incompetent late-night coding. The missing "=" is neither here nor there as none of the browsers noticed the difference when I put it back. The float:both gaffe is rather more fundamental. Somehow, in my befuddled state I had conflated the float and clear CSS properties into a single property - it made sense at the time.

BUT (and this is the point) despite sloppy coding, IE still managed to interpret my intentions correctly and displayed the page as I had intended. Meanwhile the Moz stickler pretended not to understand me.

I will publish the corrected code here when I've finalised it.

So, just to recap, IE got it right but that was wrong whereas Moz got it wrong but that was right. OK?

Pint of bitter IE?

David
18th Jul 2004, 12:48 pm
Francis - having just read both of the excellent articles you pointed to in your post, I am now much clearer about this issue. I am, however, left with the impression that in this particular case, IE is technically wrong (according to current specifications) but is actually more logical in the way it interprets the code. Moz is technically correct but is illogical and Opera falls somewhere between the two.

It would seem absolutely logical that a float within a container should stay within that container and not spill out of it. My conclusion is that in this case, the specification is not logical. I can think of all sorts of reasons why this is - layers, absolute positioning etc.

There's no doubt that CSS is very complex and there are lots of conflicting issues within the specification. The fact that Moz requires a workaround in order to correctly dispaly a very simple layout tells me that W3C haven't got it quite right yet.

francis
18th Jul 2004, 04:15 pm
There's a feeling that the W3C have got a few things wrong with the current spec. There's even the possibility that CSS3 will support two different box models: the correct one as implemented by IE6 (standards mode), Moz/FF, Opera, Safari etc etc and also the <IE6, IE6 (broken mode) version. The feeling is that IE's implementation of the box model is more logical, but we'll have to wait and see whether the W3C is going to do this. CSS3 (http://www.w3.org/Style/CSS/current-work) promises some amazing stuff (if you look at that link in non-IE browsers, you'll see the right-hand menu doesn't move - that's CSS2's position:fixed)

I keep those pages bookmarked as they're really useful. In fact, about two hours after your post, a colleague mailed me with exactly the same query!

James
18th Jul 2004, 06:02 pm
An interesting thread guys.

What bothers me is that code is supposed to be STANDARD. Yet, there is nothing STANDARD about its implementation! I appreciate the "IE is wrong" argument but ultimately, for the coder, it's an illogical headache.

francis
18th Jul 2004, 06:32 pm
Indeed, and this is where the W3C is also flaky. If you have a look at, say, the CSS2.1 (http://www.w3.org/TR/CSS21/) specs, on the one hand it says "specification", so okay, this is what we work towards. However, the next line down says "recommendation" so, huh, maybe this is just what the W3C recommends we do. It's the same with, I think, all of the specs, eg: HTML4.01 (http://www.w3.org/TR/html401/).

David
19th Jul 2004, 11:51 am
Well, I promised a solution to this layout issue and so I set myself a challenge. I gave myself 3 hours to come up with a layout solution for this very simple page that did not require a hack, fudge or workaround in order to look the same in all 3 target browsers.

I started by tweaking the model I had begun with but no matter what I did, I couldn't get Moz to play ball with plain CSS (no fancy stuff).

I then thought I might be on safer ground moving to an absolute position model. I tried this and although there was some success, Moz insisted on flowing the body text below the nav column. Again, I couldn't do it with plain CSS.

I thought that, being such a simple layout, there must be someone out there who has already done this - and of course there is. There are plenty of sites that offer free CSS layout templates. I checked out 4 or 5 different solutions. Not one of them had managed to implement even a basic page layout with plain CSS that was consistent in all 3 browsers. There was a hack here, a fudge there and a number of workarounds. Little Boxes (http://www.thenoodleincident.com/tutorials/box_lesson/boxes.html) at The Noodle Incident (http://www.thenoodleincident.com) was typical of many. Even a very basic two column layout (http://www.thenoodleincident.com/tutorials/box_lesson/basic2_fixed.html) isn't possible without a fudge.

The closest I came to finding something approaching what I wanted (http://nemesis1.f2o.org/authors/weakley/final) was at Max Design (http://www.maxdesign.com.au/presentation/page_layouts/index.cfm). This layout (http://nemesis1.f2o.org/authors/weakley/final) is defined in pretty straightforward CSS. In fact, it's similar to the technique Francis used on the Bentley site. I did, however, have a problem porting this solution to my site and by now, my 3 hours was running out. I needed a sure-fire solution that I knew I could implement in about 10 minutes.

And I did it. I found a logical, consistent, robust and simple solution that looked the same in all 3 browsers with a minimum of code and (perhaps more importantly, with a minimum of time). "What is this magic bullet?" I hear you ask. Well, having spent far too much time scrutinising CSS workarounds, I am tempted to christen this ingenious solution "the cross-browser table hack". It is, of course a simple table layout with all the table formatting moved to CSS.

The logic behind this is simple. Since the CSS box model is not logical, simply substitute it with a model that IS logical. Let the table do all the dividing and containing and let CSS do what it's best at, formatting.

The beauty of this solution is that it not only looks the way I want but it also "acts" the way it should. Resizing the browser window causes the content cell to widen and the content within flows as if it were in a <div> while the nav cell retains its fixed width. Hence, it is impossible to tell (without looking at the code) whether this page is <table> based or <div> based.

Here's the relevant html:
<body>
<table id="container" cellspacing="0">
* <tr>
* * *<td colspan="2" id="head"><img src="images/title.gif" width="290" height="33" /></td>
* </tr>
* <tr valign="top">
* * *<td id="nav">
* * *<ul>
* * * * <li><a href="index.html">Home</a></li>
* * * * <li><a href="gallery.html">Photo Gallery</a></li>
* * *</ul>
* * *</td>
* * *<td id="content">
<p>The hamlet of Montefiorile is in the heart of the Tuscan hills, surrounded by woods, olive groves and Chianti Classico vineyards which provide the wonderful foods and wines of the area. Scenic walks in the woods can be followed by a refreshing swim in the hamlet’s pool.</p>
<img class="imgright" src="images/limoni-01.jpg" width="250" height="175" alt="" />
<p>From relaxing on the patio it is only a ½ hour drive to Siena, or 1 hour to Florence, to see and experience all the delights that these world renowned cities can offer.</p>
* * *</td>
* </tr>
* <tr>
* * *<td id="footer" colspan="2">footer</td>
* </tr>
</table>
</body>


As you can see, there is practically no embedded table formatting. Only the cellspacing attribute is required as there didn't appear to be any way of dealing with this in CSS. Obviously, the colspan attribute is also used to control cell layout.

Here's the relevant CSS:
body {
background:#5989B8 url("../images/back.jpg");
color:#2F4962;
font:0.84em/1.5em arial, san-serif;
padding-bottom:30px;
}
#container {
width:85%;
background-color:#DAEDFF;
border:2px solid #466C91;
margin:30px auto 0px auto;
}
#head {
padding:70px 20px 25px 20px;
}
#nav {
width:120px;
padding-left:20px;
}
#nav ul {
list-style:none;
margin-left:0; * * /* for IE and Opera */
padding-left:0; * */* for MOZ */
}
#nav li a{
font-weight:bold;
color:#466C91;
text-decoration:none;
}
#nav li a:hover{
color:#F00;
}
#content {
padding-right:20px;
padding-bottom:20px;
}
#footer {
background-color:#CCDEEF;
border-top:1px solid #466C91;
padding:5px 20px 5px 20px;
text-align:center;
}
.imgright {
float:right;
margin:6px 0px 15px 15px;
}

Notice that (other than cellspacing), every aspect of table and cell formatting can be achieved with CSS and it all works perfecly logically and with no surprises. The table/cell formatting was almost perfectly consistent in all 3 browsers. The only inconsistency I noticed was that IE refused to correcly display the bottom margin for #container but this was easily resolved by padding-bottom for the body.

Here's how the 3 browsers display the page:

http://www.websitearchitecture.co.uk/watson/postimages/limoni/ie-tab.jpg
Internet Explorer

http://www.websitearchitecture.co.uk/watson/postimages/limoni/moz-tab.jpg
Mozilla - notice minor text flow differences between this and IE, above. This has always been the case with these two browsers. It's a minor annoyance and can be resolved by rigid formatting of the paragraph tag.

http://www.websitearchitecture.co.uk/watson/postimages/limoni/opera-tab.jpg
Opera - what the heck is it doing with that image!

There are two other non-table related inconsistencies with this design that are probably worth pointing out. These issues crop up whether you use tables or divs.

1. Both IE and Opera consider the indent of a list to be a margin, whereas Moz considers this indent to be padding. Since I wanted no indent, I had to set both these to zero. See the comments in the code above for details.

2. Opera does some very funny things with images. Most importantly, it deals with the space around images differently to both IE and Moz (IE and Moz are consistent in this case). The result is that the relative position of floated images in Opera is slightly different from IE and Moz. I haven't found a solution to this but frankly, I can live with that.

So, the upshot of this investigation is that I failed in my stated aim. I have, however, learned a lot and discovered a new (and far superior) way of working with tables. The method of using a CSS ID for each cell area even allows for such accessibility options at a "skipnav".

James
19th Jul 2004, 04:30 pm
Like it David. But no matter how you dress it up, you've used tables for layout. Francis won't approve! :lol:

David
19th Jul 2004, 11:25 pm
I'm not expecting approval :) What I've done is not clever and is not funny but it IS pragmatic. I genuinely hope that the CSS 3.0 box models will sort out this muddle. A web designer should not need to be concerned with arcane fixes and fudges just to deliver a very basic page layout. This kind of thing just plays into the hands of the techies - the technology underpinning web pages should allow designers to work freely and not sidetrack them into Kafkaesque searches for simple solutions. What a waste of time!