lofty said:
what is the best practice for sizing cells and tables?
That is - sizing them to stay the size i specify. Every
time i want a particular cell or table to be a certain
width or height, they seem to end up changing. The ones i
dont care about, and dont specify a size for at all, seem
to be 'bossing around' the ones i want to remain a
constant size. Do i use shims? Do i give up and just get
my hands dirty and learn some html? Whats up! I understand
that the gui has to transform my actions to code but
i would really love to be able to specify a priorty to a
cell or table that says HANDS OFF! to your clever little
robots.
lofty, pasted below is a document that may help with tables. (I've been
working on it a long time, and figured it was time to share, comments
welcome.)
Cheers
============
Stupid Table Rules - No Copyright, please destribute, for corrections or
additions please post reply.
============
Stupid 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. Some of these rules are part of HTML
standards, some are just there to make your life easier when dealing with
FrontPage.
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, just like cramming
marbles into a balloon will make it stretch after several marbles are added.
The deflated balloon will tend to have a certain size. If you put an item
in the table that "pushes" against the cell walls, it will stretch. If you
are using tables to lay out a page nicely, pushing against the cell walls is
bad; they will change size, and distort your table. In this analogy, you
are building your page using deflated balloons, and then putting just enough
marbles in them but not enough to cause the balloons to stretch.
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 (more than about 3
pixels causes problems)
* specifying a nested table width to wide (the table within the cell is too
big)
Generally, "pushing" on cell walls by placing a too-large object in the cell
is not a good idea. The reason for this is that any other formatting tasks
that table is doing will 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 per the HTML W3C standards. This rule is difficult to remember and
tempting to break because several popular browser programs are good at
accommodating mistakes in this rule. (Internet Explorer)
Even though you can usually get away with ignoring the rule, it is not a
good idea to do so. Sooner or 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 dimensions in tables is generally a good thing to avoid.) Quite
often, when you are tempted to break this rule, you should be using a nested
table instead. (Table within a table.)
Also note, in 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.
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 all these rules.
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, 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.
You may build a pixel table by deciding how large the table should be and
specifying cell sizes inward. You can also build a table by putting items
in your cells, and adjusting the total table size accordingly. As long as
the finished table adds up correctly, the steps you use to get there do not
matter.
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. 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 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.
Cells Need 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.
Using empty table cells can sometimes cause problems for some browsers, as
they are not always drawn or "rendered" on the screen correctly.
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 above) 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 this happens, simply continue
finishing the table and the effects will go away.
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.
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.
* 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 more than 4 or so 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 nested tables.
* 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.
* Check 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.
* 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.
* Don't believe the hype! Nobody anywhere has ever made a fully WYSIWYG
HTML editor. That includes FrontPage, DreamWeaver, etc. WYSIWYG 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), a rare operating
system and view your page all messed up. 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 don't ever drag and drop table parts, learn to use (and love) the
table and cell properties dialogue boxes.
