Does deleting the line <div style="width:100%; float:left;height:3px; background:#666666;"></div> on https://pl.wikimedia.org/w/index.php?title=Template:Komisja_Rewizyjna help?

Maybe, but this is still very unexpected behavior.

Turning off the float on the bar is sufficient to correct the issue. If it's necessary for something, the only thing I can think of is overflow-x: hidden. I think in this case the wide tables support now installed for Vector 22 has identified a genuine issue in the HTML/CSS used onwiki.

Took me just a few minutes to find affected articles on Wikipedia. https://en.wikipedia.org/wiki/List_of_presidents_of_Burundi (and lots of other articles in https://en.wikipedia.org/wiki/Category:Lists_of_national_presidents)

With VectorWrapTablesTemporary=false, a table is pushed below an infobox:

With VectorWrapTablesTemporary=true, it is cut off:

mw.loader.moduleRegistry['skins.vector.js'].packageExports['resources/skins.vector.js/config.json'].VectorWrapTablesTemporary = true;
mw.loader.moduleRegistry['skins.vector.js'].packageExports['resources/skins.vector.js/tables.js'].init();

This is the same thing as in my original example, except the floating element isn't big enough to cut off the entire table.

Any article with a big table and a floating element before it (e.g. an infobox or image thumbnail) is going to be affected.

Which is expected behavior, that table is scrollable.

In T367629#9896451, @Izno wrote:

Which is expected behavior, that table is scrollable.

This is my understanding as well. This issue happens when the floated element is very wide (or in the case of the page in the description, 100% of the page width). But I cant think of a case where we'd want a floated element to be 100%, the whole point of floating is to allow other elements to be next to it.

In my mind, the most common case of a table below a floated element is the infobox, which should be skinny enough for a table with noresize. The other option is to add "clear: both" to noresize, but i'm not sure thats actually desirable.

Adding clear: both seems like a good solution here. Generally when a table is marked with noresize it means "I know this is big and it's big for a reason - don't squish it under any circumstances." With this in mind, a float does take away space from the table so should be disabled. Patch welcome unless someone can give me an example where this wouldn't be wanted.

Note this assumes we do provide the opt out described in T367248 of allowing editors to wrap a table in a div and say "This table doesn't need horizontal scrolling" as we are changing the default behaviour for tables with this roll out.