The gauntlet was thrown down and I took it up - wrecking a perfectly good table-based site template in the process, mind you! The question as to whether a salty old table dog like me can pick up table-free website design in a long weekend? Score one for tables! As you can see from the attached screenshot, I have two fundamental layout problems.

First, the footer.
I have worked many hours on the site footer, trying to get it to work without going back to the drawing board (Photoshop, in my case). I've said it before and I'll say it again - I'll miss good ol' "rowspan=2"! :) Anyway, I gave in and re-sliced the image in a way I thought would be easier to design table-free. The best I could do with the prior image slicing wound up with the text centered, not right-justified. All effort at right-justification yielded a white background behind the text only. I tried the old grassbar as both foreground and background images. Yup, I've been knocking my head against this for a few days now. The way the css stands now is clean, I felt it would work - float all footer images right, with a clear:both before each one. The first image clears the middle-section column effect. The second image clears the first floated image, or so I thought. Anyway, Firefox understands me...

Second, the left column.
I have the same problem whether I float the left column or the right. The floated content expands or shifts, whatever the appearance changes over the past few days there is one thing in common - the 700px width of the containing <div> seems to be meaningless. This I truly don't get - when working with images, they stay in their containers fine. When dealing with two columns of text, I seem to be stuck with a liquid layout. This is currently best illustrated in the IE pane of the screenshot - it centers the page as intended, but that darned menu is stuck over there on the left edge. I've tried this every which way, there must be something fundamental I'm missing.

Other problems, like column height, can wait as can the gap in the header - that's from extra blankspace output by the php app. For this little project, I've relaxed my site rules a touch. Open editing of the code (don't worry, it isn't dynamic) is allowed for all, I've provided two links - first is the code itself, second the history page - which highlights edits using diff.

canuckbison.bisonsystems.net/PmWiki/TemplateSource?action=edit
canuckbison.bisonsystems.net/PmWiki/TemplateSource?action=diff

Edit the code there, and your change will be highlighted in the history page. Cut and paste that snippet into this thread, if you want - that way the line number changed is highlighted for me to see and evaluate. Like this:

Changed lines 142-143 from:

background-color:White;}

to:

background-image:url(../images/sliver.jpg);
background-repeat:repeat-y;}

Attached is a screen shot showing the current output discrepancies on XP in Opera, IE and Firefox. The image highlights my frustration - unpredictable results, at least for the uninitiated like myself, across browsers.

Oh :deer:!

Umm, for the footer, why not simply create a single image of the buffalo and grass, then use that one image as your background, something like this...


#footer {
background:#FFF url(name.ext) bottom no-repeat ;
color:#033 ;
padding:20px 100(?)px 30(?)px 20px ;
text-align:right ;
width:700px
}

Problem solved, no special positioning, no slicing, no sweat :D

Originally posted by the_pm
Problem solved, no special positioning, no slicing, no sweat :D

Done! I'm holding you personally responsible for the extra .35KB, though...

Whoa, never mind! I wouldn't want someone on a 14.4 modem to have to wait an extra 1/4 sec. for the page to download!

;)

Now for the middle section. All you need to do here is create a containing element with your desired width and background/text colors specified. Then float your menu in its own div on the left next to your content. Let your content fill out the entire area, but pad it to accommodate the menu. Here's a sample from a project I'm toying with - http://corvette.websitewelcome.com/~onintell/new/excerpts.php

The code is pretty much bare, but I think closely resembles what you're trying to achieve (without the header portion, which has already been ironed out).

See if that does the trick for you. No tables, no positioning, and not a stitch of superfluous markup :D

Originally posted by the_pm
The code is pretty much bare, but I think closely resembles what you're trying to achieve (without the header portion, which has already been ironed out).

You'd better have another look; try using IE. I've broken (not on purpose!) Zope's code for the navbar, and we're back to the whitespace and line wrap problem.

Originally posted by the_pm
Now for the middle section. All you need to do here is create a containing element with your desired width and background/text colors specified. Then float your menu in its own div on the left next to your content. Let your content fill out the entire area, but pad it to accommodate the menu.

That's what led me to this problem the other day...
Probably since I don't know how to make that left column any taller than it is, without breaking the page.
Besides, I thought <div id="wikifoot"> with width specified to 700px would do the trick as that containing element...

Try this - see how there's a line break in your code between the navigation images and the containing <div> tags?

...no-repeat;">
<img name="image11"...

Close that space:

...no-repeat;"><img name="image11"...

So the long line of code that makes up your nav images should not have gaps between the end of the <div>/</div> tags and the <img> tags.

See if that does the trick. This is an old IE bug where IE treats a line break in code like a space, which jostles your images around a bit and leaves room underneath for a descender.

Originally posted by BigBison
That's what led me to this problem the other day...
Probably since I don't know how to make that left column any taller than it is, without breaking the page.
Besides, I thought <div id="wikifoot"> with width specified to 700px would do the trick as that containing element...
No need to make it taller :)

Create an image of the sidebars to use as a background (1px sliver will do the trick). Set it as the background image in the parent <div>, then float the nav <div> to fit right between the lines! This is how I achieved the desired effect in the sample I posted for you.

Originally posted by the_pm
Try this - see how there's a line break in your code between the navigation images and the containing <div> tags?

Nope. I also got rid of the line break between the last image and the </div>.

The bars already were a 1px sliver, unless you meant vertically? I don't understand why they're gone entirely now, after specifying the sliver as the background of <div id="wikibody">.

canuckbison.bisonsystems.net/PmWiki/TemplateSource?action=diff

<edited>

Ok, we're honing in on the problem. I've heard there may be IE bugs when you specify height by itself for a container, though it only shows itself in certain circumstance (of which I've forgotten). Just for kicks, try specifying the proper width in <div id="wikihead"> and see if that helps.

I'll keep searching on my end...

Originally posted by BigBison
The bars already were a 1px sliver, unless you meant vertically? I don't understand why they're gone entirely now, after specifying the sliver as the background of <div id="wikifoot">.

canuckbison.bisonsystems.net/PmWiki/TemplateSource?action=diff
Nope, I meant as the background of a container in which <div id="wikileft"> should reside (not talking about the footer here).

Like so:

<div style="background:#FFF url(bg_wikileft.gif) repeat-y ; color:#033 ; width:700px">
<div id="wikileft" style="float:left ; width:###px">
Left menu stuff goes here
</div>
<div id="wikicontent" style="margin-left:###px">
Wiki content goes here
</div>
</div>

This would take a little tweaking from here, but it would basically accomplish what you're trying to achieve.

wikihead, wikibody, and wikifoot have each been set to 700px all along. The container we're currently discussing is "wikibody", now that we've each gotten that wrong...

wikileft and wikitext (I don't get to name these) are both inside of wikibody.

Deleted line 153:

width:560px;

OK, with the left margin set to account for the 140px column, I don't get where deleting this line makes a difference. See, 560px is the width of wikitext. Since it's inside wikibody, shouldn't it inherit the same width?

See what happens now?
canuckbison.bisonsystems.net/PmWikiTipsForEditing

The screenshot:

Here. Is this what you're trying to achieve within the content area?

http://www.plhmedia.com/ex/wiki/

You got it. Providing I catch on, I'd like next to try to figure out how to do a 3rd column, or a second 'box' under the first, in the left column. Cake with tables...

Source-nap to your heart's content :)
Providing I catch on, I'd like next to try to figure out how to do a 3rd column, or a second 'box' under the first, in the left column. Cake with tables...
You mean stack a column underneath the navigation? Simple, just create a div inside of <div id="wikiLeft"> and go from there! If you need the div to extend into the area that is being protected by padding in wikiLeft, use negative margins.

Originally posted by the_pm
Source-nap to your heart's content :)

Thank you! It will center, I presume?

Originally posted by BigBison
Thank you! It will center, I presume?
As long as it's located inside a container that centers the entire page, then sure, it should center just fine. Though you'll want to watch out for inheritence. Sometimes specifying <div align="center" id="parent"> around an entire page causes the equivalent of text-align:center in every <div> that follows. A single, brief rule in your style sheet should nullify this effect.

Something like - #parent div { text-align:left } - should cause the default inline element alignment to trickle down through the rest of your site.

Just a minor point that bugs me quite a bit. I don't think it's right to use the phrase table-free site when you are simply referring to ditching layout tables and using css layout instead.

It would be more accurate to call it a css layout site. Why do I think that distinction is important? Well simply because even under css layouts, tables are still perfectly valid for data... and indeed SHOULD be used.

I've seen some people go too far with removing tables and create entire data layouts entirely in css which is simply wrong, especially as the entire point of css layouts is for accessibility then using css layouts for data tables breaks that accessibility again.

This problem with the navbar in IE just won't go away...
although everything appears to be set up the same way as when the header is separate (http://www.ericjbowman.com/header5.html).

OK, Rich. Table-free template it is! I want tables only within the main content area.

I have no taste for css tables, either. I tried these out the other day, and realized if anything the markup involved was less readable and more cumbersome than a table.

I'm happy with my new footer! Just this morning, I was ready to put that part of the structure back into a table. CSS layout site is a good term, as well because that's really what I'm trying to achieve, is semantic over structural markup.

Check out:
canuckbison.bisonsystems.net/PmWiki/LocalChanges
to follow along with my site-specific updates to PmWiki.

Originally posted by Rich2k
Just a minor point that bugs me quite a bit. I don't think it's right to use the phrase table-free site when you are simply referring to ditching layout tables and using css layout instead.

It would be more accurate to call it a css layout site. Why do I think that distinction is important? Well simply because even under css layouts, tables are still perfectly valid for data... and indeed SHOULD be used.

I've seen some people go too far with removing tables and create entire data layouts entirely in css which is simply wrong, especially as the entire point of css layouts is for accessibility then using css layouts for data tables breaks that accessibility again.
No arguments here. It would be perfectly valid to use tables in the layout proposed by Eric, but they are simply unnecessary. This does happen to be a layout without tables, and therefore it is tableless. But by all means use them where appropriate - for tabled data and in instances where CSS rules will not reliably produced the desired results, which, thus far, is not the case here :)

Originally posted by BigBison
This problem with the navbar in IE just won't go away...
although everything appears to be set up the same way as when the header is separate (http://www.ericjbowman.com/header5.html).

OK, Rich. Table-free template it is! I want tables only within the main content area.
Mind if I pose this question elsewhere, using the real URL? (these people will not tolerate masks when trying to decipher someones source)

Originally posted by the_pm
Mind if I pose this question elsewhere, using the real URL? (these people will not tolerate masks when trying to decipher someones source)

Feel free.

Oh yeah, I noticed something just now.

''"word"'' — <span id="emphasis-italics"> — “word”
'''"word"''' — <span id="emphasis-bold"> — “word”

This is an explanation of part of your inline markup, right? If you intend for these elements to be applied to more than one word on a page, you must use class, not id! ID can only be used to identify one element per page, class can be used multiple times. So it should be:

''"word"'' — <span class="emphasis-italics"> — “word”
'''"word"''' — <span class="emphasis-bold"> — “word”

Only IE mistakenly allows for multiple occurences of id (and in turn ignores portions of DOM that allow you to identify elements by class names - stupid IE).

Sorry about the double post.

Remember, I was perfectly happy with a quite-simple table-based markup last Friday and I can always go back to it. But I want to learn...

In that respect, I'd say lesson learned number one is it's better to start fresh for a css layout rather than trying to convert a design you've conceived in tables.

Ahhh... my custom change in the php code needs a slight monkeywrenching job... thanks!

Also note the current absence of the sub-footer pictured in the last screenshot. I think you've just helped tremendously. Check back in a few hours, though! I seem to have 4 lines of php, plus a bunch of css and html changes to make.

These sorts of things take some getting used to, css is less ambiguous within the confines of a tabled layout, imo.

Oooh, looking better and better each time!

Here's the help thread I posted on hte WDG BBS if you want to jump in on it: http://www.htmlhelp.com/bbs/wdgbbs.cgi?action=display;num=132802

Before I delve back into this, one more note is that currently, two out of three browsers prefer Arial for <h2>. :confused:

Yep if you have more than one element with the same id it is invalid code and won't validate with an XHTML/HTML checker.

You should use class instead.

Originally posted by BigBison
OK, Rich. Table-free template it is! I want tables only within the main content area.


The only reason I pick up on it is because people unfamiliar with the level of detail we go into here about layouts may get the wrong idea and assume using the <table> tag for it's designed purposes is wrong.

CSS tables aren't fully supported in IE so you shouldn't use them (like it or not the VAST majority of all browser accesses are IE). What I mean by CSS tables is http://www.w3.org/TR/CSS21/tables.html

Originally posted by Rich2k
Yep if you have more than one element with the same id it is invalid code and won't validate with an XHTML/HTML checker.

You should use class instead.

Boy howdy that's frustrating. When I sat down and started working up my site from scratch the other day, I wondered specifically about this. Despite having (and checking) copious links to how-to information, I didn't come up with that fundamental tidbit...
...until after I'd gotten it wrong! :homer:

Yeah I've done that many times before, even though I know that it generates invalid code, I just forget :)

Thing is, you [i]wil[p/i] be punished by some browsers for this one. It's not one of those frowned-upon practices that browsers tolerate, it's flat out wrong. Sometimes you won't see it until you try to employ DOM techniques, and sometimes you'll see it right from the start in layout.

What about this?

<div id='wikitext'>

is a generated tag. Could its lack of double-quotes be my problem? I've just re-posted my code. Paul, thanks for the sample code, but I couldn't find anything in it I didn't have. There's some reason why my container breaks down.

I'm onto something thanks to Firefox DOM Inspector...
Now I'm getting somewhere...
But why is the page centered only in IE?
And why does the footer no longer work in Firefox?

Originally posted by BigBison
What about this?

<div id='wikitext'>

is a generated tag. Could its lack of double-quotes be my problem? I've just re-posted my code. Paul, thanks for the sample code, but I couldn't find anything in it I didn't have. There's some reason why my container breaks down.
Are you talking about the code I posted for your left side menu and content areas? I thought those were all sorted out. I didn't post anything for the top navigation yet. I'm waiting to see if there's any word back from the post I made on the WDG BBS first.

Originally posted by BigBison
I'm onto something thanks to Firefox DOM Inspector...
Now I'm getting somewhere...
But why is the page centered only in IE?
And why does the footer no longer work in Firefox?
You're probably relying on text-align to center your page, which only works on inline elements. Instead, wrap your entire page in a div with <div align="center"> at the top. Go back a few posts and you'll see this recommendation along with a warning about inheriting the center alignment.

And why does the footer no longer work in Firefox?
Maybe you left a tag or a quote open somewhere? Just a guess...

Originally posted by the_pm
Are you talking about the code I posted for your left side menu and content areas? I thought those were all sorted out. I didn't post anything for the top navigation yet. I'm waiting to see if there's any word back from the post I made on the WDG BBS first.

Sorry, Paul, I didn't need any of your code - it didn't lead to any changes. I am wondering why you changed my sliver.jpg into sliver.png, though? I'm still wondering about the single-vs-double quote thing. Here's the change that fixed it:

Added line 195:
<!—Page Left Fmt?—>
Deleted line 196:
<!—Page Left Fmt?—>

Yes, I had a comment in the wrong place - makes all the difference in templates for some wikis, cms and blogs. What was happening was the <div id="wikibody"> tag was being erased at runtime, which is why the elements didn't ever go into that container. Thanks, DOM inspector - although that should've been obvious to me looking at the code earlier.

How anti-climactic! :blush:

Sorry, Paul, I didn't need any of your code - it didn't lead to any changes.
No problem, though there was a big difference between our markup - we had two different elements carrying the left menu background. Moving it out to the parent element is what allows you to simulate two columns with the same height, something very challenging in most layouts that do not use tables for positioning elements.

Originally posted by the_pm
No problem, though there was a big difference between our markup - we had two different elements carrying the left menu background. Moving it out to the parent element is what allows you to simulate two columns with the same height, something very challenging in most layouts that do not use tables for positioning elements.

Yes, you're right, sorry - I did change the sliver to the parent div and that did come directly from you, and it's a clever technique.

Ok, I was more asking really, because if there wasn't a difference I was going to have to hunt down the external element that was causing a difference in layout between two similarly coded snippets. Are you links from the past few pages up-to-date?

Incredible! I can't even center a damn web page properly! I want my tables! :bawling:

Just posted the latest.

Are you sure you put everything inside the containing <div>? The footer might be outside of it. What's the URL of your updated page?

The URL in the OP for 'page history' also serves as an example of the latest update, as do all pages on the site. The footer is in the containing <div>, as evidenced by my inability to right-justify the text anymore.

Back to DOM Inspector in Firefox.

Here's the fix:

Changed line 149 from:
<div class=“wikihead” style=“height:35px; background:url(../images/plank.jpg)<snip />
to:
<div style=“height:35px; background:url(../images/plank.jpg)<snip />

Whahappa?

Near as I can tell,
padding:0; margin:0;
is all there is to it, I don't think the nav images are floated at this point.

Now could someone please reliably center my page? I'm about to...
Put it all in a centered table!!!!!!!!!!!!!!!

Oh, the "height:100%;" I ended up defining for the container div, is vital to getting the columns the same height.

As for centering:

Set your body to text-align: center; this will center it in IE.

Then, make a container div around everything on your page (and I mean everything), and set a width for it, then set it's margins to 'margin: 0 auto;' to take care of compliant browsers.

text-align:center does tend to behave quite differently cross browser unfortunately.

Centering in IE isn't the problem, it's those other browsers. Regardless of how the code appears now, I've put that center command in a variety of places, including the <body> tag, still no go. What works in one browser doesn't reliably work for the others.

The margin:auto command sonicgroup mentioned is the right one for every other browser. This tells *real* browsers that the margins of the container should fill the space around it, accommodating whatever padding elements it might see around it - in this case none. IE mistakenly applies text-align to block-level elements. While I'm in favor of an element such as block-align (which does not currently exist), the specs are clear as to how text-align is supposed to work, and IE screws it up, as usual. The margin:auto rule should replace the need for elements like <center> or even <div align="center">, though the latter is still acceptable.

If the margin: 0 auto; is not working, you need to ensure that you have an explicit width (either in pixels or %) set for your containing div. It won't work unless you specify a width.

Originally posted by BigBison
The gauntlet was thrown down and I took it up - wrecking a perfectly good table-based site template in the process, mind you! The question as to whether a salty old table dog like me can pick up table-free website design in a long weekend? Score one for tables! As you can see from the attached screenshot, I have two fundamental layout problems.

First, the footer.
I have worked many hours on the site footer, trying to get it to work without going back to the drawing board (Photoshop, in my case). I've said it before and I'll say it again - I'll miss good ol' "rowspan=2"! :) Anyway, I gave in and re-sliced the image in a way I thought would be easier to design table-free. The best I could do with the prior image slicing wound up with the text centered, not right-justified. All effort at right-justification yielded a white background behind the text only. I tried the old grassbar as both foreground and background images. Yup, I've been knocking my head against this for a few days now. The way the css stands now is clean, I felt it would work - float all footer images right, with a clear:both before each one. The first image clears the middle-section column effect. The second image clears the first floated image, or so I thought. Anyway, Firefox understands me...

Second, the left column.
I have the same problem whether I float the left column or the right. The floated content expands or shifts, whatever the appearance changes over the past few days there is one thing in common - the 700px width of the containing <div> seems to be meaningless. This I truly don't get - when working with images, they stay in their containers fine. When dealing with two columns of text, I seem to be stuck with a liquid layout. This is currently best illustrated in the IE pane of the screenshot - it centers the page as intended, but that darned menu is stuck over there on the left edge. I've tried this every which way, there must be something fundamental I'm missing.

Other problems, like column height, can wait as can the gap in the header - that's from extra blankspace output by the php app. For this little project, I've relaxed my site rules a touch. Open editing of the code (don't worry, it isn't dynamic) is allowed for all, I've provided two links - first is the code itself, second the history page - which highlights edits using diff.

canuckbison.bisonsystems.net/PmWiki/TemplateSource?action=edit
canuckbison.bisonsystems.net/PmWiki/TemplateSource?action=diff

Edit the code there, and your change will be highlighted in the history page. Cut and paste that snippet into this thread, if you want - that way the line number changed is highlighted for me to see and evaluate. Like this:



Attached is a screen shot showing the current output discrepancies on XP in Opera, IE and Firefox. The image highlights my frustration - unpredictable results, at least for the uninitiated like myself, across browsers.

Oh :deer:!
It would be so much smarter and cleaner to use css to position your css layers, i did this with my site, it took a very long time, but was worth it.

Example
.cssexample { top:how far u want it from the top; left:how far away you want it from leftpx;
U gotta put dimentions there also.

Originally posted by BigBison
Centering in IE isn't the problem, it's those other browsers. Regardless of how the code appears now, I've put that center command in a variety of places, including the <body> tag, still no go. What works in one browser doesn't reliably work for the others.

It's true actually, there doesn't seem to be a reliable way to center a <div> for instance using CSS other than in IE. In IE you wrap that div in another with text-align:center and the nested div is centered. That's the way I expect it work but it doesn't seem to in Mozilla.

Thanks for the help. I'm spending today reading up on css more than trial-and-error, I'll get back to centering I'm sure. In the meantime, any ideas why <h2> insists on displaying in Arial? Interesting to note, the <h2> stylesheet section hasn't changed, except the % value, since the table version. The table version displayed <h2> properly.

Originally posted by Rich2k
It's true actually, there doesn't seem to be a reliable way to center a <div> for instance using CSS other than in IE. In IE you wrap that div in another with text-align:center and the nested div is centered. That's the way I expect it work but it doesn't seem to in Mozilla.
Again, you shouldn't expect text-align to align a nested <div>. Text-align specifically aligns inline objects only. IE mistakenly uses it to align block-level elements too to make up for its inadequacies when it comes to CSS positioning and margin:auto.

The only thing confusing about text-align is that according to specs it's supposed to align all inline objects, including images. So it should have been called inline-align, not text-align, and I believe it should have a block-level counterpart. But IE getting something wrong should not raise any unreasonable expectations, unless it's your expectation that IE screwed up again ;)

Originally posted by BigBison
Thanks for the help. I'm spending today reading up on css more than trial-and-error, I'll get back to centering I'm sure. In the meantime, any ideas why <h2> insists on displaying in Arial? Interesting to note, the <h2> stylesheet section hasn't changed, except the % value, since the table version. The table version displayed <h2> properly.
In your stylesheet, you didn't put a space between Trebuchet and MS. It's TrebuchetMS, which the browser doesn't recognize, so it looks for Helvetica, and not seeing it, reverts to your default sans-serif, Arial.

I know you know how this works, I just thought I'd spell it out for anyone else who might be reading this thread who doesn't know :)

Originally posted by the_pm
I know you know how this works, I just thought I'd spell it out for anyone else who might be reading this thread who doesn't know :)

I do know how it works, but yeah spell it out! I've looked at that offending line half a dozen times without noticing that. Even tried putting quotes around it... back to monospaced font in the code editor! :blush:

Wednesday, September 8, 2004 @ 03:35 PM MDT. by ejb
Changed line 37 from:
font:bold 110% TrebuchetMS, Helvetica, sans-serif;}

to:
font:bold 110% Trebuchet MS, Helvetica, sans-serif;}

I think I've found a solution to centering my site. Check back later. Further comment on table-free: if you've been using tables for development for years, some of the standard css layout practices just feel so... kludgy.

Originally posted by the_pm
Again, you shouldn't expect text-align to align a nested <div>. Text-align specifically aligns inline objects only. IE mistakenly uses it to align block-level elements too to make up for its inadequacies when it comes to CSS positioning and margin:auto.

The only thing confusing about text-align is that according to specs it's supposed to align all inline objects, including images. So it should have been called inline-align, not text-align, and I believe it should have a block-level counterpart. But IE getting something wrong should not raise any unreasonable expectations, unless it's your expectation that IE screwed up again ;)

Well quite, but if you won't use text-align you have to resort to using the align attribute of <div> it's very annoying.

Originally posted by Rich2k
Well quite, but if you won't use text-align you have to resort to using the align attribute of <div> it's very annoying.
Yes - until IE catches up with the rest of the modern world, this will be the only option. But once you get the hang of it, it's not so bad, and it'll enjoy just as much future browser support as the same thing in tables, so all-in-all, things could be worse.

Wednesday, September 8, 2004 @ 07:04 PM MDT. by ejb
Changed line 137 from:
<div id=“container” align=“center”>
to:
<div id=“container”>

This latest one applies text-align:center to container.

Wednesday, September 8, 2004 @ 07:00 PM MDT. by ejb
Changed lines 136-137 from:
<body style=“text-align:center;”> <div id=“container”>
to:
<body> <div id=“container” align=“center”>

Yields the same result any of three ways - only centers in IE.

Originally posted by the_pm
Are you sure you put everything inside the containing <div>? The footer might be outside of it.

I'm working on something along those lines, I see what you're thinking. However, with the aforementioned 100% height requirement of my body div, moving footer or sub-footer out of the container (holding "body") pushes them below the bottom of the page, unacceptable for this page (http://canuckbison.bisonsystems.net/PmWiki/PmWiki).

Trying something...

OK, I've cleaned up the code a bit. I was at a point where only IE displayed the site centered. So I added the following to body first, then to container as follows:

Wednesday, September 8, 2004 @ 11:02 PM MDT. by ejb
Added line 54:
margin:0 auto;

The result? Now the site centers -- but only in Firefox.

Now centering in Firefox and Opera, but not IE...
that's with margin:0 auto; plus align=center in the container div.

No, you can't always get what you want... Take it Mick!

I believe I've tried everything mentioned in this thread... I think...
So now it's my turn!

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Foo</title>
</head>
<body>
<div align="center">
<div style="height:300px ; width:500px ; background:#900 ; color:#FFF ; margin:auto">Foo</div>
</div>
</body>
</html>
Try that in your browser of choice, and then go from there. I'll bet you can make it work. It centered the fixed width box in IE, K-Meleon, Moz. and Opera just fine.

Originally posted by the_pm
It's TrebuchetMS...

Actually, it's "Trebuchet MS" as font names with spaces are supposed to be enclosed in quotes.

Originally posted by the_pm
Try that in your browser of choice, and then go from there. I'll bet you can make it work. It centered the fixed width box in IE, K-Meleon, Moz. and Opera just fine.

Stay tuned...

Almost, but not quite... C'mon, Firefox, stay with me here!
Give me a bit to figure this one out...

edit...
I just measured the pixels - y'know that 130px right-padding we used to align the text in the footer? Mozilla has put that padding outside the div - centered beautifully, of course.

The difference from the screenshot on the current site is I changed padding-right to margin-right, just for kicks...

Here's the screenshot of the change:

Actually, it's "Trebuchet MS" as font names with spaces are supposed to be enclosed in quotes.
I didn't want to say it - sounded too nit-picky at that point.
I just measured the pixels - y'know that 130px right-padding we used to align the text in the footer? Mozilla has put that padding outside the div - centered beautifully, of course.
That's how it's supposed to work (hence the broken IE box model). I'm working on it - these methods definitely favor fluidity. It's tougher when you're faced with fixed width elements :confused: That's not a knock on the design, just a statement of fact...

Originally posted by the_pm
...That's not a knock on the design, just a statement of fact...

I think that's the conclusion I'm coming to. If you want a fixed design, stick with tables (although I'm determined to see this through), however if you're thinking fluid, definitely css layout. I'm so sick of it I'm spending the night image editing.

I suppose it wouldn't be the largest infraction in the world if you wrapped your CSS-driven layout in the single cell of a single table.

It just feels so...dirty. I dunno - but it's not invalid, that's for sure.

This might be one you'll want to post on the WDG BBS. They love trying to figure this stuff out. http://www.htmlhelp.com/bbs

I'd post it myself, but why involve a middleman? If you do it, I'll watch the thread - I'm very curious myself.

Originally posted by the_pm
It just feels so...dirty. I dunno - but it's not invalid, that's for sure.

What feels dirty is having a 700x1 graphic with 698 white pixels...

Originally posted by BigBison
What feels dirty is having a 700x1 graphic with 698 white pixels...

??? Why not a 2x1 px graphic repeated on an axis with a white background? That's the clean way out :)

No, what's really dirty are 1x1 spacer GIFs. :eek:

Originally posted by the_pm
??? Why not a 2x1 px graphic repeated on an axis with a white background? That's the clean way out :)

Do who to the what now? :homer:

Originally posted by the_pm
I suppose it wouldn't be the largest infraction in the world if you wrapped your CSS-driven layout in the single cell of a single table.

:eek: Sacrilege!!! Now I'm gonna hafta get old-school on ya...

Originally posted by sonicgroup
No, what's really dirty are 1x1 spacer GIFs. :eek:

No knocking spacer.gif! Look at my last update. If the browsers can't agree on what "padding" means via stylesheets, I can promise you they do agree on how to display a 130x140 spacer.gif!

:spiny: Spacer Gif Is Your Friend!

Notice how my footer is fixed? Except...

Why won't my footer text center vertically?

Originally posted by BigBison
No knocking spacer.gif! Look at my last update. If the browsers can't agree on what "padding" means via stylesheets, I can promise you they do agree on how to display a 130x140 spacer.gif!


Quite don't complain at people using these things for layouts when the browsers themselves react differently to the way it should be done.

So there's nothing "invalid" about using my ol' buddy, then?

I still use spacers for things, but then I'm not a CSS layout fanatic :D

In my other threads, I've (with a little help) re-worked the code from the gound up in xhtml 1.1. Regarding the problems above, I don't know whether it's the new doctype or the container <div> back in the code, but I have now solved the prior padding-right problem (in the footer) without using blank.gif.

Which is not to say my little buddy is gone!

There he is again, steadfastly giving me 10px of padding-top this time. The footer div is fixed at 140px height to display the entire background image. If I spec padding-top:10px it makes sense to cut the height down 10 px as well. Except in IE, the result cuts the graphic.

Today's mission, should you choose to accept it:

Eliminate spacer gif!

bronco.bisonsystems.net/rc6.html