NOTE: The current preferred location for bug reports is the GitHub issue tracker.
Bug 826 - HTML5 validator returns errors when colspan is used even when there are enough cells
HTML5 validator returns errors when colspan is used even when there are enoug...
Status: RESOLVED INTENTIONAL
Product: Validator.nu
Classification: Unclassified
Component: HTML parser
HEAD
All All
: P2 normal
Assigned To: Nobody
http://www.greenwichlibrary.org/Child...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-22 18:54 CEST by Will Gray
Modified: 2011-04-27 07:39 CEST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Will Gray 2011-04-22 18:54:43 CEST
Consider this example page ( http://www.greenwichlibrary.org/Children/ ) and run it through the Validator.nu or W3C validator. It gives errors for "Table column 3 established by element td has no cells beginning in it.", and yet each table has 4 cells/columns, and the "colspan" of 2 is called on the second cell. Also, for the record, regarding that next table cell (which the validator is complaining about)--I tried it with "display: hidden", which is the default, and I tried it without; in each case, the error comes up, so the CSS display (hidden or visible) of the cell is NOT what is causing this bug. I quadruple-checked this. Either there should be no error, or maybe someone can explain exactly why the error is occurring? It never came up as an error when checked against the XHTML 1.0 validator (previous doctype).

Thank you for your time.

-_Will
Comment 1 Michael[tm] Smith 2011-04-23 22:32:09 CEST
This is a reduced case of the markup you have in your source:

<table>
<tr>
  <td>foo</td>
  <td colspan="2">bar</td>
  <td>baz</td>
  <td>hoge</td>
</tr>
</table>

The validator code correctly reports that markup as an error; the colspan=2 attribute/value is serving no purpose at all in this case (nor in your original). Try removing and it re-validating.
Comment 2 Will Gray 2011-04-24 02:33:03 CEST
(In reply to comment #1)
> This is a reduced case of the markup you have in your source:
> 
> <table>
> <tr>
>   <td>foo</td>
>   <td colspan="2">bar</td>
>   <td>baz</td>
>   <td>hoge</td>
> </tr>
> </table>
> 
> The validator code correctly reports that markup as an error; the colspan=2
> attribute/value is serving no purpose at all in this case (nor in your
> original). Try removing and it re-validating.

Hi Michael,

The markup comes from a 3rd-party control that is (unfortunately) using the table for layout of the "tab" menus(s) (and styling on the cells provides for background images to create each "tab"). Anyway, when I remove that colspan, the display of the tabs renders incorrectly. But that's kind of beside the point since I don't know of anything in the W3C recommendation for tables that explicitly states that a colspan as used in this case would be "invalid" markup. And since it was valid in previous HTML versions (and my understanding is that not a whole lot of table changes have been made) then the "error" in this case would seem to be unintentionally reported anyway. As I understand it, the validator is reporting that there is a cell "missing", when in fact there are no cells missing.
Comment 3 Will Gray 2011-04-24 02:50:02 CEST
(In reply to comment #2)
> (In reply to comment #1)
> > This is a reduced case of the markup you have in your source:
> > 
> > <table>
> > <tr>
> >   <td>foo</td>
> >   <td colspan="2">bar</td>
> >   <td>baz</td>
> >   <td>hoge</td>
> > </tr>
> > </table>
> > 
> > The validator code correctly reports that markup as an error; the colspan=2
> > attribute/value is serving no purpose at all in this case (nor in your
> > original). Try removing and it re-validating.
> 
> Hi Michael,
> 
> The markup comes from a 3rd-party control that is (unfortunately) using the
> table for layout of the "tab" menus(s) (and styling on the cells provides for
> background images to create each "tab"). Anyway, when I remove that colspan,
> the display of the tabs renders incorrectly. But that's kind of beside the
> point since I don't know of anything in the W3C recommendation for tables that
> explicitly states that a colspan as used in this case would be "invalid"
> markup. And since it was valid in previous HTML versions (and my understanding
> is that not a whole lot of table changes have been made) then the "error" in
> this case would seem to be unintentionally reported anyway. As I understand it,
> the validator is reporting that there is a cell "missing", when in fact there
> are no cells missing.

Or... do you think there needs to be a row above this row (with an extra cell) in order to define the number of columns first before using colspan in the next "real" row? Just seems odd that this is valid everywhere else. I can try it (next week), but not sure what its going to look like--if I set the cells of that row to "display:hidden" I assume it would still count in regard to the number of table columns being calculated?
Comment 4 Will Gray 2011-04-24 02:53:26 CEST
And I guess the real question then is: is colspan valid when used in a table that has only one row?

I'm looking around but so far cannot find an answer to that...
Comment 5 Michael[tm] Smith 2011-04-24 05:51:49 CEST
Hi Will,

(In reply to comment #2)
> ... I don't know of anything in the W3C recommendation for tables that
> explicitly states that a colspan as used in this case would be "invalid"
> markup.

The doctype in your document is "<!DOCTYPE html>", and when validator.nu sees that doctype, it checks the document against the document-conformance rules in the HTML5 spec.

And the parts of the spec that are relevant are here:

http://dev.w3.org/html5/spec/tabular-data.html#the-table-element
http://dev.w3.org/html5/spec/tabular-data.html#table-model

The text that's relevant is:

"Tables have rows, columns, and cells given by their descendants. The rows and columns form a grid; a table's cells must completely cover that grid without overlap."

"A table model error is an error with the data represented by table elements and their descendants. Documents must not have table model errors."

As far as what constitutes a "table model error", is the spec there is an algorithm that defines how a user agent (browser) must form a table: 

http://dev.w3.org/html5/spec/tabular-data.html#forming-a-table

...and in that algorithm there's a step that says this:

"If there exists a row or column in the table containing only slots that do not have a cell anchored to them, then this is a table model error."

I think that's the case the validator is reporting here; in another part of the "forming a table" algorithm , there is step that requires the user agent to establish a new (fifth) column when it sees the colspan=2 attribute for this case. But then gets to the end of the algorithm and the table actually still has only four columns, because there is no other markup in your source that puts any cells in that fifth column.

The validator.nu backend has a specific "Table Integrity Checker" feature for checking whether tables have any table model errors. There are some details about it here:

http://hsivonen.iki.fi/table-integrity-checker/

It is possible of course that there are some bugs in that checker, but at least in this case, I think what it's reporting is correct, not caused by a bug in the checker. But I will take a look at your source again and make sure.
Comment 6 Michael[tm] Smith 2011-04-24 06:07:13 CEST
(In reply to comment #4)
> And I guess the real question then is: is colspan valid when used in a table
> that has only one row?

No, it's not valid -- not in HTML5, at least. I took another look at your markup and I guess as you've seen from looking at it yourself, that table in fact has only one row, and a colspan serves no purpose in a table with only one row. In a user agent that follows the HTML5 "forming a table" algorithm correctly (which pretty much all major browsers do, because the algorithm was essentially reverse-engineered from existing browser behavior), that colspan causes what the spec defines as "table model error".
Comment 7 Will Gray 2011-04-24 06:15:42 CEST
(In reply to comment #5 & #6)

Hi Michael,

Thank you very much for the in-depth explanation (and sources). Maybe what's
really throwing me is the vagueness/wording of the error message, but I
understand that the validator is experimental, so I won't get hung up on that.
Given that the code did validate (apart from the custom attributes) for XHTML
1.0 Strict, I guess I wasn't anticipating any real changes there either. BUT...
be that as it may, it seems to me from your explanation and sources that the
validator is behaving as intended.

I did just test out the idea of having an initial, hidden "dummy" row to
establish the number of columns and it validated just fine (code below), so I
am going to try that with my own page when I'm back at work next week, and with
any luck the table layout will display the same as now, but validate. I'm just
not sure yet where that leaves the use of colspan, since if in everything prior
to HTML5 the browsers are merging the two cells anyway, then I'm not quite sure
if I'm going to end up with, display-wise. But if I can't get it to work, then
I may just have to re-write the control to use div's instead of a table (I'd
kind of like to anyway, bit was hoping for a temporary fix for the table).
Anyway, that's not your problem.  :)

Thanks again,

-_Will
Comment 8 Will Gray 2011-04-24 06:17:16 CEST
Code that validates:

<!DOCTYPE html><!-- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> --><!-- <!DOCTYPE html> -->
<html lang="en">
<head>
<title>Children</title>
<meta charset="utf-8" />
</head>
<body class="children">
<table>
<tr>
<td style="display:hidden"></td>
<td style="display:hidden"></td>
<td style="display:hidden"></td>
<td style="display:hidden"></td>
<td style="display:hidden"></td>
</tr>
<tr>
  <td>foo</td>
  <td colspan="2">bar</td>
  <td>baz</td>
  <td>hoge</td>
</tr>
</table>
</body>
</html>
Comment 9 Will Gray 2011-04-25 22:22:45 CEST
Just a follow-up: due to the screwiness of the 3rd-party control I'm using, I ended up having to put the hidden row *after* my main row of cells, but then it worked and validates fine. Thanks for all the help!
Comment 10 Michael[tm] Smith 2011-04-27 07:39:17 CEST
(In reply to comment #9)
> Just a follow-up: due to the screwiness of the 3rd-party control I'm using, I
> ended up having to put the hidden row *after* my main row of cells, but then it
> worked and validates fine. Thanks for all the help!

Cool -- glad to hear it worked out