Re: CSS Tables: Aargh !?!?

Hi again Michael

Had a more in-depth look at things now I had some time to do so, and
while I still can't address all of the issues you raised, I do have a
couple of further suggestions which might help with at least some of
these issues.

Try including the text size for INPUT, SELECT and OPTION elements in
the CSS styles.  E.g. set text size for these elements to 1em.  That
should help to make the scaling of these elements more in proportion
to the browser text size and to the other elements on the page which
resize according to the browser text size.  From my own tests I think
that should also help to reduce any large gaps between columns, and
make them better proportioned to the selected text size.

The grey bar under the "Search" button is caused by a default margin
on the FORM element - if you add a CSS style for FORM setting margin:
0px, that should get rid of it.

And of course, as I said in my previous post and as others have also
suggested, don't be afraid of using tables where the content is
genuinely tabular - that's what tables are for, and it should help to
make the presentation of the search results easier and more
consistent.

Hope that helps you get closer to your formatting goals with this
project!

Regards,
Donna

On Thu, 12 Aug 2004 16:50:14 -0500, Michael D Schleif
<mds(at)helices.org> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Please, review these pages:
>
>	Search screen:
>	<http://helices.org/tmP/test_1.4.html>
>
>	Result screen:
>	<http://helices.org/tmP/test_2.html>
>
>	Combined search/result:
>	<http://helices.org/tmP/test_2.1.html>
>
>These are static web pages from a CGI application.  The idea is to go to
>the Search screen, enter search criteria, and get a list of results
>(below the search object.)  Yes, the CGI functions; but, presenting the
>information in XHTML 1.0 Transitional, using CSS, without tables, and
>*without* any JavaScript is difficult ;>
>
>In production, we will be able to dictate which browser is used.  Now,
>we want it to look ``the same''<TM> in all browsers at 1024x768 -- or,
>at least, recent versions of IE6, Mozilla and Firefox.  Additionally, we
>are designing for accessibility, and ad hoc resizing of the screen and
>font sizes is going to happen.  Currently, we are testing with these
>browsers:
>
>	Firefox v0.9.1   (Debian)
>	Firefox v0.9.3   (w2k)
>	IE v6, SP1       (w2k)
>	Konqueror v3.2.2 (Debian)
>	Mozilla v1.7.1   (Debian)
>	Mozilla v1.7.2   (w2k)
>
>Due to the nature of the application, each web page will be _more than_
>50% form data.  Almost all content will be presented in some type of
>block or tabular format.  Our goal is to eschew tables, and do
>completely without Javascript.
>
>Problems
>========
>
>[1] Font sizing is inconsistent, especially in input/select objects.
>    Currently, we are using the method here:
>
>	<http://www.thenoodleincident.com/tutorials/box_lesson/font/index.html>
>
>    Problems remain, mostly due to differences in widths of input and
>    select objects.  The result is horizontal space between columns,
>    especially at the right edge of blocks.  See Search screen, between
>    columns 2 and 3.  How can we minimize that gap?
>
>    Also, compare Firefox (w2k) Result and Combined views -- the HTML
>    for the results table is identical; but, there is not enough
>    horizontal space in the combined view, and the rows wrap.  Yes, we
>    can increase div.search width:; but, this also changes when
>    font-size changes.
>
>    Konqueror is absolutely *HORRIBLE* for this type of tabular,
>    horizontal placement!  What is with this?
>
>    In general, we are finding that font _width_ varies within a given
>    browser across multiple platforms.  Also, font _width_ varies within
>    a given browser, and a given browser, between multiple machines.
>    What is this about?
>
>    What can be done?  Where have others documented these issues, and
>    their workarounds?
>
>[2] IE6 !?!?  O, how I struggle with this beast!  No matter what, fonts
>    are larger, and wider, and more inconsistent from machine to machine.
>
>    Notice, also, the horizontal lines between rows in the Search view.
>    We have added padding-bottom (px) to these; but, each time we resize
>    the font, this also changes.  Other browsers have this gap, too;
>    but, not to the extent of IE6 (and, gasp, Konqueror.)  What is the
>    trick here?
>
>    Then, there is the grey band *beneath* the Search button, *beneath*
>    the yellow div.  How can we get rid of that?
>
>[3] Select objects are very touchy, and not treated the same across
>    browsers.  When text-align:right, the final character partially
>    disappears in the drop-down icon.  How to fix this?
>
>    When float:left column 3 in Search view, then Mozilla/Firefox (w2k)
>    both tried to eat the drop-down icons (e.g., they disappear when the
>    mouse draws near, or one above it is selected and released.)  Why
>    does this happen?
>
>
>Plea
>====
>
>[A] What are better ways to handle font-size, especially font width,
>    issues for our application?
>
>[B] What are better ways to handle input/select objects for our
>    application?
>
>[C] What are better ways to handle tabular data presentation for our
>    application?
>
>What do you think?
>
>Thank you, for your consideration, comments and ideas.
>
>- -- 
>Best Regards,
>
>mds
>mds resource
>877.596.8237
>- -
>Dare to fix things before they break . . .
>- -
>Our capacity for understanding is inversely proportional to how much
>we think we know.  The more I know, the more I know I don't know . . .

HWG hwg-techniques mailing list archives, maintained by Webmasters @ IWA