Re: CSS Tables: Aargh !?!?

Regret I can't help with much of what you are asking for, Michael, but
I do have a suggestion re the display of search results - it's clearly
tabular data, so the best way to display it is using a table.  By
trying to do away with tables altogether (a laudable objective with
regard to layout tables), you're actually dispensing with some
essential structural information when it comes to genuinely tabular
data, like the example search results you point to in your post below.
For example, those using a screen reader (i.e. software which reads
out the page content, used by people with little or no useful vision),
rely on the structure of a table to make sense of data like these
search results.  Without the table structure, there is nothing left to
show the relationship between, for example, the column headings and
the data in each column.
So I'd suggest that you do retain tables for content like this, which
is genuinely tabular.  Might make it easier to format and display too.
:)

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