Table looks ok...
http://de.wikipedia.org/w/index.php?title=Benutzer:Brion_VIBBER/Test&oldid=26963610

Testing in Firefox 2.0, the floating problem appears to be triggered by the
"position: relative" style on the enclosing <div>.

As far as I can tell, "position: relative" with no offset *should* act
identically to the default (implied "position: static"), which of course means
it shouldn't even be there... I think. :)

But...

• with position: relative the links in the float don't work where they overlap

the <div>'s box (more easily visible if you set a border)

• without position:relative, the info link icon goes zipping around to the wrong

location, up in the previous paragraph or something.

Sounds like a bug shown by a workaround for another bug, or... something.

ayg wrote:

position: relative with no offset acts as a bound for position: absolute elements inside it, for
one. For instance, <div style="position: relative;"><div style="position: absolute; left:
1em;">Foo</div></div> will have "Foo" 1em from the left of the relative-positioned div, not the
body. That's why the info link goes somewhere else if you go to position: static.

The issue seems to be related to the fact that the containing block extends all the way to the
edge of the page; the links only fail when the box overlaps them. If we give an appropriate pixel
width (which should be easy, since we know the pixel size of the contents), the problem disappears.

wiki.bugzilla wrote:

Just to correct myself about what I meant with "wikitables" at #1 ...
http://de.wikipedia.org/w/index.php?title=Benutzer:Brion_VIBBER/Test&oldid=26966321
Well, no "inclusion", obviously, but generally the same behaviour as for <div>s.

I was testing to much stuff today, so I mixed it up a bit, sorry ;-)

michaeldaly wrote:

A fix for this bug is available in conjunction with that for bugs 8718 and 9126.
See bug 9126 for info.

Assigned to extension developer

Fixed in r41720/r41725.