table geometry validation

[James Leifer]

Hello,

I always validate the output of my CGI scripts against the DTDs to
make sure I'm producing clean pages. However I notice that there are
a class of errors that are outside the scope of DTD validation, namely
table geometry problems.

Examples:

* I put a

td rowspan="2" ...

in one row but forget to skip the appropriate column in the next row.

* I put in width attributes on the tds to help a big table render
quickly, but my widths add up to more than 100%.

These lead to unexpected and broken output in many browsers.

Are there any batch tools to check these kind of problems? Are there
any debug modes of common browsers that report when the table appears
to be broken?

I'd be grateful for any pointers!

-James

[Jukka K. Korpela]

Re: table geometry validation

James Leifer <James.Leifer@i nria.fr> wrote:
[color=blue]
> I always validate the output of my CGI scripts against the DTDs to
> make sure I'm producing clean pages.[/color]

You cannot make that sure by just validating your script output.
[color=blue]
> However I notice that there are
> a class of errors that are outside the scope of DTD validation, namely
> table geometry problems.[/color]

Surely.
[color=blue]
> * I put a
>
> td rowspan="2" ...
>
> in one row but forget to skip the appropriate column in the next row.[/color]

This is far beyond the scope of validation. In HTML, rowspan is declared
NUMBER, i.e. a digit sequence. In XHTML, it's CDATA, meaning "anything
goes" (as far as DTDs are considered).
[color=blue]
> * I put in width attributes on the tds to help a big table render
> quickly, but my widths add up to more than 100%.[/color]

Validators won't even catch width="hello world!", since the width
attribute is declared CDATA (since both numbers and percentages are
allowed, and there's really no way to describe this restriction in SGML,
still less in XML).
[color=blue]
> Are there any batch tools to check these kind of problems?[/color]

I don't think so. If you find a candidate, make sure you double check
what the tool actually does. Most "HTML checkers" other than validators
include subjective and even completely wrong checks.

Besides, it's not an error to have e.g. a table where rows have different
numbers of cells. Such a table may sound odd, and the interpretation of
its structure might be debatable, and there are really no rules on how
the feature should be reflected in visual presentation, but it would be
wrong to flag a page as erroneous just because of such a phenomenon.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[James Leifer]

Re: table geometry validation

"Jukka K. Korpela" <jkorpela@cs.tu t.fi> writes:
[color=blue][color=green]
>> I always validate the output of my CGI scripts against the DTDs to
>> make sure I'm producing clean pages.[/color]
>
> You cannot make that sure by just validating your script output.[/color]

Agreed. The fact that one run produces correct output doesn't mean
that all runs will. ``Don't want no fallacious induction here.'' 8-)

One can do better though: languages such as cduce (www.cduce.org) give
compile-time guarantees that the XML output of *all* runs will conform
to any specification you choose (e.g. xhtml 1.1 strict). I am
starting to experiment with this.

<snip>
[color=blue]
> Most "HTML checkers" other than validators include subjective and
> even completely wrong checks.[/color]

Right on. I always use the WDG validator.

<snip>
[color=blue]
> Besides, it's not an error to have e.g. a table where rows have different
> numbers of cells.[/color]

Sure, in general it could be sensible. But in practice it indicates a
bug in my CGI and spells trouble for browser compatability. I wanted
a tool to make sure my programs weren't doing that by mistake.

-James