Re: layout tables

I still haven't found an easy to use and set up table using CSS to handle
form layout for example. I have found some but they're a bit messy in
comparison to a table IMHO (see
http://css.nu/articles/table-in-css.html#Tbl1 for example). I think it's
helpful to provide summary information about the form being display in the
table even though the table is only being used for layout. Inddeed, you
could argue that it is always more helpful to provide summary information
even if the table is only being used for layout. Ideally it would be nice to
have a table type attribute or something but I would be happier to see the
summary attribute being used to at least explain it's purpose. Unless we
standardardize the text to be used in the summary for layout tables, eg
"layout table: additional information" this would mean validation tools
wouldn't be able to identify whether the table was being used for layout or
not but if you know it is only a table layout then you can ignore the
warning surely.

As far as adding title text to each cell aren't we going to be possibly
confusing the problem by offering to much information? The summary attribute
in conjunction with headers etc for complex data tables seems to be
sufficient to me.

OK, I inadvertantly send this originally to Charls who kindly replied as
follows but I wanted to send it to the list anyway. Here's Charls's reply:

Was this for the group? I got it privately. (Feel free to forward my
response).

Well, although making real tables should of course be done in HTMl by using
table elements and all the associated bits and pieces, the stuff you have
there rendered nicely in MOzilla 1.2 for Mac OS X. iCab doesn't handle
floats, so linearised it (Amaya would do the same thing I guess, but I
didn't
test it yet).

If I was trying to replicate the kind of form where there are two columns,
with the left hand one being labels, right-justified and the right hand one
being text inputs left-justified I would use inline spans with a width to
try
and make them behave right. (Hmm. I suppose you could use divs as well, like
you do in your example). Either way, I can think of worse things than the
raggedy look that non-compliant browsers will give - things that cause real
problems.

Another approach would be to use RDF annotations for tables that are layout
tables. This would potentially take the information out of the page
(although
you could also use meta elements to include it, and provide an automated way
of stripping that to put it on the web as RDF, via a very simple XSLT). At
that point you can start by defining your own property for a layout table,
and simply write some RDF to relate it to another such property if you find
one, so that until one of you decides to use the other person's property
there is information that can be used to match the two - also providing
backwards compatibility.

Although I don't know of any current validation or repair tools that are
currently equipped with a complete general-purpose RDF parser, I know that
these are coming (in part because I have some students at work on one, an in
part because the use of things like EARL makes it an obvious direction to be
moving in order to use other people's validation results in your repair
tool).

Cheers
Ian

-----Original Message-----
From: Charles McCathieNevile [mailto:charles@w3.org]
Sent: 08 November 2002 09:33
To: Kerstin Goldsmith
Cc: wai
Subject: Re: layout tables



Well the way I do it is by not using tables just for layout purposes. Really
simple (but not entirely true - I do use a tool for presentations that is
supplied to me and gets maintained and regularly updated by other people.
That uses a table to put some buttons on the page. I used to maintain my own
version, but it got too hard to keep up).

There have been discussions before about getting people to use
summary="layout table" (so should spanish tools look for summary="solo
maquetacion" or what?) or some similar mechanism.

It would also be possible to use a profile to identify this. It seems like
standardising ways of doing this and then getting that implemented in tools
is a lot of work compared with just not using tables for layout, from my
perspective.

Chaals

On Thu, 7 Nov 2002, Kerstin Goldsmith wrote:

>Has anyone come up with a way to standardize on signaling that a table
>is being used for layout purposes only?  When we run our documentation
>through our accessibility checking utility, we have told folks to add a
>null SUMMARY attribute to their tables, and our checking utility
>recognizes this as a signal that the table need not be checked for
>association between headers and cells, or for header markup itself.  Is
>anyone else standardizing on this, or are folks using SUMMARY="This is a
>layout table?"  Or some such variation?  It seems that the SUMMARY=""
>makes sense in the same way that null ALT attributes work for decorative
>graphics, no?
>
>Is anyone interested in standardizing on such a thing, so that all ERTs
>(Evaluation and Repair Tools) can be looking for the same thing?
>
>Cheers,
>-Kerstin Goldsmith
>
>

-- 
Charles McCathieNevile  http://www.w3.org/People/Charles  tel: +61 409 134
136
SWAD-E http://www.w3.org/2001/sw/Europe ------------ WAI
http://www.w3.org/WAI
 21 Mitchell street, FOOTSCRAY Vic 3011, Australia  fax(fr): +33 4 92 38 78
22
 W3C, 2004 Route des Lucioles, 06902 Sophia Antipolis Cedex, France


_________________________________________________________
This email is confidential and intended solely for the use of the 
individual to whom it is addressed. Any views or opinions presented are 
solely those of the author and do not necessarily represent those of 
SchlumbergerSema.
If you are not the intended recipient, be advised that you have received
this email in error and that any use, dissemination, forwarding, printing, 
or copying of this email is strictly prohibited.

If you have received this email in error please notify the
SchlumbergerSema Helpdesk by telephone on +44 (0) 121 627 5600.
_________________________________________________________

Received on Monday, 11 November 2002 10:57:36 UTC