Hi @hgzh - for the particular example I've proposed some changes on wiki that fix this:

• https://de.wikipedia.org/wiki/Vorlage:Denkmalliste_Schweiz_Tabellenkopf
• https://de.wikipedia.org/wiki/Vorlage:Denkmalliste_Schweiz_Tabellenzeile
• https://de.wikipedia.org/w/index.php?title=Vorlage:Tabellenstile/styles.css&stable=0&shownotice=1

if those make sense, as a next step we can look to formalize those rules in Vector 2022.

Hm, creating an y-scroll on the parent element indeed fixes the stickyness of the table header and I know it's probably the only way to maintain the sticky header with horizontal scrolling in a css-only way, but I'm not sure if this really creates a good ux:

• if the table height is smaller than the viewport (see https://de.wikipedia.org/wiki/Walensee which has a rather short table with sticky headers) there will be a lot of additional whitespace that fills the remaining viewport height.
• having many elements with vertical scrolling makes the page look cluttered, especially when at some point there will be horizontal and vertical scrolling combined.
• this is based just on my personal experience, but I find it quite annoying having two vertical scrolls in one page especially where the 'inner' vertical scroll size exceeds my viewport.

I think there is no way to restrict css to the actual case when overflow starts, is there?

This situation is one of the primary reasons why we do not have a universal sticky tableheader behaviour yet T42763: Implement repeated/fixed/floating/sticky table headers.

I think there is no way to restrict css to the actual case when overflow starts, is there?

No, there is nothing like a :overflowed pseudo-class. The only method I can think of is detecting overflows in containers with JS and then applying a class or something to those cases.

per convo with @Jdlrobson
"Sticky headers are not compatible with overflow - the only way to fix this is to add a fixed height on the div containing the table.. which is not going to be popular."

"I don't think we can guarantee support for sticky headers -at best we can detect the classes community are using and map them to something close enough, so I see this as more a trade off - we break sticky headers (unless editors opt out with the wrapping div if we can find a way to leave them alone)"

@ovasileva @Jdlrobson if its ok with both of you, i think we should decline this task recognizing that sticky headers wont be preserved with our responsive table solution. Perhaps the only action item for this task could be updating documentation somewhere with this decision

Is there a recommendation on how to proceed onwiki?

In T367369#10140171, @hgzh wrote:

Is there a recommendation on how to proceed onwiki?

Once we get a fix for T367248: Tables inside divs should not be wrapped in div.noresize, the sticky behaviour on https://de.wikipedia.org/wiki/Liste_der_Kulturg%C3%BCter_in_Aarberg?useskin=vector-2022 will work again once the table is wrapped in a div (without a noresize class) - however that won't fix the responsive behaviour - it will still overlap the sidebars at certain resolutions.

Steps I would recommend now to prepare for these upcoming changes:

• To workaround the above bug you can wrap the fixed table with a div with class noresize that you then disable at a certain breakpoint. e.g. wrap with <div class="noresize tabelle-kopf-fixiert tabelle-zeile-aktiv-container"> and add rule @screen media and min-width: 1200px { .noresize.tabelle-kopf-fixiert tabelle-zeile-aktiv-container { max-width: none; overflow-x: visible;} }
• For mobile/responsive behaviour you'll need to adjust the template - likely to add a fixed height as we talked about earlier https://adamlynch.com/flexible-data-tables-with-css-grid/ seems like a good write up of this approach.
• I'd recommend adding word-break: break-all; to all columns (td elements) and possibly a max width based on vw.

Is that helpful?

Thanks, I'll have a look at it.

Related note, in case useful/pertinent here: I noticed there's a fresh proposed code-overhaul for the equivalent gadget at Enwiki, which is intended to fix Vector-2022 display issues and other issues. Devs here, may wish to examine that (either to validate the changes for the gadget, or if feasible to use it for this task/the implementation subtask). I hope that helps.