Rubber tables

G

greiggy

Registered
I'm doing a news page (in Dreamweaver) based on a table with a variable two column layout down the page that is roughly like this:
narrow cell + wide cell,
wide cell + narrow cell
etc
When I check the output in a browser, the narrow columns appear wide and vice versa, or more often they are all roughly the same -- not at all according to the layout.

I have tried setting individual cells to a percentage i.e. table width="70%". How do you ensure tables appear pretty much the way they are laid out? Is there a way to hold the size or keep the size within certain limits (I thought the table width command would do this)

Would nested tables help me here, or should I revert to using layers for everything?
 
well are you trying to put tables side by side, or using TDs?
it should be something like this:


Code: 
<table width="100%">
<tr>
<td width="25%">
skinny column data here
</td>
<td width="75%">
wide column data here
</td>
</tr>
</table>

Unless I misread what you're trying to do, that should do the trick for you. Need to specify table AND tabledata widths if you want the columns to be fixed in different proportions.

or better yet, do it all in css...
 
You could also have one table with, say 5 columns all at 20% (or maybe 10 at 10%). Then use span to have 3 columns and 2 columns on one row and then 2 columns and 3 columns on the next row.
 
I am a long time Dreamweaver fan, starting version 1.0, and it is one of my favorites by far. However, tables in DW are one of the few areas that the program sometimes frustrate me.

First of all, I would not use % values for hieght and width. Unless you really want a site to expand and contract, % is not good. For most sites, pixels allow you more control on design. for sites that have paragraphs that people are to read (articles for example), % is bad bad bad.

A basic rule of typography is to not have lines of text be too long. If they are, people have a hard time finding the next line of type after they get to the end of one. That is why books fill each page, yet wider formats, such as landscape oriented books magazines, newspapers, etc. use 2 or 3 colums of text. So on a site, % can make the text too long when viewers have a very wide browser window. The only time I use % is when I want to center my entire page in the browser window (see my site at www.phelpsinteractive.com for an example). I make a table that is 100% wide and 100% tall, with the alignment inside the table (just click in the middle of it) set as middle and center, then I put my sites content (such as the Flash file at pehlpsinteractive.com) in the middle. that way, as a person resizes their browser window, my site stays in the middle.

Here are the requirements for every table (DW won't always autmatically put the values in, watch the HTML and edit the code if you have to.

1. you need width and height values for each table you build
2. you need width and height values for every table cell
3. the sum of the widths of all table cell in a table row must equal the width of the table.
4. the sum of the heights of all table cells in a table column must equal the hight of the table.


Now, there can be 3 states of each cell
1. empty 2. text 3. graphics

Text and graphics are usually not an issue. Images, especially ones that are the exact hight and width of the cell it resides in, helps keep the size of the row and colum that is risdes in. Text can do this too.

Empty is the issue. I usually make a small photoshop file that is pure white. You can make a 1pixel x 1pixel image, but I like to make one that is 10pixels x 10pixels or so. Make it all white and save it as a GIF with white transparent. Many talk of a Transparent GIF, and this is what we are making here. Place this in a cell that is totally empy. Then select the image in the table cell and in the Property Inspector, type in a new hight and width using the values of the cell it is in. This forces that cell to maintain the hight and width just like any image (like I mentioned above). So, you basically have to make sure every sell has sometihng in it. If you leave a cell or 2 empty, it sometimes can be ok (depends on total number of cells), but if you preview a table with very little content or no content at all, you might get some funky results.

If you have Adobe ImageReady (bundled with Photoshop since Photoshop version 5 or 5.5) then I recommend building any graphic intensive tables in there. Use the slice tool to draw you table cells then export the HTML file to your sites root folder and tell it where to export the sliced images. Open this HTML in Dreamweaver and preview it. I bet money that it previews good. I've never had major issues this way. Of course later editing might present gaps or whatever, but just follow the instructions above. The more content you have in a table, the less likely you are to have problems with it.
 
Actually, height is not a valid attribute for tables, and it never has been. Height used to be a valid attribute for individual cells, but it has been deprecated.

Height declarations will work, in most browsers, if you use either no DOCTYPE or a broken DOCTYPE, because without a valid DOCTYPE the browser goes into quirks mode. But as soon as you upgrade to DW 2004, which places a full valid DOCTYPE in your code, your shiny new valid DOCTYPE will put browsers into standards mode and your 100% height tables will no longer be 100% height.

Nested tables would likely be the best solution to the question posed about table widths. Use one parent table, one column wide, with as many rows as necessary. Then within each cell of that table, place a table with one row and two cells. One cell is assigned 30% width, the other is 70% width. Next row, another table, with the width assignments reversed. That way, the width of the content from any one row won't affect the width of the other rows.

But keep in mind that tables will always expand to contain their content. In a table that's, oh, say 600 pixels wide, if the first column is assigned a width of 50%, that cell should be 300 pixels wide. But if you put a 400-pixel-wide image in there, that cell will become 400 pixels wide. And if you put a 400-pixel-wide image in the cell next to it, it will also be 400 pixels wide, and your table will now be 800 pixels wide. As Harvestr pointed out, an empty cell may collapse completely, so it's best to put something in every cell -- either a transparent gif or a non-breaking space.
 
Yes, but using % for widths is bad design, hands down. I hate seing text reflow as I resize my window. Dimensions in pixels is much better. Don't get me wrong, there are designs out there that might work fine with %, but for most sites, formatting is just as much a design element as color. Therefore, having a left and right margin, something you see in all printed makerials, is a good practice. It looks nicer, allowing you to assigns areas as blank, for holding images, pull quotes, definitions, or side notes. Plus, as I stated before, it is easy to read. Find a paragraphy or two of text, set it to about 9 point type and paste it into a program that will let you flow the text as wide as you can, from edge to edge of your screen and read a few lines. Now set margins that resemeble the size of a normal book. Now read. I bet the smaller margins make it easier for you to find the next line.

Now for headers that you want to expand from left to right no matter what size, a pixel dimension for the image (left cell) and % for the right cell, then yes % is fine. I hate it for text though, just looks bad and the readability suffers.
 
How about posting a copy of the current page (or URL) and a sketch or simple JPG of what you want it to look like.

I'm betting a table-less design will be a better solution here.

-----

Not tested a lot, but works so far. Still needs a bit of polishing...

http://homepage.mac.com/mdnky/greiggy/main.html
 
My problem was that assigning percentages e.g. 70% and 30% doesn't seem to work. There is no graphic content in this particular table. I would expect the larger table to occupy around three quarters of the width and the narrower one around a quarter or so, but I have fouind it's completely unpredictable.

This reinforced harvestr's view that percentage wifths for tables are best avoided. I think I'll try that.

I had to come up with a quick solution, so I used layers.

I was thinking that nested tables would be more secure and I may try that.

I still have the "mission" of making ordinary multi-cell tables in DreamWeaver behave without major dysfunction!
 
Nice work, mdnky! I have the feeling greiggy isn't quite ready for table-less css design yet, but if he wants to investigate it, what you put together could be a great starting point. I haven't really gotten into tableless design myself -- I've been waiting for better browser support, and I may be waiting a long time if I continue to wait for that!

I tend to agree with Harvestr on fixed-width vs percentage table widths (although there's a completely opposite school of thought that advocates fluid design). He's absolutely right about line length and how it affects ease of reading. But setting a fixed table width to control line length can make the page really hard to read for people with impaired vision who set their browser to override your font size and display their type in a really large size. They're going to have a massively long page with 2 or 3 words on each line.

Setting the overall width in ems could actually be a good solution for that, because that's entirely based on the text size itself. Somewhere around 40 characters per line is typically considered "ideal," but that's not etched in stone and will vary depending on your font, type size, etc. So you could set your container width (table, div, or whatever) to 40em -- that won't be exactly 40 characters, because an em is slightly wider than most characters -- but your width will be approximately an alphabet and a half wide, which is a good line length for reading. It wouldn't reflow as the browser window was resized, but would reflow if the user adjusted their font size, which is a good thing.

That's not the issue we're dealing with here, though. You can set a fixed width for the parent table, so that lines of text don't reflow as you resize the window, and still set percentage widths of individual table cells in your table that's nested inside your parent table. I.e.: Parent table (fixed width) contains nested table (fixed width, or 100%), and nested table contains individual cells with percentage widths assigned.

Hey, Greiggy, we've veered off your original question here, and you said you've got layers working to do what you want. Would you let us take a look at what you've got? If you'd rather not, that's fine too. :) I still think my suggestion of nested tables would work -- I played around with that a little this morning, and the cells hold their widths just fine, regardless of the amount of text I put them -- but if you found a working solution yourself, that's good too. You definitely learn stuff better that way than just copying someone else's code.
 
sonjay said:
I tend to agree with Harvestr on fixed-width vs percentage table widths (although there's a completely opposite school of thought that advocates fluid design). He's absolutely right about line length and how it affects ease of reading. But setting a fixed table width to control line length can make the page really hard to read for people with impaired vision who set their browser to override your font size and display their type in a really large size. They're going to have a massively long page with 2 or 3 words on each line.
Click to expand...

Good point about visually impared people, they would have to jump to the next line every 4th word or so, lol. On those sites, the school of though that advocates fluid design would be right in using % widths. Yet, most of the time % widths just equals bad design. I think the visually impared factor is blown out of proportion. The world has moved to glasses, contacts and such, not to magazines written in 56 point type. I'm not acting as if this isn't an issue, just saying that unless your site is for a visually impared audience, such as older adults, then the issues isn't huge. I'm all for building versions of my page for such audiences, not making my standard site huge and goudy to all just for the few that need such a layout. It is the whole reason for plug-in sniffing scripts, so Flash folks go to my Flash site and non Flash folks go to my non Flash site. That way I don't have to give up Flash just because 1% of my viewers don't have it.
 
Harvestr said:
I think the visually impared factor is blown out of proportion. The world has moved to glasses, contacts and such, not to magazines written in 56 point type. I'm not acting as if this isn't an issue, just saying that unless your site is for a visually impared audience, such as older adults, then the issues isn't huge.
Click to expand...

For the most part yeah, you're right. But it is something to take into account. With my contacts in, my vision is 20/20 -- but for personal browsing (as opposed to Web site building) I have my browser to never display any type smaller than 14 pixels. On my 19" monitor at 1280x1024, that keeps everything readable without me having to squint and lean in toward the monitor. Now, 14 pixels doesn't make a huge difference in how many words appear on a line, but it does make a difference.

Nearly any page design is going to break if the user boosts their font size large enough, so I just don't worry about that. Anyone who sets their minimum font to 72px or something is used to seeing broken pages and weird layouts. But for some reason, I'm acutely aware of what a page looks like and how readable it is when the minimum font size is 14. ;) I try to design my pages so that some reasonable amount of variation in font size won't really matter.
 
Sonjay writes:
"Hey, Greiggy, we've veered off your original question here, and you said you've got layers working to do what you want. Would you let us take a look at what you've got? If you'd rather not, that's fine too. I still think my suggestion of nested tables would work -- I played around with that a little this morning, and the cells hold their widths just fine, regardless of the amount of text I put them"

OK, here's one that really needs nested tables or something.

http://www.transform-reading.org.uk/MAIN_SECTIONS/News.html

There are aspect of this site which are horrible – whenever I get some time do a bit more work on it but there's a lot of changed content to keep up with. I'm just an amateur on limited time so please no LOL even if it warrants it! ::cool:

This table I have left as a basic table but have removed the height declaration, set an overall width=850 and set the narrow cols to width=250 and the wide ones to width=600 or thereabouts. The top left is supposed to be narrow.

I've tried per cent declarations on the width as well.

I think I need nested tables, or keeping the areas separate with layers which I have done on another site, so I know it works.

Just intrigued to know why regular tables in DW seem to be so inflexible?
 
In 3 different browsers (Safari, Exploder and Firefox), the top left is narrow -- so I'm not sure what you're after there that you're not getting. By "top left" you're referring to the cell that contains "Visitor from Woking"?

Judging by the rest of the page, I think maybe you meant the top left one should be wide. You have that cell set to colspan="2" -- so it should be wide, right? Well, the cell right next to it ("Junction 12 Sponsorship") has a width of 73%. So the browser is honoring that width over the colspan. Don't blame the browser; you're giving it conflicting instructions.

When I removed that width="73%" from the "Junction 12" cell, and added a width="73%" on the 2nd cell in the next row (News release for Junction 12), the table ended up doing what I think you're trying to achieve -- an alternating row effect, where one row is wide-narrow, then the next row narrow-wide, and so forth.

If that's what you want, you'd definitely be better off with nested tables. It's possible to accomplish the same thing with a three column table using colspans on the table cells, and when I cleaned up your code a little, that's exactly what I got. But nested tables will be much more reliable. If you're using more than 1 or 2 rowspans or colspans in a table, you need to start thinking about nesting tables. Too many rowspans and colspans just make a table more fragile and likely to fall apart.
 
Thanks, Sonjay. Two good answers for me here: (1) clean up the code and do it carefully -- which I obviously didn't 'cos you found a percentage width still in there; and (2) nested tables would be more reliable.

Now (to keep this excellent thread going), what did mdnky mean by going for a tableless design?
 
Ah, tableless design...! mdnky can probably give you a much better answer -- I've only ever played around with that a little, and have never actually built a web site that way.

It's possible, using css, to design your pages and position everything on them without using tables. If you look at the sample mdnky posted, that's a tableless design. The colors are headache-causing (mdnky, what were you thinking?), but all of the layout is accomplished using css positioning. Not a table in sight.

Tableless design accomplishes the wonderful goal of completely separating content from presentation. You can totally redesign your site (and I mean *totally*) by changing nothing but your css stylesheet. Tables are only used for tabular data, not for overall page structure.

However, it's tough to do right, largely because browser support for css positioning is very quirky. I admire and respect people who are already using tableless design, but for now I'm sticking with tables for my overall page structure until we have more consistent and reliable browser support. Within my overall table structure, I've been using divs more for items that in the past I would have automatically used a nested table, and I've taken baby steps in other areas that move me in that direction, but I've not yet attempted a completely tableless site.

Also, if you use a program like Dreamweaver, the page display in design view can get pretty mucked up. The latest version of DW has much better support for that than earlier versions, but it's not there yet. So you have to be really comfortable working in code view and hand-editing your stylesheet. I'm comfortable enough in code view that part wouldn't really bother me, but it would pretty much make DW almost worthless for working in design view at all.

Another consideration, at least for me, is that I have clients who use Contribute, another Macromedia product, to edit sites that I create using Dreamweaver. Contribute has absolutely terrible support for css positioning that would make it impossible for them to edit their sites with Contribute. So for those clients I have to use tables for page structure.

Based on what I've seen, I don't think you're ready to tackle tableless design (no offense intended), but if you decide to really get into hand-coding, you might want to investigate it. It's definitely the future of Web design.
 
Sonjay writes: "Based on what I've seen, I don't think you're ready to tackle tableless design (no offense intended), but if you decide to really get into hand-coding, you might want to investigate it. It's definitely the future of Web design."

Pretty mild comment based on what you've seen! No offence taken at all. Just wanted to know more about the process. Have looked at mdnky's worked example. Seems the way to go for really clean results but I still need to complete the 101 on basic coding . . . and then some.

Thanks for the input as always. Lots to think about
 
Well, that's my vacation reading plan all set up then ::cool:

Thanks for the links, I'll check them out. Not sure how this meets my need of being able to do frequent, fast changes of content and layout, rather than working up a good design that will endure, but I need to get my skill level on coding up a bit for sure.
 
You must log in or register to reply here.
Back
Top