Table Talk
- or - |
|||
![]() |
Anne [keeper of all things] finds the original version | ||
![]() |
Note that I made a row for each challenge
rather than using spacers to try to line things up.
The reason why is that I cannot control how wide people make their browsers and thus it would be impossible to make items line up in every situation. If someone makes their browser too skinny, it would throw every thing off. I did use row-spacers to separate the rows more clearly. Please note that I added some indentation solely for the sake of my poor eyes ... it helps to make sure I have closing tags. |
||
![]() |
I notice that whenever the file is edited
with MS word, the table size is reset from width=100% to
an actual 640 pixel value Why is the single pixel added as a first column, I thought it was to help line up rows? |
||
![]() |
as it might be easier to see what chris did I added a border to what Chris did you can see how it looks at and also look at the source code where she made comments about what she added: | ||
![]() |
Irwin says: I looked
at all the versions of the homework that Anne cited. All
of them looked good when I viewed them in a full window.
Chris' was the best from my point of view. With one exception, they all looked bad in a smaller window: the text abutted the border and was hard to read. The exception was Anne's latest: It looked good in both small and large window, but it seemed to have extraneous horizontal lines. |
||
![]() |
Chris fixed the lines again. By adding width to the single transparent gif spacer that originally set height only to add space between the challenges, e-less actually was setting the left column which also could be done in table definition tags. The final version does this. There was no combination of percentages for table definition size that did not have the potential for text to bleed into the border depending on the browser, window size and screen resolution. | ||
![]() | Irwin thinks he has found the
problem only to recant later on: No they do not go away. The left column collapses for me in Netscape if I take off the width for the one remaining dot_clear.gif set for height=10 width=267 leaving just width=267 and TD width="*" at the top. The right column text bled into the border. Ann who is thoroughly confused as usual throws Front Page at the problem and discovers an extraneous row at the top, extra columns within challenge 5 and believes that you can't mix pixels and percent so sets everything to pixels |
||
![]() |
By now, no one can stand the
original graphic but the following points are worth
remembering: If setting a total pixel size - set it about 20 pixels less than the screen resolution as Anne says:"The table is set too wide at 682 for my 680x480 whatever screen resolution and 14 inch monitor. In the header I have to scroll to see all of it in the right column... I am fine with the total table width set anywhere from 590 with 620 being the very widest. The 620 has the horizontal rule right at the very edge of the screen in NS but I would have to scroll a bit in MSIE to get both columns centered in my monitor." Try it not only with different browsers, but different screen resolutions. |
||
E-less is very sorry
for creating all this confusion. Partially, it is the
result of using an editor and not really seeing what is
happening. I don't know how the dot_clear.gif got
width=267 - I do remember having a tough time getting the
links and challenge titles to line up. I guess I'm
learning working procedures as well. I'm not a programmer
- so it is very hard for me to deal with the codes. I
just want an editor that will do it for me.
This page brought to you courtesy of GeoCities. |