...

applied to the H1/H2. This makes the client treat what would otherwise be a block-level object as if it were just running text, more-or-less, so anything else would nestle up against it normally. You'd probably then need to ensure that your next style (for following paragraphs, etc) had a clear:left in it or you forced a <br /> after your "small" text or something (or wrapped the

<h1>/small text combo in a <p></p>).

Thanks, that's definitely a possible approach, I'll have a play.

... and I'm nearly there now, I just have one annoying niggle to sort out.

I want to change the colour of the second smaller part of the heading but can't seem to override the inherited colour setting. Firefox's "View Source" shows that the HTML for the heading is:-

<div class=blogpage>

<h1 class="sectionedit1"><a name="heading_1" id="heading_1">Heading 1</a></h1> <div class="level1">

</div>

<h5><a name="heading_5" id="heading_5">Heading 5</a></h5> <div class="level5">

Paragraphs of text here

</div>

..... lots of other stuff

</div>

The level1 and level5 div sections are put there by the Wiki, not by my additions to create the two-sized heading, but I'm able to set them to "display: inline" too and thus the h1 and the h5 headings appear on the same line as required.

The relevant CSS is:-

div.dokuwiki h1 a, div.dokuwiki h2 a, div.dokuwiki h3 a, div.dokuwiki h4 a, div.dokuwiki h5 a, div.dokuwiki a.nolink { color: __text__ ; text-decoration: none !important;

... ... ...

div.blogpage h1 {font-size: 220%; margin-left: 0px; font-weight: bold; border-bottom: 1px solid __text__; display: inline; } div.blogpage h5 {font-size: 100%; margin-left: 0px; font-weight: bold; display: inline; color: green;}

div.level1 { display: inline; }

The colour of the h5 bit is staying determinedly at __text__ rather than the green that I'm setting (I don't really want it green, it's just easier for testing). I assume that the colour is being inherited from the div.dokuwiki setting. Is there any way I can force the div.blogpage setting for the colour to override the other? The dokuwiki div is 'outside' my blogpage class.

(N.B. I can't set the h5 class explicitly as that part of the HTML is generated by the Wiki)

I'm not very good at understanding this CSS/inheritance stuff! :-)

Following Chris' CSS question, I have a (hopefully) quick one of my own.

How to I convert the following table code to CSS (on the grounds that tables are bad): <table> <tr><th colspan=2>Heading</th></tr> <tr><td>Menu</td><td>Content</td></tr> <tr><td colspan=2>Footer</td></tr> </table>

To keep it simple I haven't styled the table but assume it represents the whole "page" of a fairly typical layout where there's a header and footer, and between them a menu on the left and content on the right.

It's staightforward to do this with floating DIVs except that with the table, the menu and content cells are (by definition) the same height, so if (for example) I style the cell backgrounds then the whole of the cell gets coloured. With floating DIVs I get whitespace around the menu and content DIVS. Also, I'm not sure how to convert a table of width/height 100% to a CSS equivalent.

I know this is basic stuff but when it comes to CSS I just don't "get it" :-(

On 11/05/11 14:03, Greg Thomas wrote:

Tables are not "bad" - they are good for presenting tabular data. OK, so they shouldn't be used for layout, which is what you are trying to avoid.

Indeed, correction accepted!

There's an example (with a better explanation than I could give) at http://css.maxdesign.com.au/floatutorial/tutorial0816.htm

This doesn't actually work as expected if the content is shorter than the menu, see example here: http://www.more-solutions.co.uk/test.html This is the exact example from the above tutorial except that the content has been reduced and background colours added to the left and right sections. Note that the line (border) between the left and right sections is only as long as the right-hand content, and the background colours don't fill the whole areas unless the content does.

If this were a table-based layout, the left and right "cells" would by-definition be the same height.

Of-course I can fix this by forcing the height, but that has far more disadvantages than benefits.

On 12/05/11 10:50, steve-ALUG@hst.me.uk wrote:

But original website's text says

"We will also apply a border to the left of the "content" div. This could be a problem if the "leftnav" div is longer than the main content. If this is the case, the border can be applied to the right side of the "leftnav" div instead of the "content" div."

That's fine if you know in advance which is bigger, but in many cases that's a luxury that can't be relied on, and in any case it doesn't solve the problem of the background colour not filling the "cell".

On 12/05/11 10:51, Greg Thomas wrote:

Position is Everything.

No, I mean the web site! There's an example of how to set "columns" to equal height at http://www.positioniseverything.net/articles/onetruelayout/equalheight

Thanks, this does seem to address the problem, although it is a very messy hack by the looks of things!

I haven't tried it yet, but I can see problems when I go to my next stage: allowing the left menu to have it's own vertical scrollbar if needed. (The left menu will be a JavaScript tree menu and to be useful on small screens it needs to scroll independently of the main content.) In a table cell I should be able to make this happen using overflow:auto but the hacks at positioniseverything.net are already using overflow to achieve the column effect.

I understand why tables are bad for layout in theory, I really do. But given how hard they are to work around in CSS in practice why should I be ashamed of reverting to tables for layout? Why don't we just have <layout><lr><ld></ld></lr></layout> (functionally equivalent to table/tr/td but providing the distinction for all the valid reasons that table is bad for layout)?

Grrrrr.......

A while back, on 12 May 2011 15:17, Greg Thomas Greg@thethomashome.co.uk wrote:

On 12 May 2011 15:04, Mark Rogers mark@quarella.co.uk wrote:

> Why don't we just have > <layout><lr><ld></ld></lr></layout> (functionally equivalent to table/tr/td > but providing the distinction for all the valid reasons that table is bad > for layout)?

Well, it's still the same problem you have with tables; HTML is supposed to be all about content, but you're describing layout.

OK, coming back to this, is there anything "wrong" with the following layout? You will recall that my original question was:

How to I convert the following table code to CSS (on the grounds that tables are bad): <table> <tr><th colspan=2>Heading</th></tr> <tr><td>Menu</td><td>Content</td></tr> <tr><td colspan=2>Footer</td></tr> </table>

So, given that I want table-styled layout but shouldn't use table tags to describe the layout, and the following seems to work, is it "acceptable" to the purists? The HTML seems to be pure content now, and the CSS contains all the layout information, so it seems like it should be OK but it seems too easy?

<html> <head> <style><!-- #header, #main, #footer { display:table; margin:0px 2%; width:96%; } #menu, #content { display:table-cell; } #header { background-color: #fcc; border-bottom: solid 1px black; } #footer { background-color: #cfc; border-top: solid 1px black; } #menu { border-right: solid 1px black; width: 30%; background-color: #eee; } #content { background-color: #ccc; } --></style> </head> <body> <div id="header">Header</div> <div id="main"> <div id="menu"> Menu </div> <div id="content"> Content<br/>over<br/>several<br/>lines </div> </div> <div id="footer">Footer</div> </body> </html>

Mark Rogers mark@quarella.co.uk

This doesn't actually work as expected if the content is shorter than the menu, see example here: http://www.more-solutions.co.uk/test.html This is the exact example from the above tutorial except that the content has been reduced and background colours added to the left and right sections. Note that the line (border) between the left and right sections is only as long as the right-hand content, and the background colours don't fill the whole areas unless the content does.

Excuse me for walking in part-way through, but have you tried putting the border and background on div#container instead of div#content? You may need to tweak background-position (IIRC) to get it just so.

If this were a table-based layout, the left and right "cells" would by-definition be the same height.

On some devices.

Of-course I can fix this by forcing the height, but that has far more disadvantages than benefits.

On some devices. There's also min-height. On some devices.

Don't you love web tech? :-) This is where I earn my money. :-)

Hope that helps,

Mark Rogers wrote:

On 12/05/11 11:29, MJ Ray wrote:

...

Excuse me for walking in part-way through, but have you tried putting the border and background on div#container instead of div#content? You may need to tweak background-position (IIRC) to get it just so.

I'm not sure I understand: the "border" is the line between the two "cells" so is not on any outer edge of div#container, but somewhere within it.

Yes, that's doable with a background image on top of a background colour. Or you can put a border on both the side bar and the content and position them to overlap. There are tons of ways to skin this kitty depending on exactly how long you want that fur stole to be.

...

...

If this were a table-based layout, the left and right "cells" would by-definition be the same height.

On some devices.

On "most" devices?

There's no proof of that.

...

Don't you love web tech? :-) This is where I earn my money. :-)

Absolutely!

What I find frustrating is that CSS was developed "with the benefit of hindsight" yet doesn't solve many of the layout problems that tables do solve.

I feel it solves most of the styling problems, but not necessarily in a narrow "my layout is the only layout" way.

Another example: Foo Bar FooFoo BarBar

How do I lay that out so that Bar/BarBar are aligned vertically, for any value of Foo/FooFoo? With a table this is easy. (Putting Foo/FooFoo in one div, floated left, and Bar/BarBar in another div, would work, but only if Foo/FooFoo/Bar/BarBar never individually exceed a single line, unless I don't care that FooFoo/BarBar are also horizontally aligned, which I do....

If you'd settle with them aligned only in some conditions (browser window the right size and shape) then that's do-able. One of the CSS grid systems should do it, although now I've just noticed that the latest version of cssgrid.net isn't scaling down for me :-/

If they really don't make sense if they're not aligned both ways, then that may well be a table and should be marked up as such.

If they make sense without alignment but you want to force them to be aligned even in non-ideal conditions, then... DON'T DO THAT! :)

Good luck,