[Nfb-web] html tables

Michael Baldwin mbaldwin at gpcom.net
Mon Dec 19 14:30:06 UTC 2011


Ideally they should not be used, but it is frequently done.
 
Michael

-----Original Message-----
From: nfb-web-bounces at nfbnet.org [mailto:nfb-web-bounces at nfbnet.org] On
Behalf Of Stanzel, Susan - FSA, Kansas City, MO
Sent: Monday, December 19, 2011 6:30
To: NFB Webmaster's List
Subject: Re: [Nfb-web] html tables

Hi Listers,

This is just a question. I had thought tables were not supposed to be used
for layout. I thought they were for numbers.

Susie

-----Original Message-----
From: nfb-web-bounces at nfbnet.org [mailto:nfb-web-bounces at nfbnet.org] On
Behalf Of Benjamin Hawkes-Lewis
Sent: Sunday, December 18, 2011 5:58 AM
To: NFB Webmaster's List
Subject: Re: [Nfb-web] html tables

On Sat, Dec 17, 2011 at 11:37 PM, Bryan Schulz <b.schulz at sbcglobal.net>
wrote:
> how do designers know what numbers to use when coding table tags such as
width and trying to line up similar text on several rows without asking
someone with vision to view a form?

Sighted developer perspective here, but maybe these thoughts will prove
helpful.

The interaction of HTML, CSS, and browser differences in the case of table
layout is fairly complex. It's not really that easy for sighted developers
either,

I recommend reviewing the following materials:

An introduction to table formatting from Sitepoint:

http://reference.sitepoint.com/css/tableformatting

The CSS 2.1 specification for table formatting:

http://www.w3.org/TR/CSS2/tables.html

I think you have three basic approaches:

1. Don't specify any column widths and just let the browser apply its
automatic column sizing. There is no normative algorithm here. Still, this
is probably the best approach if you're in doubt. The visual effect might
not be the best, but it is unlikely to result in catastrophic legibility
failures.

2. Specify widths for some columns but allow the browser to apply its
automatic column sizing to the others. For example, you might want to force
a long width for a long text description, or a short width for a price
column.

3. Specify widths for all columns. The advantage of this approach is that
the results are fairly predictable.

So, how do you determine what width to make each column? I guess the overall
activity is as follows:

1. Determine the total width available for all the columns. Note this is
exclusive of width consumed by margins, padding, and border around the table
and between each column. For cross-browser sanity, you need to set these
explicitly.
2. Work out the longest possible content for each column.
3. Work out the width that would be consumed for the longest possible
content.
4. If the combined widths are less than the total width available, you're in
luck. You can either divide the remaining width among all the columns or
allocate the extra width to text columns (as these are the most likely to
change in length in the future).
5. If the combined widths are more than the total width available, then you
need to allocate less width to some columns and allow the browser to break
the content into multiple lines. In general, you want to do this with text
columns not number columns. If you have to choose between text columns, you
normally want to pick text columns that normally have shorter text so that
only a few rows are affecting by breaking. Be careful not to allocate less
width to a column than is taken up by the longest word in that column, as
browsers can't hyphenate.

Note that web design is not precise, since as an author you don't absolutely
control things like what font or size text gets rendered with. So you're
best off erring on the side of caution - giving extra width - when sizing
columns.

I guess the most scary bit here is how to determine the width that would be
consumed for a given bit of content. This depends on the text size. This
will vary depending on what mechanism you are using to specify text sizes,
on whether the text is bold or italic, and on the typeface used to render
the text.

Fortunately, you can determine the width of text in situ. One way to this is
to create a "div" element containing just your text, with the same text
stylings as will be used for your table cells, then float it, so it only
takes up the width required to show its text rather than the width of the
containing block. You can then inspect it with a DOM inspector (such as
Firebug for Firefox or such as the built-in DOM inspector in recent IE
versions) and determine its width. If a DOM inspector is causing you
accessibility problems, you can write some JS to query the width of the
element.

Obviously, you can use a DOM inspector or JS queries to check your finished
work too.

--
Benjamin Hawkes-Lewis

_______________________________________________
Nfb-web mailing list
Nfb-web at nfbnet.org
http://nfbnet.org/mailman/listinfo/nfb-web_nfbnet.org
To unsubscribe, change your list options or get your account info for
Nfb-web:
http://nfbnet.org/mailman/options/nfb-web_nfbnet.org/susan.stanzel%40kcc.usd
a.gov



_______________________________________________
Nfb-web mailing list
Nfb-web at nfbnet.org
http://nfbnet.org/mailman/listinfo/nfb-web_nfbnet.org
To unsubscribe, change your list options or get your account info for
Nfb-web:
http://nfbnet.org/mailman/options/nfb-web_nfbnet.org/mbaldwin%40gpcom.net





More information about the NFB-Web mailing list