Fog Creek Software
Discussion Board

Knowledge Base
Terry's Tips
Darren's Tips

Table editor

Any chance of a table editor?

Chad Z. Hower
Tuesday, March 26, 2002

Unless you mean for presenting tabular data, I would suggest you stay away from tables.
People have been using tables to create lay-out because no better alternative was around. But there has been for a while now. Use CSS and DIV-tags to create all the layout you need.
It's easier to maintain, easier to read (for machines and non-graphic browsers), but not so much easier to understand at first. At least when you're thinking in terms of tables still. Look for info by searchin on css positioning in Google. It will get you to many a good site explaining how to create lay-out using CSS instead of tables.

Of course you have to think about how to deal with non-css compliant 'older' browsers. There are ways to deal with that too.

Erik van Linstee
Wednesday, March 27, 2002

It is in fact tabular data. And even with CSS, CD doesnt support that either. :)

Chad Z. Hower
Wednesday, March 27, 2002

Some folks really want tables from time to time.  If using CityDesk, I'd do all I could to avoid using them.  I suggested that one of my clients create and manage his tables in MS Word and paste them into articles.

I also suggested how he could display his information with using a table.  He's sticking with the MS Word tables though.

Wednesday, March 27, 2002

After seeing Erik van Linstee's comments above on using CSS and DIV tags, I did just as he said and searched on Google and found some great information ( was very good).

So, I'd like to "announce" the re-vamp of one of my web sites (, which now uses DIV tags for it's structure. It took some experimeting and pulling of hair (especially when testing in different versions of IE), but I think it now looks reasonable as a first attempt with this method.

What do you lot think?

And does it look OK in your browsers? (Should have a header and body block, with a menu block and content block inside the body, the menu to the left of the content. There should be approx 5 pixels spacing around most elements.)

Any comments appreciated.

Ian Jones
Thursday, March 28, 2002

Looks great in IE!  (but not in Mozilla :-( if you care)

Michael H. Pryor
Thursday, March 28, 2002

In response to Ian:

As noted by Michael, you fell into the IE trap.

IE does in fact ignore the CSS spec on the BOX model.
Instead of adding padding to the WIDTH, it subtracts it from the width to arrive at the content area.

Therefore, you boxes are bigger in browsers that follow the spec and implement the box model correctly.

There are workarounds. Look at or search for "css box model" on google.

Erik van Linstee
Friday, March 29, 2002

Another good place for CSS (and dumping tables in favor of DIV) is

Brad Wilson
Friday, March 29, 2002

Thanks for the feedback and suggestions, I'll definitely be using some snippets from bluerobot and glish, thankyou.

I didn't understand Erik van Linstee's comments about box sizes at first, but I've just downloaded Netscape 6.2.1, and low and behold all is now clear. I got some very strange stuff from netscape 4.77 on linux, but I'm not too bothered about that.

I initially used the import url method but found that IE 4 was a bit strange, it partially read the CSS, on some pages would show the boxes but without content, on others it didn't seem to have read the CSS at all. But who cares about IE 4, how many people actually use it? Not many I bet, I only tested it because the site I was at used it as a minimum spec test. I probably will return to the import method, and see how that goes, bluerobot suggests that this is the best method for linking in CSS as browsers that don't understand CSS can't handle it anyway, so content just gets shown in order.

I'll have another crack at it when I get a chance, things are a little manic at the moment.

Thanks again.

Ian Jones
Tuesday, April 2, 2002

Geez, I had a nice big message typed in and then hit backspace with the cursor in the wrong place. Poof, back out to the main page and the message is lost to the world. Well, second time lucky perhaps...

Just over a year ago I learned pretty much all there was to know about CSS Positioning. I had read all of the arguments about why it was a good idea, and basically got excited. So I read all the articles, downloaded all the snippets, and viewed source on all the neat pages.

About two weeks later I had learned all of it - no boast there, there's not too much to HTML really. My conclusion is simple: CSS Positioning does not work, at least not as a general replacement for table-based-layout.

Why? No one reason of course.

To start with the main selling point is that anyone can read your CSS marked up articles, regardless of what browser they use. They might not get all the styles you wanted, or perhaps none at all, but at least they'll get the text.

Actually, no.

IE actually comes pretty close to being usable (and looking over it now, it seems that 6.0 is even better than the 5.5 I wrote for). However when using iCab, Opera and both 4.7 and 6.x of Nav (and Moz), the page became unreadable. Layout got confused, pictures ended up on top of text, in some cases TEXT ended up on top of other text! In fact the only non-IE browser you could read it on was Lynx! So much for "graceful degredation"!

Now of course, you'll want to say "bad browser authors". Well in this particular case I might let you get away with that. But then as I used it more and more I came to the conclusion that there are several theoretical problems that basically mean it won't ever work they way they say it should.

Consider how you think about layout. Do you think of things (as I do) in terms of "put this column next to that one", or perhaps "put this text beside that picture"? Likely yes. Well that's not the way that CSS thinks about things. Instead it's "put this picture down and to the right of the upper left corner of the parent that contains both me and the image".

Instead of a peer-peer positioning system based on ID's, they instead chose a parent-child system. That means that to do something as stupidly trivial as put a caption beside a picture, you have to put both in DIV's, and then put the DIVs in another DIV, and then position the two inside the common parent (you can simplify somewhat, as you don't need to wrap things like P's in DIVs).

Of course, you typically want your picture to lay next to a specific part of your article...

In the end you end up with all sorts of DIVs and such scattered about to make a proper hierarchy. This is just to make the items inside peers, which is what you wanted to do in the first place. I really think this is a terrible design flaw in the system. Useful in some cases sure (laying out major blocks in the BODY for instance), but as the only solution it's terrible.

Now ok, that's really just some more work. But once you get it and the browsers start working, THEN it's great, right? Users will be able to scale up and down you text and override your styles, right? Nope.

Another problem that became increasingly obvious was that the measurment system also falls prey to the problem above. After you get the hang of it and know where to find and kill all the hidden whitespace css insists on adding, you can get all those upper left corners where you want. But the OTHER corner is another matter altogether.

What's the #1 use of tables for layout? Well it seems to be to get a three-column layout. To do that with a table is trivial, but to do so with css isn't nearly as easy. That's because tables know about their cells, and thus have some ability to shift around their edges to stay with the other cells. But remember, in css you don't know about your peers, so there's no way to say "put your left edge 5px to the right of that guy" when laying out your rightmost column. I ended up with no rightmost column, substituting instead the "leftover" from not using that space.

Ok, ok. So you've got everyone on the planet to use the same browser. You've re-created all your pages to carefully add all the blocking and hierarchy to support it. You've even removed lots of features you used to have in order to get it to work. Ok NOW the user can change the font size!


And here's the last thing I found. Basically the positioning interacts with the measurement system in a way that I think fundamentally makes the whole system not work. Basically the only way to make the positions change with changes to the font size is by using measurments based on font sizes - typically em's.

But remember, you don't know about your peers. So if the user does decide to increase the font size then that part of the text will indeed get bigger, but then it will end up over the other bar.

Wait you cry, why not specify the width in em's too? Well I did, but if your page is like practically every one on the planet, you're likely to have different fonts and sizes on different areas of the page, right? Ahhh, well SIZE information is relative to YOU, so if the user changes the size of the font that happens to be in the nav bar and not the body, boom, nav bar overrunning body. That would be trivial to solve if the nav bar could simply push the body a bit to the right to make room, but it can't. In fact it's worse that that, because I found that in most cases the text overran the edges of it's own container!

Unlike a table.

I carefully constructed this site:

with some placeholder graphics and lots of the effects removed. Even on the first page you can see that it doesn't work right, look at the text at the bottom and try resizing. I defy to you fix it.

If you click on the Starfleet Orion link you'll see how it should work - if you're on IE that is. The page you're looking at is a bit of an illusion, the nav bar is actually located at the bottom of the page. It looks nice, and resizes OK.

But use the nav bar to go to SunDog and you'll see it fall apart. Note that the HR at the top is actually below the picture, but it doesn't render that way. Resize down and the picture will happily cover the title, because there's no way for it to know it's there. This is a non-problem with table layout.

Then I asked other people to try it. 100% (I mean that, EVERY ONE) noted problems I could not see, some of which rendered some or all of the pages unreadable.

And that's when I gave up. Learn from my pain, do not use CSS Positioning!

Maury Markowitz
Tuesday, April 2, 2002

I don't want to figure all that stuff out even if it works perfectly every time.

I want folks to be able to build a soccer schedule or make a table of the PTA committee chairpeople without learning rocket science.

Tuesday, April 2, 2002

Let's not confuse the separation of functions of content manager and site structure builder that makes CD so great. The content manager must be able to set up tabular information in articles as easily as they do it in MS Word. For simple tables, that is what we do and then paste into CD. It seems to work pretty well so far. If Fog Creek doesn't want to go to the trouble of building a table editor for articles that mimics Word, then they can put some effort into making sure that cutting and pasting from Word works flawlessly. It seems to now, but who knows.  If a content manager has go into the HTML editor, that suggests a place where CD may be a little short of design goals.

The person developing templates could use tables or div for basic site layout. Does anyone know if the 3 column layout at Blue Robot and Glish work across browsers as they claim? Also, not being that familiar with CSS, are there any problems if the content manager puts tables inside a template made with  divs?

Dick Dillon
Wednesday, April 3, 2002

Try this for yourself...

Now resize to the left (make it thinner). Goodbye menus! And check out the word wrapping in the center.

Maury Markowitz
Wednesday, April 3, 2002

*  Recent Topics

*  Fog Creek Home