When CSS Is A Worse Hack Than Tables....

There are some problems with this that need to be worked out but it was just a quickie;

http://imaginekitty.com/shrug.html
(not tested in IE6 because I think I deleted it :bigoops: )

Triumph,

Thanks very much. I am going to look at it in more detail after lunch. For now, I would like point out that my example was just a simple illustration of a more widespread problem. That is, the same thing crops up in 3 column layouts.... where you are required to use either bg images or multiple nested divs to acheive bg effects on the side columns. You end up with a hacked, highly nonintuitive structure for something that could be acheived simply with tables.

So even if we can make your solution to this simple problem work, I am still skeptical of the value of pure css solutions in these other cases. Again, I am really wanting to know what the practical value of remaining "pure" is, when it results in code that is more difficult to manage and understand (at least as I see it).

Thanks again,
J

Tables are not for layout, they are for presenting tabular data and nothing else. To me it all boils down to integrity. Doing things the right way even if no one will ever notice.

It may be a philosophical issue and it may be something more temporal such as future proofing your code. "Practical" doesn't really enter in to the discussion. In my experience there is nothing more convoluted than a tables based layout.

That may be because you are unfairly imposing unrealistic limits such as "no images" and "pure css" (whatever that means). Faux columns is the perfect and simple answer to this problem but you've decided for some unknown reason that you don't want background images (which in my opinion are much better than boring, square, blocky, solid colors). Background images are part of CSS and completely valid and useful.

Triumph,

Thanks for the reply. I hope you won't think I'm argumentative if I continue this discussion -- I genuinely would like to understand your perspective more deeply, as I know most good web designers agree with you.

This is a key point and I agree with you. The markup specifies the logical elements of your document, and of course, logically, a sidebar and the main content are not data elements in a table. So we want to respect the logical integrity of our document.

By the same token, it seems just as reasonable to expect some logical integrity within our css. That is, our display logic (css) should have a natural structure as well. If I see a border around a sidebar (as in our example), logically it makes a lot more sense for that to be a border around a single element, rather than a left and top border of one element, the top border of the element below it, and the left border of the element to its right. I could go on with examples of this kind of thing, but you get the idea.

So the question arises: Why do we always choose to respect the integrity of our document content over respecting the integrity of our display logic? This choice seems to me at best arbitrary and in some cases misguided.

On the philosophical issue I agree with you, but as I said above I still have a philosophical issue of my own with having css code whose logical structure is convoluted and difficult to follow.

As for future code proofing and maintenance on a practical level, unless you are a css expert, it is usually far easier to understand what is going on (and change it when needed) in a table based layout. Typically, an html novice can do it. However, with a multicolumn css layout with different backgrounds for the different columns, it is often very difficult to figure out which div corresponds to which background color, because of the deep nesting required.

First, I don't doubt that you can create more elegant pages using bg images, and I have no problem with designs that use them. My point is, with css, I should be able to design anything I want... I shouldn't have to use bg images to create bg color. The reason is simple too... it comes up in most discussions of the faux column topic I've read: If you use bg images, you have to remake them anytime you want to change you color scheme. Instead of going into css and changing one color code, I have to go into photoshop and remake my image.

Finally, none of these problems would exist if you were able to force a float to expand to fit its container. Is there a legitimate design reason that this is impossible?

Thanks again for any further discussion,
J

The [C]ontainer's height is determined by the height of the [M]ain content. You want the [F]loat to gain 100% height of the container.

[C
[F][M]
]

What if the Main content has a clear:both inside? What is the expected rendering?

[C
[F][M]
[M:clear]
]

You are getting into reflow-troubles with more vertical control. In CSS, [F] does not know about the height of the following element [M].

Jonahx -

Ok, so you have a neat 3 column layout. What if you want your content that appears to the right be first in the source?

also, what crazy amount of nested divs are you talking about to achieve a 3 column layout?

...content...

...sidebar-1...

...sidebar-2...

http://www.alistapart.com/d/holygrail/example_3.html

No images
No JavaScript
Equal column height
Quarantine your "hacks" (2 of them for IE) within a conditional

With markup integrity comes basic accessibility. There is more to accessibility than just proper markup but it's the only proper foundation. My example was surely a poor one and perhaps the display logic was a bit off but it was just to make a point, I suppose.

I can not agree with you on that. Perhaps it is easier to understand tables for someone that has built pages with tables based layouts for 10 years but the beauty of CSS is it's simplicity. Looking for the simplest solution is part of the reason I sought out CSS based techniques.

Oh, you make it sound like such a chore. If all you are doing is a big square block on the left then I can make thousands of background images without breaking a sweat.

Floated items are removed from the normal flow of the document in a way like absolutely positioned items except they still affect the document around them. The document will flow around a floated item and what you are considering a design flaw is it's actual purpose.

No images
No JavaScript
Equal column height
Quarantine your "hacks" (2 of them for IE) within a conditional

ifohdesigns, Thanks for the link. That is certainly an improvement over the multiple nesting here, eg:

http://matthewjamestaylor.com/blog/perfect-3-column.htm

It does however still use the absurdly long divs hack, which is problematic in cases such as the example in my OP. And I havn't been able to get Triumph's solution there to work while still maintaining the liquidness of the main content. Perhaps you can solve that? I am still not sure it can even be done.

J

What is the "absurdly long divs hack" you keep mentioning?

[C
[F][M]
]

What if the Main content has a clear:both inside? What is the expected rendering?

[C
[F][M]
[M:clear]
]

You are getting into reflow-troubles with more vertical control. In CSS, [F] does not know about the height of the following element [M].

IChao,

This is just the type of explanation I was seeking. Although I am still not quite sure why you couldn't simply have conflict resolution rules for cases like this (eg, here the float would just be its own height, and the hypothetical height:100% directive would be ignored). For example, css implements conflict resolution for table borders. This doesnt seem too different.

I'd appreciate any further thoughts though, as the reason must be something along these lines... Thanks,
J

It's linked in the OP. See the section on that page called "How?".

It's linked in the OP. See the section on that page called "How?".

Sorry, I missed it. I didn't recognize it by your nickname.

Again, it's not really a matter of time or difficulty. It just seems reasonable to me that I should be able to do it without images and without the long div hack. Your ability to make thousands of images without breaking a sweat reflects proficiency with an image-making program. So now proper css design is coupled to graphic making ability... that seems wrong to me. This time, it's a philosophical issue for me more than a practical one

When you don't use the hypothetical "height:100%" directive that I want everything would work as it does now. So unless it would lead to "unresolvable" situations of the type Ichao suggested (tho I think his example can be resolved), I still don't see a reason for it not to exist. I've talked to a couple other designers who say they would like something like that, though the experts here probably have a deeper understanding of css.

The conflict resolution rules would mean that if the container contains lots of floats with hypothetical-height: 100% setting, any float painting would have to wait until the height (and clear status) of any element inside the container is known to the browser. But that is not the way CSS is designed, CSS is designed to allow for incremental rendering and to minimize reflow, and to avoid circular dependencies.

Yep. That's the reason I was looking for. So it's not a design flaw but a preference for rendering speed over maximum design flexibility, which is perfectly reasonable.

Thanks again,
J

Well, shoot. Now what do we do? I'm already bored.

I'd still like to see the original problem solved with liquid main content

I'd still like to see the original problem solved with liquid main content

I'd still use faux columns but I'm stubborn.

I'd still like to see the original problem solved with liquid main content

I'd still use faux columns but I'm stubborn.

how would you get the border on there with faux columns tho? don't you just have one repeating image?

border-top and border-bottom with the repeating image having borders on left and right.

but listen, the solution i posted does not require tons of hacks, and nested divs like you have been talking about.

It in fact is much easier to read, more flexible and faster to load than a table based solution.

Next. You will still have to add styles to your table, be it inline, or in an external sheet, if for nothing else, but for background colors, and borders.

The point I am making is, yeah you might have to write some more css, but you have less markup. A scalable site, yes. Accessible across all sorts of media, and much more sear engine friendly.

You also walk away with some reusable code.

Even still, answer me how you would change the order in which your content appears with the table solution? Not using JS.

ifoh,

I think you may be misunderstanding what exactly my issues are, bc I agree with much of what you're saying. I'll answer each of your points... we'll see.

Unless I'm misunderstanding you, this will not reproduce my original example precisely. In particular, bc you need to use the big div hack to get the left nav to sync with the main content, the bottom border won't be visible.

It in fact is much easier to read, more flexible and faster to load than a table based solution.

Yes I agree. You posted a nice solution for the 3 column layout. I bookmarked it. My point is still that such a solution is not entirely flexible. Let's say you wanted some white space between all the colored sections, and you wanted both colums, the main content, the header and footer all to have a border. Now you run into problems with the bottom border again bc of the big div hack... So the solution, nice as it is, won't work for all requirements.

The point I am making is, yeah you might have to write some more css, but you have less markup. A scalable site, yes. Accessible across all sorts of media, and much more sear engine friendly.

Ya, I do get all that. I am just saying that I still think there are cases where it is quite difficult and messy to write an exact css equivalent to something that is easy to do with tables. Still, I have not seen a solution to the example in my OP, and I'm sure I could concoct more difficult problem.

Anyway, my point here is not to bash css... it is pretty remarkable for most things. But I still don't think for all. I'd love you or someone else to prove me wrong, btw.

J

You forgot one:

Even still, answer me how you would change the order in which your content appears with the table solution? Not using JS.

Even still, answer me how you would change the order in which your content appears with the table solution? Not using JS.

I wouldn't. In the OP example though, I don't see that as a big drawback? Why would I want to change the order of the left nav and main content. I fully agree that in other cases this is a legitimate concern.

I want to be able to use css for everything. It is just very frustrating that it cannot accomplish certain very simple things that tables can.

J

So for example, if that sidebar contains 200 links, you are going to force a person with a screen reader to have to listen to 200+ links as opposed to offering them content right off the bat?

"Yes I agree. You posted a nice solution for the 3 column layout. I bookmarked it. My point is still that such a solution is not entirely flexible. Let's say you wanted some white space between all the colored sections, and you wanted both colums, the main content, the header and footer all to have a border. Now you run into problems with the bottom border again bc of the big div hack... So the solution, nice as it is, won't work for all requirements."

In your example you are running the main content area the same color as the background of the page. All you have to do is make the main content area the same color as the background as a short solution, and let the padding leave space.

Borders, add your borders as you please, keep in mind the box model for IE though.

I am currently working on an internal company application... no disabled employees. I know accessibility is a big issue, but realistically there are tons of situations where it is not relevant.

Borders, add your borders as you please, keep in mind the box model for IE though.

I'm not sure I follow you... could you post example code? I don't see how you can get bottom borders on anything that uses the big div hack tho... maybe I'm missing something.

This is the least of all problems, but for argument sake, if they hire a visually impaired employee?

This is silly. Hire a visually impaired employee to do computer work? In my particular case, it's a small company where I know for a fact this won't happen. Anyway, this discussion has veered into territory I'm not really interested in. I have never been arguing that tables are better... so no need to convince me of their drawbacks -- I know all the standard reasons. I have simply pointed out some cases where I think its hard to duplicate a table layout exactly with css. My simple OP example is still not solved, eg.

Well instead of dodging around the answer...what would you do if that became a requirement?

Umm... I guess I'd rewrite it without a table.

What would you do if you had to solve the problem from my OP in css?

Use either the method I provided to you, altering it to allow for borders.

Or.

Faux columns and call it a day. Bite the bullet, add an image.

Sorry, I didn't follow your advice for how to do this alteration. Would you mind pasting up some example code?

As I said earlier, I still don't see how to make this work. You said above "border-top and border-bottom with the repeating image having borders on left and right." however the border-bottom won't show up bc it will be pushed off by the long div. If you don't use a long div, the border will be at the bottom of the float's content, rather than aligned with the bottom of the main content. again, if i'm missing something plz post an example.

Thanks,
J

CSS provides the methods to do exactly what you want. The trouble is, we're stuck with having to service a PoS browser with limited support for anything beyond css1.

You don't like the faux column method, at the least, on philosophical grounds.

A little trickery with borders can also emulate equal length columns.

But you want two equal height columns using pure css and no images. Or, even three equal height columns, complete with borders and gutters between the columns.[1]

It can be done, it's not a css issue, it's an IE issue. Notice that Firefox (Gecko), Opera and Konqueror/Safari (KHTML/Webkit) handle the css just fine, thank you.

Neither the float method of creating columns, nor the display table-group method is appropriate for every case. If we could ignore IE, we'd still have decisions to make and work-arounds to hack. That both properties are powerful, means they both come with serious gotchas that we are required to know. Future enhancements to css will likely make things easier, while requiring us to know more and more.

cheers,

gary

[1] These demos are from the wayback machine archives of my now defunct site. Someday, I'll have refactored them for the new site. :shrug:

Gary,

Thanks very much for taking the time to see what I was getting at. The solution you posted is v nice, and funny that it uses table display via css -- though it makes perfect sense and satisfies my desire to have the css logically structured.

Nice to know that CSS is not the problem as well. Now, given that we are indeed stuck with IE and having to make our sites compatible with it, is there a way to solve the problem in my OP with css and still have it be IE-safe? I guess the answer may be no.... how many designer man-hours, I wonder, has IE cost the web developer industry?

Thanks again,
J