Table syntactical restructuring causes strange behaviour

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View


 I converted the tables (for _tabular_ :) data)  in a project from the
plain <table><tr><td></td></tr></table> structure to seperation into
head/foot/body divisions (not the <div>-element). Now I get a strange
behaviour in FireFox not obeying the given sizes anymore, but not in
all cases. It seems that when there are elements with explicit 100%s
within tbody-cells they hijack the table-sizes. I mean I would
understand that when I made size-information only on the first row
(ruling all other rows) and that becomes now seperated (because it's
head now) that the other rows become wild, _but_ an explicit
size-information as colgroup doesn't help at all.
 The thing is I can *see* the jump from the right layout (while
loading, the table is not ready yet) to the wrong layout (after table
layout). Even stranger is that (for god sake) the resizing of the
html-element (the browser-window) does _not_ reduce the size of the
table, an immediate reload _does_  reduce the size of the table.
 So the thing is changing to head/foot/body let my tables behave as if
they don't have any size-information at all (in Netscape 7.2, FireFox, SeaMonkey 1.0, Flock 0.5pre, so all of the Gecko engines,
Opera 8.52 not and IE 6.bla not)

 Any idea, link to bugzilla (which would help much, only cause dispair

Re: Table syntactical restructuring causes strange behaviour

Ah forgot the DOCTYPE, XHTML 1.0 Strict, standard conform, no errors,
no warnings, as it should be. I will produce a simple test-page if I
can, it's complex to reproduce maybe.


Re: Table syntactical restructuring causes strange behaviour


 I found the culprit, it was a rowspan="2", it was relative difficult
to track down, because the incremental render-engine of Gecko is
extreme fluctous (I visited table-data without the problem, then surfed
to the table with problem -> fine, reload -> bad and so on, sometimes I
didn't even got an idea where was the problem yet: in the update or the
 The content for the row-spanned cell doesn't matter at all, so it was
not the configuration of the containing elements, in the end I
triggered it by the character 'a'.
 I still have problems to reproduce it in the most simple way, so the
spanning is not the only condition.
 It smells after a bug because too much conditions have to be
fullfilled to trigger this (tbody+rowspan+...), if you quit any of them
it flips back to normal behaviour.

 I've to fix this in proprietary ways, so I may offer no general help
for others, except writing a bug-report.

 Anyway, greets

Site Timeline