Thursday, May 15, 2014

Interesting HTML bug?

Found this very interesting in HTML.

When you create a table with colspans, in some situations the colspan gets ignored.

Check this out:

<table border="1">
    <tr>
        <td colspan="2">111111111111</td>
        <td>2</td>
    </tr>
    <tr>
        <td>1</td>
        <td colspan="2">222222222222</td>
    </tr>
</table>

will produce this html:


image


While this:



<table border="1">
    <tr><td></td><td></td><td></td></tr>
    <tr>
        <td colspan="2">111111111111</td>
        <td>2</td>
    </tr>
    <tr>
        <td>1</td>
        <td colspan="2">222222222222</td>
    </tr>
</table>


will produce this html:


image


You see, when i do not add the empty row with 3 blank TD, the colspan settings are ignored.


Anyone has a good explanation for this? I’m puzzled.


Play with it yourself:


http://jsfiddle.net/RDL3s/4/


http://jsfiddle.net/RDL3s/5/


I found this issue while working on multi column settings for KWizCom Forms, I couldn’t figure out why the form ignores my colspan only on some cases…


 


image


( sneak peak, beta will be available tomorrow – ping me if you want to see it first)


Cheers

5 comments:

Sebastian said...

If you look closely at your first screenshot, you see that the middle column exists but that its width is very small.
I remember this problem to exist since the late 90s so I guess it is expected behaviour defined in the HTML spec (although I have not checked).

Lawrence said...

It's because you've got opposing colspans. Essentially you're telling the first column to span the second one, and the second one to span the first one.

When you add the empty row with 3 td's and no colspans, there is now a row to baseline the others against, which is why it works in this scenario.

Shai Petel said...

Thanks,
still I'm not convinced this is how it should work - to me it still feels like a bug. Maybe it is by design, not sure - but i don't see any reason the browser would need a baseline empty row to figure it out.

I mean, what is the reason it renders differently once there is an empty row with no colspans?
I mean, what would be a use case or situation where you would want the table to render like it does without the empty row?

In any case, the workaround is simple, so no worries.

Lawrence said...

I don't think it's a bug so much as it is a logic problem.

In your first example, the first cell in the first row is set to colspan=2. You are basically asking the cell, "Please span 2 cells in your adjacent/sibling rows."

So your cell says, "Ok let's look for those 2 adjacent cells. Huh, there is only one adjacent cell? Ok so I can't span anything then. Let me just display my cells."

The reason it only sees one adjacent cell is because you've also applied the same rule in your second row. So in the eyes of the browser, your second row is effectively only made up of one cell (even though you see two in the code). There are two opposing colspan rules in play here, each canceling the other out.

That's why I think it's just a logic processing problem. In your second example, you've got a "baseline" row for the others to span against, so it's easy for them to udnerstand what to do.

Shai Petel said...

Thanks for replying back.

I see what you say and know why it is happening, however, I still consider it as a bug but if you insist "problem" is a better word go for it.

The reason I say it is a bug and not a problem is, you have to consider what is the expected result vs. the actual result.

I would expect the browser to count a colspan2 column as 2 columns, and to figure out each row has 3 columns and create it's baseline according to that. Simple enough logic IMHO and the only correct assumption.

If the HTML designer took the time to mark a column as coslpan2, I assume that's what he wanted and expect the browser to handle it as specified.

I do not see a problem in the logic of writing the HTML this way. I see a problem in the logic in the way the browser interpret this HTML and renders it.
While the former I would consider as a logical problem, the latter I tend to call a bug.

It could be by design bug, if the w3c enforces this logic on the browsers, but still a bug IMHO.

Thanks.