Ok, so pasted below is a bit long and a couple years old, but it'll get you
on the right track.
Good luck!
Teriel9 said:
I have used tables to lock the positions in my web pages.
My problem is that in a 3 column table, the right hand column does not
display at the width given to it, which is the same as the left hand
column.
This is the case in both the "Included" pages and "Main" pages
http://www.wyns-carsales.co.uk
Can anyone please help
Thanks
Teriel9
Table Rules
These rules will help you take some of the pain out of working with tables.
They are presented in a boiled-down fashion designed to let you get decently
formatted tables. There may be caveats or special cases that do not follow
these rules to the letter, however it is a good idea to always follow these
rules while doing HTML editing in FrontPage, DreamWeaver, or whatever you
choose to use.
The Rules:
• Tables are like balloons, the contents dictate the size.
• Tables are like dogs, the best ones are purebreds.
• The math in tables MUST add up correctly!
• Cells need contents, if need be, use a single pixel gif or a space
character.
• Tables are like kids, they must be told what to do.
The rules explained:
Tables are like balloons, the contents dictate the size.
Tables will change size based on what you put in them, as all size
specifications are “minimum size”. Tables act like balloons, if you put
things in them they may stretch, just like cramming marbles into a balloon
will make it stretch. If you put an item in the table that "pushes" against
the cell walls, it will expand. If you are using that table for layout
purposes, the layout will then have mistakes in it.
Some items that can "push" your cell walls:
• strings of text with no spaces, such as phone numbers, URLs, names, and so
on
• images
• using cell padding or cell borders that are too large (using more than
about 3 pixels can cause problems)
• putting a table in a cell (nested tables) that is too big for that cell
Generally, “pushing” on cell walls by placing a too-large object in the cell
is not a good idea. “Pushing” a table cell a table border with a large
object can cause any formatting tasks that table is doing to be disrupted or
misaligned.
Problems caused by too-large items often manifest as a line or color that is
just "off" a little bit, or where the tables in one file look slightly
larger than tables in other files. You may notice this when viewing several
pages in quick succession. If one of several similar files looks slightly
different, it is possible the different file has a table error in it.
To keep this characteristic of tables from being a problem for you, always
check the contents of your cells to make sure items are not too large.
Also, watch for little “jumps” of the table lines when you are adding things
to cells; if the cells move when you add an item, chances are you are
breaking the table with that item.
Tables are like dogs, the best ones are purebreds.
Mixing of percentage and pixel specifications in the same table is not
allowed. This rule is difficult to remember and tempting to break because
popular browser programs are good at accommodating most violations of this
rule. Even though you can usually get away with ignoring the rule, it is not
a good idea to do so. Sooner or later breaking this rule will catch up to
you and make formatting the table the way you want more difficult.
The rule simply put; you must use either percentage or pixel based
measurements in each dimension (horiz./vert.) in any given table. (You may
also use no sizing at all.)
If you use percentage for one table cell, you MUST use percentage for the
other table cells and for the table itself.
If you use pixels for a table cell, you MUST use pixels for the other table
cells and for the table itself.
This rule applies towards each dimension, in that you can use percentage for
the width, and use pixels for the height without breaking this rule. (Using
vertical dimension specifications in tables is generally a good thing to
avoid as they only add additional complications.) Quite often, when you are
tempted to break this rule, you should be using a nested table instead. (A
table within a table.)
Also note, for 99.9% of tables out there, there is NO REASON to specify a
height in a table or cell. Let the contents dictate the height. After all,
the horizontal scroll bar is the enemy, not the vertical scroll bar.
The math MUST add up correctly.
All of the specifications used to create the table must have logically
consistent math. This is an easily missed yet an extremely important rule.
This rule applies to the vertical dimension as well as horizontal
dimensions, however since horizontal specifications are far more common, we
will focus on horizontal numbers to explain this rule.
Errors in table cell sizes can cause logically impossible situations. When
a browser such as Internet Explorer or Netscape Navigator encounters a table
with that type of error, it makes a “guess.” Sometimes the browser guesses
wrong, and will draw unpredictable things on the screen. For this reason,
we recommend you follow this rule.
In general, percentage tables are easier to make correctly, but give you
only a fair degree of control in how the page looks. Pixel based tables
will provide maximum control over how the page looks, but require more
attention to detail to get them to appear correctly.
This rule has two parts, one for each way of specifying size:
Percentage Tables
The sum of all cells across the table, must always add up to 100%. No
exceptions! If there are three cells, 33%, 33% and 34% are acceptable
values for those cells. If there are three cells, 45%, 45% and 20% are not
acceptable values for those three cells. (They add up to 110% across.) Any
combination of cell sizes that adds up to 100% is OK. Any combination that
adds up to above or below 100% is wrong.
Cell values in percentage are always in relation to whatever the table size
is. Cell values in percentage have NO BEARING on how big the table is on
the screen, they only control where the lines between cells will be drawn
within the table.
Table size in percent is always in relation to whatever space that table is
in. If the table is in another table cell, and is set at 80%, it will
change size to always be 80% of the cell. If the table is on its own and
not in another table, it will be 80% of the browser window, whatever that
may be. If the person viewing the web page changes the browser window size,
the table will change size too. Likewise, a percentage table placed in the
cell of another table (as in nested tables) will change size when the cell
of the outside table changes.
Pixel Tables
The sum of all cells across the table must add up to the total dimensions of
the table. In a three column table, columns of 45, 45, and 60 pixels
require that the table width be set at 150 pixels. A table sized at 600
pixels, but with only one cell, should have that single cell specified at
600 pixels as well. If you have a web page that should stay at 760 pixels
wide (approximate full screen for most computers), you can use any
combination of cell sizes, but it must add up to exactly 760 pixels total.
Cell values in pixels dictate how large the table setting should be, and
vice versa. There is a direct connection to the values (unlike percentage
tables). Pixel table measurements are absolute, the table should not appear
to move when the browser or outside table moves or changes.
Cells Need Contents.
Cell are not always drawn on the screen correctly if there is no contents.
Usually, a table is used for sizing or for holding something in place. This
means you will sometimes want a table cell to be a certain size, yet not
have anything visible in the cell.
Yet, using empty table cells can sometimes cause problems for some browsers,
as they are not always drawn or “rendered” on the screen correctly, or not
rendered in the size that you want.
To combat this, you can use a space character or a single pixel, transparent
GIF image in the cell to cause it to be drawn correctly. A space character
will be the default font size of 12 pixels tall. The single pixel gif can
be made to push the cell to any size, or simply left its natural size for
table cells that will be shorter than 12 pixels.
Use the height and width values of the image to make the gif fit the cell
size you want to have.
Search Google for “single_pixel.gif” to get yourself an image; it is a
transparent, 1x1 pixel image that can be dropped into tables to help with
sizing. It is small (download) but can be stretched to be any size you need
using the IMG SRC specification in HTML. (i.e. change image properties).
This image is typically created by Adobe web development tools. Hint: Using
Internet Explorer save the page to your desktop, then open and inspect the
images folder called “page name files” to get the image.
Tables must be told what to do.
In general, all cells and all table sizes should be set for best results.
(See the exception for table sizing below) Any cells or tables left
unspecified will be drawn according to how the program rendering them
decides. Some programs will distribute sizes evenly; some will change cell
sizes according to how many characters are typed in the cell and so on. So
leaving the sizes out will cause a page to drastically different on
different browsers and operating systems.
This rule is important to remember while you are building tables, as cells
or items in cells will sometimes move on their own accord if their sizes
have not been specified.
If you are using a WYSIWIG editor such as FrontPage, you may see different
results than what would appear in a browser program, or see your cells sizes
vary widely as you put more items in.
If you add an item small enough to fit in a cell, and the cells or table
move around anyway, chance are there is an unspecified setting somewhere
that is causing the problem. Finish specifying the table and cells and
table borders should pop back into place.
Addition concerning cell padding and spacing: Cell padding of more than
zero will also consume space in your cells, which in turn will consume space
in your tables. Be aware that cell padding over about 3 pixels will begin
to cause unpredictable sizing problems in your tables. If you are using
more than one cell padding specification in your web site, i.e. 4 pixels on
one page, 2 pixels on another page; then you must also pay close attention
to cell and table sizes in relation to cell padding as the padding will
effect where the edges of the cells and tables will be.
Exception: If you use no size specifications at all in a table, you do not
have to be concerned about making the dimensions add up. In the case of a
“size-less” table, whatever you put in the table will dictate its size.
However, if you use any size specifications in any part of a table, you must
continue to add specifications in all parts of the table in that dimension.
(Horiz/Vert). In some cases, you can use images to force an unspecified
table to a certain size, without using any sort of sizing on tables or
cells. Although this is a way of avoiding this rule, the images method of
sizing has many other problems and rules that must be followed. For that
reason, we recommend against using the images sizing method if you are
editing with FrontPage except in “cannot fix it in any other way”-type
situations.
Other things to remember about tables:
• Use nested tables to work around these rules, or to make a certain look
you cannot get without breaking the rules. Nested tables are simply tables
placed in the cell of another table.
• Do not use more than 4 or so layers in nested tables. Many browser
programs will start to choke on more than a few, you should be able to
design just about type of layout with 4 or fewer layers of nested tables.
• Use “single purpose tables” to work around these rules. For example, if
you want a fixed-width menu on the left, but on a page that will vary in
size according to the browser; put a fixed width table to hold the menu
within the left cell of a percentage table on the page. Since rules apply
to only single tables, you can add nested tables to not break any rules.
This works because browsers can have problems if the instructions in the
tables are not logical. A browser will not have a problem with the overall
page layout itself.
• Do not use tables with a total number of cells more than about 50 or 60.
Many, many table cells will fill up the memory allocated for the browser and
cause the computer of the person viewing the web page to slow down or crash.
If you need many table cells, simply split the table into two or more to get
around this problem. (The limit is the cells within a single table, not the
total cells on the page.) Older versions of Netscape in particular have
problems with many table cells in a single table.
• Avoid using vertical specifications in your tables unless there is a
specific reason to do so. Almost ALL layouts in HTML can be done without
vertical specifications. Using a specification doubles the amount of things
that can go wrong, and doubles the amount of time you have to spend to make
the table correctly.
• “Breaking” a table involves using incorrect dimensions, forcing sizes to
be a certain way or putting something in a table that is too big, or
deleting one cell in a row or column. Once you have “broken” a table, it
may be misaligned, look weird, not be drawn at all, or crash the web browser
program. Not all table breaks can be seen immediately. Some will come back
to haunt you many months after they are created when you come back to make
edits the next time.
• Making a mistake in a table is not always immediately apparent. In some
cases you may come back months or years later to modify a file, only to find
that you reveal a mistake by making further modifications. For this reason,
even though it may not look like following the rules helps the page any, it
is a good idea to follow them anyway.
• To check an image size within a table; right click on the image and check
the properties in the “Appearance” tab. The image pixel size should be no
larger than the cell size, minus the cell padding size. (i.e. image is 100
pixels wide, cell padding in the table is 3 pixels, the cell must be 106
pixels wide in order to not be broken by this image.)
• Watch for little “jumps” in the table lines when you insert items. Any
movement of the lines may indicate a problem. (Applies to pixel based
tables only, percentage based table lines are supposed to move.)
• Use the “show paragraph marks” toggle in the standard toolbar to view
table lines for tables that have zero borders.
• A single pixel, transparent gif is a useful tool to have. They can either
be created in an image editing program, or pulled off another web site.
• To find difficult-to-handle table elements in a browser for
troubleshooting purposes, use the mouse to select portions of the web page.
(Click at the bottom right of a HTML file in your browser, and drag to the
upper left to select the contents of the file.)
• Despite what HTML compliance supposedly means, sometimes formatting in
HTML makes a difference. If you have odd things going on in your tables,
try checking the HTML itself for extra spaces, carriage returns, tabs,
spaces at the end of lines, and so on. Sometimes cleaning up the formatting
can cure some table problems.
• Don’t believe the hype! Nobody, anywhere, has ever made a fully WYSIWYG
HTML editor. That includes FrontPage, DreamWeaver, etc. WYSIWYG HTML is a
logical impossibility, as someone can always come by using Netscape v 1.0, a
text reader program, a text only browser (such as Lynx), or a rare operating
system and view your page. Because you cannot predict how someone might
view your page, you cannot predict what “non-standard” you can get away
with. So you are best off not attempting it at all It is your
responsibility to learn some of the underlying HTML if you want to have web
pages that work well on the web, that is the only way to get web pages that
work well in a wide variety of situations.
• So it naturally follows... Just because a tool is there does not mean you
have to use it! FrontPage in particular is packed with all sorts of fun
stuff and convenient ways of doing things. Many of them break these rules
or will break browsers when they attempt to display them. You should NEVER
drag and drop a table or cell border. DO NOT DO IT. It is simply
impossible for you to make good tables that follow these rules if you do
that. So never drag and drop table parts, learn to use (and love) the table
and cell properties dialogue boxes.
