Stretching a div to the bottom of another div

[x-byte]

I'm trying to make the menu div stretch all the way to the bottom a the content div. I have a little idea on how to do it though... but I'm a little stuck. The way I use now only stretches the menu down to it's text content..

The CSS code is like this for the menu and content:

#menu{
position: relative;
float: right;
width: 150px;
height: 100%;
height: auto;
min-height: 100%;
border-left: 1px dashed #336699;
border-bottom: 1px dashed #336699;
background-color: #EFF4FA;
text-align: left; /*corrects for IE hack*/
clear: left;
}

#content{
position: relative;
float: left;
height: 100%;
height: auto;
min-height: 100%;
width: 537px;
text-align: left; /*corrects for IE hack*/
clear: left;
padding: 3px;
background-color: #FAFAFA;
}

But I think I can solv this by using float: left on the menu and still manage to place it to the right of the content. Or am I totally wrong here?

If you want to look at the site, you can visit here:

http://www.x-byted.tk

The entire CSS file is placed here:

http://home.no/x-byted/stylemain.css

[lnmnky]

You can script it or

frig it so that the dotted line and blue is actually a background image of the content that spans on the right hand side top to bottom.

[x-byte]

You can script it or

frig it so that the dotted line and blue is actually a background image of the content that spans on the right hand side top to bottom.

585248735[/snapback]

Simular to this example?

background: url(background.png) top center repeat-y;
height: 100%;

[lnmnky]

-bYtE,Jan 7 2005, 12:16]Simular to this example?

background: url(background.png) top center repeat-y;
height: 100%;

585248772[/snapback]

This is on the content div ? (I hope)

I would say "top right" if it's the blue dotted. I wouldn't put a height as its content makes the height.

[x-byte]

This is on the content div ? (I hope)

I would say "top right" if it's the blue dotted. I wouldn't put a height as its content makes the height.

585248865[/snapback]

I've tried some variantions of this but I can't seem to get it right.. I'm not sure if you understand what I wanted though.. so I made a screenshot of what I want.

[lnmnky]

Make an image that acts as the blue menu div background and border.

Like this attachment.

But have it as a background image on the content div, and "top right repeat-y"

[AJCrowley Esq]

I haven't thouroughly examined your page, so this doesn't necessarily apply. But there seems to be a trend of late of using divs where tables are the appropriate solution. Tables are the absolute basis of good HTML layout, and should be learned thouroughly before playing with divs. As a general rule, if it can be done with a simple table, using divs and css is simply the wrong way to go.

From what I interpreted of your original question, a table is what you're after, and in a table, all cells in a row are the same height (except those that span multiple rows, but that's another story), and switching to a table may both be appropriate, and solve your problem instantly. If I misunderstand, I apologize, but I do feel that this needed to be said in some thread, as a lot of people seem to be going layer crazy when it's not appropriate (think of it like having a 20 minute long flash intro with no skip button, and annoying midi music in the background of your page with a hundred animated gifs of skulls scattered randomly over the page :)).

Hope you find this helpful, if not, I hope someone does. :)

AJC

EDIT: I just reread your initial post, and for menus with both an on and off state, this obviously isn't applicable, and divs are the solution. I still feel that what I said needed to be said though.

[x-byte]

Make an image that acts as the blue menu div background and border.

Like this attachment.

But have it as a background image on the content div, and  "top right repeat-y"

585248961[/snapback]

I can't seem to make that work for some reasons.... :blink:

I've added this to the content div:

background-image: url('/images/background.png') top right repeat-y;

But it doesn't show... Am I having a bad day or what?

I haven't thouroughly examined your page, so this doesn't necessarily apply. But there seems to be a trend of late of using divs where tables are the appropriate solution. Tables are the absolute basis of good HTML layout, and should be learned thouroughly before playing with divs. As a general rule, if it can be done with a simple table, using divs and css is simply the wrong way to go.

From what I interpreted of your original question, a table is what you're after, and in a table, all cells in a row are the same height (except those that span multiple rows, but that's another story), and switching to a table may both be appropriate, and solve your problem instantly. If I misunderstand, I apologize, but I do feel that this needed to be said in some thread, as a lot of people seem to be going layer crazy when it's not appropriate (think of it like having a 20 minute long flash intro with no skip button, and annoying midi music in the background of your page with a hundred animated gifs of skulls scattered randomly over the page :)).

Hope you find this helpful, if not, I hope someone does. :)

AJC

EDIT: I just reread your initial post, and for menus with both an on and off state, this obviously isn't applicable, and divs are the solution. I still feel that what I said needed to be said though.

585249000[/snapback]

I appriciate your suggestion. DIV/CSS is my choice for design now, although I've been using tables for design before. I know how to fix it that way. But the code etc. is so much better without tables so I prefer this as it is :)

[lnmnky]

Tables are the absolute basis of good HTML layout.

What have you been reading? Get with the times.

[lnmnky]

background-image: url('/images/background.png') top right repeat-y;

585249040[/snapback]

you're not on relative to root hosting, you need add the folder name /xbyted/...

or you need to do it long hand

background-image : url("");

background-position : top right;

background-repeat : repeat-y;

[AJCrowley Esq]

What have you been reading? Get with the times.

585249258[/snapback]

I haven't been reading anything. I've been developing websites and web applications since 93, have worked for many major companies, including Intel, Peterbilt and Century 21, and am currently a teacher of web development at a reputable and respected college.

I don't know what your credentials and experience are, and they may be better and more impressive than mine, and it's true that credentials aren't everything, there's people that have been making crap for 10 years, and people who have been making incredible sites for a year. That said, I stand solidly by what I say, and I know that most reputable design houses would agree. You are entitled to your opinion, and maybe you're correct, and the experts are wrong (majority doesn't mean right), but I think that time and experience have and will continue to prove me correct on this point. I'm more than happy to intelligently debate it further if you have a reasonable point to make other than a moronic comment such as "get with the times".

[FiREFLi]

Tables are the absolute basis of good HTML layout...

585249000[/snapback]

oh dear. :pinch: tables used to be the way to go. not any more though.

[AJCrowley Esq]

Is there a reason that you think tables are no longer the way to go? On what grounds and authority do you base this opinion? Has it been reflected by anyone that I might recognize as a good authority on such matters such as W3C? Is it their solid cross browser cross version consistency? Is it their ease of use compared to layers and css?

There's absolutely a place for layers, general layout and formatting is not it. I'll be happy to concede my point if you can show me that your opinion is based on good reason, but I doubt that it is.

[lnmnky]

I haven't been reading anything. I've been developing websites and web applications since 93, have worked for many major companies, including Intel, Peterbilt and Century 21, and am currently a teacher of web development at a reputable and respected college.

I don't know what your credentials and experience are, and they may be better and more impressive than mine, and it's true that credentials aren't everything, there's people that have been making crap for 10 years, and people who have been making incredible sites for a year. That said, I stand solidly by what I say, and I know that most reputable design houses would agree. You are entitled to your opinion, and maybe you're correct, and the experts are wrong (majority doesn't mean right), but I think that time and experience have and will continue to prove me correct on this point. I'm more than happy to intelligently debate it further if you have a reasonable point to make other than a moronic comment such as "get with the times".

585249316[/snapback]

Tables were never created to provide layout to websites. It is through misuse and bad practice that they have been used for such.

I understand that there was no alternative for layout pre-css and pre NS4 and IE4, but as soon as an alternative for the misuse of data tables for layout was found it should have ceased.

"Get with the times", ok bad wording.

Follow the standards set by the w3c then.

Tables should contain data. Nothing more, nothing less, and they were never intended to hold anything else.

As for credentials, I'm not going to say what I do, or how long I've done it. It's not necessary. I have the w3c to back me up.

[AJCrowley Esq]

Ok, if you can show me a link on w3c where they state that layers are better used for formatting than tables, I will accept your claims (though I doubt that I will change my methods, as they have worked well for me for some time). My goal in stating my credentials was not to start a ****ing match about who is better qualified to make such a statement, it was merely to let you know that my opinion is based on something real.

At the moment, someone that would use layers where tables should (in my opinion) be used would strike me as someone that is used to using a visual editor such as Dreamweaver, rather than real coding.

[FiREFLi]

Is there a reason that you think tables are no longer the way to go? On what grounds and authority do you base this opinion? Has it been reflected by anyone that I might recognize as a good authority on such matters such as W3C? Is it their solid cross browser cross version consistency? Is it their ease of use compared to layers and css?

There's absolutely a place for layers, general layout and formatting is not it. I'll be happy to concede my point if you can show me that your opinion is based on good reason, but I doubt that it is.

585249362[/snapback]

the w3c saying it good enough reason. I can see your point about tables being easier but you'll never get good with css if you don't start sometime. It's definitely worth doing, I only just made the transition and I'm still no good at it but I much prefer it already.

[AJCrowley Esq]

I have a pretty good knowledge of CSS. I use it for many things, including formatting of layout tables, and layers account for a tiny percentage of what comprises CSS. While a good way to learn what you can do with CSS and DHTML, are by no means in my opinion a replacement for traditional layout methods, but an enhancement.

Working with layers and CSS is no more significant or educational than using CSS to format your tables, in fact, it is my experience that you can do a lot more with tables and CSS for static type layouts than can be done with layers and CSS. It seems to me that you are somehow confused or misinformed as to the nature of CSS - it is no more applicable to layers than any other HTML element. Layers do not equal CSS.

All of that said, I have yet to see any suggestion from W3C that layers are more suitable for general layout purposes than tables (and yes, I did just search their site for such a claim).

Edit: Censorship of naughty words here seems a bit harsh. The popular contemporary vernacular for the noun urine, and the verb urinate I thought was acceptable language today, I'm pretty sure I've seen it on shows such as the Simpsons (and what gets past the board of standards and practices has to by definition be extremely tame). It's certainly no harsher a word than "crap", which seems to print just fine without being replaced by asterisks. Oh well...

Edited January 7, 2005 by AJCrowley Esq

[Dessimat0r]

What AJCrowley Esq says is true. CSS defines the style, and HTML defines the structure and the data (although there is a technology being developed to split the data and the structure). If a table is the best structure to use for your data, then you use it! If your data is tabular, then you use a table -- it is as simple as that.

It goes without saying that most page layouts are tabular, so tables should be used.

[lnmnky]

Ok, if you can show me a link on w3c where they state that layers are better used for formatting than tables, I will accept your claims (though I doubt that I will change my methods, as they have worked well for me for some time). My goal in stating my credentials was not to start a ****ing match about who is better qualified to make such a statement, it was merely to let you know that my opinion is based on something real.

At the moment, someone that would use layers where tables should (in my opinion) be used would strike me as someone that is used to using a visual editor such as Dreamweaver, rather than real coding.

585249405[/snapback]

W3c never told anyone which was better or worse. They never told you to use tables for layout. So why do you? Because it works, and because I have for years, isn't a reason or an excuse.

Here's a link were they clearly state that tables are for data... be it images, text, links. But it should strictly be a data grid.

http://www.w3.org/TR/REC-html40/struct/tables.html

W3c set the standards, and we choose if we want to follow them. It's people like www.alistapart.com that follow the standards and make recommendation on how to layout your website properly, whilst following those said standards.

It's people that are so happy that tables work that we are stuck with people using them (for layout) 4 or 5 years after they were classed as redundant for layout purposes.

The argument about browser compatibility is seriously flawed. A correctly crafted CSS layout site will degrade gracefully to all access devices. They will degrade properly on a mono-chrome display, and they will function correctly on a Braille device that the visually impaired use.

Using tables for layout is only causing more problems for people, especially the impaired. Ever time their screen reading software comes to your new layout table, they have little or no idea about the logical semantic mark-up and layout of your site.

The content in tables may appear to be flowing beautifully down the page in columns, but the mark-up of the page actually reveals it spread into many rows, in many columns. How is my blind Nan going to make sense of your website?

Trust me, it's not a matter of opinion, but using such a dated technique for mark-up by the masses can only lead to slower web development as a whole. If everyone followed the standards, we could ditch worrying about cross browser support, because the website would still be accessible to everyone by its natural semantic mark-up.

I'm through debating it; I'm severely off topic also. Sorry to the mods.

[AJCrowley Esq]

W3C do state that tables are for the tabular display of data and images (which I would consider to mean formatting). They also make frequent references to "layout tables" throughout their site, which would seem to imply their endorsement of said technique, though I see nothing similar for layers.

It's the fact that tables work best that is the reason we're still using them, and nobody that I'd class as worth listening to has EVER described tables as "redundant". Cross browser compatibility, while a diminishing issue, is still an issue, and one which the vast majority of clients take seriously. If you look at all of the biggest and most respected sites on the internet, I doubt you'll find many, if any that use layers as a primary layout tool, and for good reason - it's not what they're for, and they're not as well suited to the purpose as tables.

It's apparent that you've made up your mind on this point, and it's not open to change, and frankly, it makes no difference to me whatsoever, though I am trying to present as strong a case as possible to prevent people from following your misguided and ill informed example. If you ever get work with a respected web design/dev house, just make sure you go with the tables method, unless you really want to be told to start again from scratch.

I know you said you're through, but if you do want to debate further, I am happy to. It's my experience that people concede debates when they realize that their point is looking weaker and weaker, but they refuse to give it up. ;)

Happy authoring,

AJ.

Edit: I don't really consider it to be off topic, it's a valid debate relevant to the initial post, and of value to anybody getting into authoring and looking to improve their HTML skills.

[lnmnky]

I'm defeated, anyway....

If you look at all of the biggest and most respected sites on the internet, I doubt you'll find many, if any that use layers as a primary layout tool, and for good reason - it's not what they're for, and they're not as well suited to the purpose as tables.

The major sites simply do not want the risk. Last time I looked, ESPN had made the jump, and were very well praised for it.

They know that it works for 99% of the people, as tables will always work for PC based browsers, no matter what version they are running.

It's apparent that you've made up your mind on this point, and it's not open to change, and frankly, it makes no difference to me whatsoever, though I am trying to present as strong a case as possible to prevent people from following your misguided and ill informed example.

I am open to change, I just see it as a step back. I've been through all the table based techniques, the pixel gif spacers, the faux curved borders, the fake shadows, and it's just a waste of time. It's all possible through accessible, light weight, search engine friendly, browser compatible css.

And if it's not compatible, you let it degrade gracefully, and the user can still get on your site, and get what they need.

If you ever get work with a respected web design/dev house, just make sure you go with the tables method, unless you really want to be told to start again from scratch.

I'm not sure what dev house means, but I work as a coder for a uk financial. I'm not a designer, I'm a code monkey, I do the front end mainly from other people's designs. Javscript, ASP, ASP.net, CSS, of course HTML. If you do care to see what I've been heavily involved in, most of the templates, then it's here.... http://www.nationwide.co.uk

We are held back from going totally xHTML through our browser support policy and the fact the the secure bank side runs a lot of legacy COM objects that have hard coded back ends the produce html. I work on the non-secure-bank side. And the real techies don't know how to go tableless.

Beware, there are browser hacks in there and it is quite messy. Not my fault, I'm one of 20 devs and I best not comment on them. I try my best, but we just can't ditch the old browsers, have moved from tables, have to increase search engine hits, and use a content management system. It does look bad in NS4 etc. but it's usable. I wanted to lose the layout etc and have it all flat for x4 browsers, but they didn't want the sudden loss of consistancy.

The next redesign will hopefully be able to do a non-skinned version for x4 browsers. I hope.

I know you said you're through, but if you do want to debate further, I am happy to. It's my experience that people concede debates when they realize that their point is looking weaker and weaker, but they refuse to give it up. ;)

Yes, I give up, but it's my lack of execution rather than my argument. I'm not the best at stating a valid case, I don't know the word for it. Take a look over alistapart, they have some good write ups on the benefits of losing layout tables.

Happy authoring,

585249516[/snapback]

Thank you, it's all good fun.

[AJCrowley Esq]

It's a risk, and that's the point. A personal homepage is one thing, but when a website is mission critical, compatibility is a huge issue.

By dev house, I mean a company that specializes in designing and programming various forms of media, primarily web as implied by the dev, but usually also print, video etc. My own feeling is that it also implies a company of at least 10-15 people, any smaller, and I'd use a different term, but that's not "law", that's just the way I like to word things.

I really don't see how layout tables can be considered a step backwards, that to me is akin to calling HTML a step backwards, as compared to Flash, I just can't make sense of it.

The site you linked seems to be a nice clean design, and well written. As is obvious by now, I would favour a table layout, but your div layout works great in my, and 99% of other peoples' browsers, and that's a choice that Nationwide had to make. I do think that the current lack of support for xHTML is a shame, but I'm reasonably comfortable that it will come in time, and I do make a point of teaching my students good xHTML coding practices.

I was trying to provoke you into further debate, but it seems that you're happy with your case as stated, and I can respect that, though I would like to understand more why you favour that method, because at the moment, all I know is that you do favour that method, and the only reason seems to be that "it's the future", which is highly debatable.

Anyway, it's been an interesting discussion, and hopefully between us we've covered enough to give people who hang in the balance enough information to make the choice that's right for them, though I think we're living proof that those that are decided, are decided (and no, I'm not resistant to change, I love to employ, and have pioneered many new web technologies).

It's been fun, and I'll take a look at the alistapart site and see what they have to say, despite my skepticism, because someone who does not at least look into both sides of such a debate is not worthy of making a statement on which technique is better practice.

Best of luck in your future endeavours, and I'll see you around the forums.

AJC

[lnmnky]

I really don't see how layout tables can be considered a step backwards, that to me is akin to calling HTML a step backwards, as compared to Flash, I just can't make sense of it.

I think of it as a step back, because all the xHTML guidelines that are coming out, are heavily steering people toward using code that produces a logical semantic site. Like Hx for headings, proper list markups, even stuff like [address] tags, some it seems (lightly) implied that you should use the TD for only containing table data. Although I understand, I'm guilty myself. You have to produce something that can deliver. A tableless is pointless if it's poorly coded and only works on the new version of Mozilla (for example)

The site you linked seems to be a nice clean design, and well written. As is obvious by now, I would favour a table layout, but your div layout works great in my, and 99% of other peoples' browsers, and that's a choice that Nationwide had to make. I do think that the current lack of support for xHTML is a shame, but I'm reasonably comfortable that it will come in time, and I do make a point of teaching my students good xHTML coding practices.

The risk was high, but we have coded it so that people wouldn't even know otherwise.

The reason I went tableless (as many others have) is to try and get everything that is visual into the style sheet, and only have raw data (content) in the HTML. The separation of data and visuals is more important these days with more use of databases, xml, flash, increase in access devices.

We have a high respect for people browsing with accessibility issues (the impaired). We try to label all our forms correctly with labels etc, and the tables only get in in the way of that. (when using screen reading software)

Have you used a screen reader and turned your monitor off and not used your mouse? It is quite an interesting practice. It made me realise how much I take for granted on websites, and users of websites.

There is also the search engine optimisation. the search engines will look for the headings etc, and obviously prioritise them. If the search engine can get to your content quicker, it is ranked higher, the tables we used to have only got in the way of our content.

Alot of code has been saved on our site through going tableless. We get millions of hits, and by even cutting out 10k of code per page, it can save a load of bandwidth (even though it's not an issue we have).

I was trying to provoke you into further debate, but it seems that you're happy with your case as stated, and I can respect that, though I would like to understand more why you favour that method, because at the moment, all I know is that you do favour that method, and the only reason seems to be that "it's the future", which is highly debatable.

I'm not the best at debating, but I don't like to be obviously giving up either lol.

Best of luck in your future endeavours, and I'll see you around the forums.

AJC

585249674[/snapback]

Cheers, take care. My day is over now. See you around.

[RufioPan]

Interesting discussion, guys.

I felt it necessary to add one more point of concern when comparing table-based layouts to xHTML/CSS layouts. No one seemed to mention the added flexibility of the xHTML/CSS combination.

Rather than propogate bad practises such as using table-based layouts, I feel that xHTML/CSS allows for more flexibility, and will aid the entire design industry by pushing corporations and users towards more modern browsers that provide a better experience. The flexibility especially comes into play when considering that with a simple CSS change, you can revamp the entire layout of your site, whereas a table-based layout change comes at a higher time/effort cost. Changing a table-based layout can potentially mean redesigning your entire table grid structure, or at the very least entails making more code changes than you would with an xHTML /CSS combination. That is the benefit of separation of content & layout.

I think the sophistication of the xHTML/CSS specs have reached a point where the only advantage of a table-based layout is the fact that you can have columns of your layout all match height. Again, this advantage is easily outweighed by the advantage of the flexibility of the xHTML/CSS combination.

Having said all this, I still believe any competent web developer/designer should understand and know about table-based layout and structure, but as an industry we should be pushing away from that archaic design practise and moving towards more flexible, extensible, and easily manageable practises.

[AJCrowley Esq]

I still don't understand the notion that tables and CSS are mutually exclusive. Though it does take marginally more code to produce tables, layers do still require the content to be placed within tags that restrict its total freedom of layout - if that is your goal, then XML and XSL might be better suited to what you're trying to accomplish.

As for the bandwidth issue, a valid point, though if you're that intent on saving bandwidth, lose all of the line feeds and spacing/indentation in your code, it will save you further precious bandwidth (not being sarcastic, I do understand how much bandwidth costs for a site that receives several million hits a month). It's clearly not as much of an issue as image optimization, which is frequently inadequately handled, and content compression (gzip or similar), particularly in IIS. The single biggest bandwidth saver on your average site is going to be making sure that you're sending the resulting document to the client in a compressed format, and as we know, because these documents are text based, they compress extremely well, and for a page of any significant size, will mean that you're using a tiny fraction of the bandwidth (find a text file and zip or rar it up, you'll see what I mean).

As I stated before, I think XHTML is wonderful, and it's unfortunate that the standard has not received more support, but XHTML is in no way conducive to the use of layers over tables, and exists completely independantly of CSS, which has the exact same implications and applications in HTML and in XHTML. It sounds like the people who favour the layer approach fall into one of two categories:

a) You think that layers are somehow related to CSS moreso than other HTML elements, and/or that XHTML and CSS are somehow more closely related than HTML and CSS. If this is the case, I suggest you spend more time with CSS, CSS doesn't care about HTML or XHTML, and it certainly doesn't care about layers vs tables.

b) You are using the wrong technique to acheive what you want. If you want a discrete separation of data and format, XML formatted with XSL is what you're after in my opinion, and would suit your needs far better. Don't forget that tables are just as controllable with CSS.

If you don't feel that you fall into one of these categories in any way, then I'd be interested to hear your reasoning, but so far, these are the only two arguments I've seen. I'll say it one more time to be sure:

CSS is just as applicable to tables as it is to layers, it doesn't care.

CSS is not the same thing as XHTML, CSS should treat an HTML document EXACTLY the same way it treats an XHTML document.

This is a very interesting discussion, but as I've said, my impressions from the other side so far are either that they're misinformed, or using the wrong technology to meet their goals.

[elliot]

XHTML isn't just about closing all your tags and quoting all your attributes. It goes hand-in-hand with semantic markup, seperating the layout/design from the content, and etc. Tables are neither of those. You're kidding yourself if you think throwing an XHTML doctype onto your HTML page makes it any better, that somehow your page follows web standards, it doesn't.

About whether W3C support layout tables, well, let's just say it isn't a coincidence there isn't a single table on their homepage...

People who use tables fall into two catagories also

a) They don't know any better.

b) They don't know how to adapt.

Edited January 7, 2005 by elliot