W3C home > Mailing lists > Public > www-validator@w3.org > January 2010

Re: [VE][64] document type does not allow element "TFOOT" here

From: Lou King <lking@knob.com>
Date: Wed, 06 Jan 2010 14:33:35 -0500
Message-ID: <4B44E58F.7000004@knob.com>
To: www-validator@w3.org
CC: David Peabody <DavidP@smdi.com>

Jukka K. Korpela wrote, On 1/6/2010 1:36 PM:
> Dag-Erling Smørgrav wrote:
>> "David Peabody" <DavidP@smdi.com> writes:
>>> The only method we have found to overcome this validation error is to
>>> place the table footer <tfoot> between the table header <thead> and
>>> the table body <tbody> in the HTML code.
>> Correct.
> Not correct. You can omit the <tfoot> element. It is not obligatory at
> all, in any HTML DTD. This is the best approach in practice. What you do
> otherwise depends on the content and structure, which was not disclosed
> - and it's not a validation issue.
>>> Unfortunately, this configuration is not Section 508 Compliant as per
>>> U.S. Government regulations concerning electronic data accessibility.
>>> When the disabled user employs their screen reader to “listen” to the
>>> site they hear the table’s title and/or column heads first <thead>
>>> and then the table’s source and footnotes <tfoot> before the table’s
>>> main data <tbody>.

Unfortunately all of this discussion does not address David's (OP) real 
problem. As a U.S. Government contractor (I'm guessing) he needs to 
comply with all sorts of BS, including "Section 508" and I'm sure a 
requirement to write W3C compliant HTML; which it is obvious he can't do 
both. The suggestions that he not use <tfoot> may not be a contractual 

With luck he has a technical contract monitor that he can present the 
information here and in the standard to, that will know enough to see 
the problem and give David a waver (one way or the other). Or accept one 
of the alternate suggestions.

>> That's a bug in the web client.
> No, it is a feature. Such behavior might be undesirable, but it does not
> violate HTML specifications.
>>> Does the W3C have suggestions or can they alter their testing methods
>>> to discourage this <tfoot> placement because it interferes with
>>> disabled users’ accessibility?
>> The placement of tfoot between thead and tbody is intentional.
> Perhaps, but it's irrelevant in validation. Validation is about what the
> DTD says, not about why it says so.
>> It makes it easier for clients to display long tables on paged media
>> (provided the table is explicitly sized).
> Theoretically perhaps. Popular browsers do a lousy job in pagination of
> pages containing tables, and if they will be improved, let's hope they
> concentrate on important things (like not breaking a table row across
> pages), instead of the rather minor <tfoot> issue.
> Let me elaborate on the suggestion of omitting <tfoot>, even though it
> is not really about validation - it does however give some reasons to
> avoid the validation problem in a simple manner.
> The <tfoot> element's meaning was never defined in a useful way - it's
> just "table footer", whatever _that_ means, and "the table head and
> table foot should contain information about the table's columns". Why
> would such information be given in a _footer_? Perhaps the footer is
> supposed to repeat the information that has been give in the header, to
> ease reading the table from the bottom row upwards? Perhaps it's
> supposed to say something else. The HTML specifications contain no
> example of <tfoot>, except extremely abstractly:
> <TR> ...footer information...
> </TFOOT>
> Whatever you wish to say in <tfoot> is most probably better said
> a) before the table, in a separate block, or
> b) in the table caption
> c) in the <thead> element
> d) after the table, in a separate block
> e) on the right of the table, placed there with CSS and marked up as in
> case a or b.
> None of these approaches causes the validation issue, and you can select
> between them according to the type of information and its role.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Received on Wednesday, 6 January 2010 19:34:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 14:18:00 UTC