I think this might be a Vector 2022 issue.

Copying comments from T377100:

In T377100#10224523, @Samwilson wrote:

The fixes here seem to be either

• give the table a background color so that although it obscures the tools menu its contents can at least been read clearly; or
• constrain the width of the table.

@JSengupta-WMF what do you think? I think a background color would be best (i.e. it'd just be white to match the rest of the content area). I'm not sure if just the table background should be white, or if the whole accordion should be (the only bit of it that extends into the tools menu is the focus outline).

In T377100#10254232, @JSengupta-WMF wrote:

As per Barbara's comment earlier, accordion should have the same width of the form. Would that solve this problem?

There's probably a way to hack in a fix, but the actual issue I think is T361737: [EPIC] With the current layout, some elements extend beyond the content area and overlap sticky page tools.

@CCiufo-WMF @NBaca-WMF - it feels like this happens in Codex and normal wiki tables. We were proposing to adjust the bg of a table, so the content doesn't bleed behind the z-index, but I wonder if this is a fix at the platform level instead of a singular patch for commtech's use case.

I believe this is more of a Vector 22 thing rather than a Codex thing, but @Jdlrobson might know better. I remember there were some issues recently with large table compatibility.

Since this relates to content, this is typically out of scope for web team and a difficult problem to address universally. It doesn't make sense to fix this on the platform level.

I can't access the URL to see how it is constructed, but presumable this table component needs to be adjusted to have responsive styles.

As a quick fix you can make it horizontally scrollable (e.g. wrap it in a div with overflow-x: scroll) but I would say that's a last resort and we should look to make this conform to our breakpoints and available space.

In our case, we're working with a data table (the block log), so we want it to be as wide as possible for legibility. We're using the Codex Accordion component which contains a Table. When the accordion is collapsed, it stays within the confines of the container. When expanded, it extends beyond it (if there's enough content). This is without any additional relevant styling; We do unset the max-width, but the same issue persists even if we keep that CSS rule. I think this is "normal" behaviour for tables. The problem from my naive impression is that Vector 2022's content body has no max-width, so the overflow-x: auto has nothing to conform to (?). At any rate, the issue I'm seeing seems to hold true for any use of tables in Vector-2022. I.e. I think the solution for T370188 might apply here as well. I see Vector makes effort to ensure user-generated tables are not too large (T334528), but this doesn't help with data tables on Special pages which are expected to have lots of columns and content. In Less, I think we'd want something like max-width: calc( @vector-max-width - @sidebar-widths ). However the sidebars appear to be variable width, too, so I don't know that a CSS-only solution is viable.

Anyway, focusing on a solutions tailored to our use-case:

100% of parent

Add width: 100% to .cdx-table__table, which already has table-layout: fixed. This makes it conform to the width of its parent.

Example:

Also, we'd need to unset this for smaller breakpoints or else you get things like:

Background colour

Give the .cdx-table a background color of @background-color-base. Arguably the best option for desktop – where presumably most admins do their admin'ing.

Example:

Hover states can look a bit odd, though:

Some combination of the above

My recommendation I suppose would be to both give a background color, and use an explicit width for smaller viewports. So the first screenshot above is how it'd look full-width desktop with the sidebars. Yes, it overlaps, but the user is able to comfortably read all information and without horizontal scrolling. This is what is currently done for data tables in production, i.e. see Special:Tags. On smaller viewports, we'd give .cdx-table__table-wrapper the form's breakpoint.

Example:

Note here that I've scrolled the table a bit to the right (the scrollbar may look different on your device), and I've got the viewport larger than the form so you can see how in some cases there would be some unused real estate.

Also note we are going to make the font in the tables a tad smaller, so that should improve the situation regardless of which solution we go with.

@MusikAnimal on your last question, yes a white background on the table makes sense.

I think you can make this responsive by adding the width: 100% to the rule .cdx-table__table--layout-fixed and removing this rule here:
https://gerrit.wikimedia.org/g/mediawiki/core/+/c99c086ffeb85f8f3802bc7014df246465bd87bd/resources/src/mediawiki.special.block/components/BlockLog.vue#327

(You may also want to consider removing the left/right padding from '.cdx-accordion__content' for full use of the space.)

My recommendation would be to always have a max width (even at the desktop viewport), so that the Table always scrolls horizontally if it's too wide. If an editor is using Vector legacy or Vector 2022 with full-width anyway, then it shouldn't be much of an issue for them.

For my understanding, is there a global precedent or pattern that we should use, or do we need to write in the logic for every table, etc?

In T379167#10362565, @JWheeler-WMF wrote:

For my understanding, is there a global precedent or pattern that we should use, or do we need to write in the logic for every table, etc?

I don't think there is one right now. Special:Tags is an example of "precedent" but doesn't feel intentional, and I wouldn't recommend it as a pattern to continue.

We intentionally designed the Codex Table so that they would scroll when there wasn't enough available space. You can test this in some of the docsite demos. You should notice the headers and footer don't overflow as you narrow the available width, but the table body content starts overflowing as scrollable automatically.

This seems like appropriate behavior for this Special:Block table too, but obviously it isn't behaving as expected here with the content container. I can have someone from DST take a look at make a recommendation on how to apply styling that works for this specific case (something like F57730396 but taking up the full available width). Even if there is no out of the box solution right now, we'll need a go-to recommendation for similar pages once they are ported to Codex. In the future, maybe we'll have a container component that will solve this.

For my understanding, is there a global precedent or pattern that we should use, or do we need to write in the logic for every table, etc?

I think the main issue here is that you are overriding the default styles for Codex?

In T379167#10355601, @Jdlrobson wrote:

I think you can make this responsive by adding the width: 100% to the rule .cdx-table__table--layout-fixed and removing this rule here:
https://gerrit.wikimedia.org/g/mediawiki/core/+/c99c086ffeb85f8f3802bc7014df246465bd87bd/resources/src/mediawiki.special.block/components/BlockLog.vue#327

(You may also want to consider removing the left/right padding from '.cdx-accordion__content' for full use of the space.)

That sounds like the "100% of parent" solution mentioned at T379167#10347085. It works great but even with the padding removed and using a 100% width viewport, things feel very tight. At smaller breakpoints you'll get F57730311.

I also tried making the font size a bit smaller, as I see Codex enlarges it on .cdx-accordion__content. Things look much better (this screenshot is the 100% of parent, padding removed, and font size reverted to normal):

But at narrower viewports such as on mobile:

So I think I'm still leaning towards some "combination" solution, with both 100% and a breakpoint for smaller viewports.

In T379167#10363807, @Jdlrobson wrote:

For my understanding, is there a global precedent or pattern that we should use, or do we need to write in the logic for every table, etc?

I think the main issue here is that you are overriding the default styles for Codex?

We are, but this particular rule nor the others we're overriding appear to be the problem in my testing. The rule you mention I don't believe has any effect at all.

To be abundantly clear, I don't think there's any issue with Codex's implementation of tables or the accordion.

In T379167#10363814, @MusikAnimal wrote:

So I think I'm still leaning towards some "combination" solution, with both 100% and a breakpoint for smaller viewports.

This sounds like the best approach so far. So you're saying at smaller viewports it would revert to scrolling?

In T379167#10363814, @MusikAnimal wrote:

I also tried making the font size a bit smaller, as I see Codex enlarges it on .cdx-accordion__content. Things look much better (this screenshot is the 100% of parent, padding removed, and font size reverted to normal):

I don't think this was intentional, it should be the same body font size as the rest of the components on the page. Not sure if that's a actually Codex issue, but resetting it here seems like a good idea.

In T379167#10363847, @CCiufo-WMF wrote:

This sounds like the best approach so far. So you're saying at smaller viewports it would revert to scrolling?

Yes, but the scrolling would be within the table wrapper, and not the entire page.

Using some clever CSS hackery, we may be able to at least make the scrolling container have 100% width, to avoid the unused real estate as seen in F57730396. I wasn't able to figure it out.

In T379167#10363872, @CCiufo-WMF wrote:

I also tried making the font size a bit smaller, as I see Codex enlarges it on .cdx-accordion__content. Things look much better (this screenshot is the 100% of parent, padding removed, and font size reverted to normal):

I don't think this was intentional, it should e the same body font size as the rest of the components on the page. Not sure if that's a actually Codex issue, but resetting it here seems like a good idea.

It looks like it's forcing a "medium"-sized width here.

For any engineers visiting this task seeking to help, here's some background info that may assist you:

• We want a 100% full-width table, if possible, since this is a data table that is expected to contain lots of information.
• In order to accomplish the above, .html-form-codex is given max-width: unset, then the form fields are readjusted to the form's width. This effectively lets the accordions stretch beyond the viewport. We can remove this hack but we still face the same trade-offs mentioned in T379167#10347085.

I've added this to the task description as well.

I also thought it'd be good to show examples of real-world data. The data in the screenshots I've shared thus far are much more brief then what you typically see in the wild. Here's an example from English Wikipedia:

I don't have rights to give examples, but I suspect more verbose languages like German will experience even more clutter.

(Side note, the bug with unparsed wikitext has been filed at T381050)

@MusikAnimal This is happening because of a browser style on the <fieldset> element that wraps everything inside the <form> element. At least some browsers add min-width: min-content to the fieldset element, which makes the fieldset at least as wide as its contents, in this case the tables which are naturally wider than the content area of the page.

Ideally, the table wrappers would be as wide as the content pane, and then horizontal scrolling whould be enabled if the table content is wider than the content pane. To fix this, you'll want to remove this style:

.mw-block-log .cdx-table__table-wrapper {
    overflow: unset;
}

The overflow rule that this is overriding needs to be in place to hide the part of the table that's wider than the content and enable horizontal scrolling.

Next, you can do 1 of 2 things:

1. (recommended) Do not wrap everything inside the form in a CdxField component that is a fieldset. You should only use a CdxField component with is-fieldset="true" to group related inputs for a single field that cannot exist outside of the group (e.g. a group of radios or checkboxes, a group of inputs that make up an address, etc). There's no need to wrap all of the fields in a form in a fieldset.
2. If you want to keep that fieldset, add min-width: unset to it. This will make it only as wide as its parent container.

This is what I'm seeing after doing this:

Finally, on the DST side, we may want to consider unsetting the min-width browser style in Codex itself to prevent something like this from happening in the future.

In T379167#10377472, @AnneT wrote:

…
Do not wrap everything inside the form in a CdxField component that is a fieldset. You should only use a CdxField component with is-fieldset="true" to group related inputs for a single field that cannot exist outside of the group (e.g. a group of radios or checkboxes, a group of inputs that make up an address, etc). There's no need to wrap all of the fields in a form in a fieldset.

We wanted the disabled states to propagate to child components (r1077140), so the outer fieldset is for that, following https://doc.wikimedia.org/codex/latest/components/demos/field.html#fieldset-with-nested-fields

I realize the nested fields don't need to also be fieldsets, though (which I think is maybe what you were saying). I believe we did that because <fieldset>'s have their .cdx-label__label__text boldened, when they are unless we use :is-fieldset="true".

If you want to keep that fieldset, add min-width: unset to it. This will make it only as wide as its parent container.
…
F57775917

The min-width: unset I think was the CSS rule we were looking for! Thank you!! :D

The only problem now is the popup menu for "Active blocks" is constrained to the table wrapper. Screenshot with devtools to show where the element is being hidden:

This is what T379947: MenuButton visually cropped in table with few rows is about. We're doing some pretty unique things on this page (full-width data table inside an accordion inside of a non-full width form), so I don't know a fix needs to be made upstream (T380220) or not. I'm guessing we can hack around it, one way or another.

cc @JSengupta-WMF for review. I say we go with Anne's solution for this task, and T379947 can be dealt with separately (be it an upstream fix in Codex, or we hack around it).

Change #1101842 had a related patch set uploaded (by Samtar; author: Samtar):

[mediawiki/core@master] mediawiki.special.block: Fix table overflow/width

https://gerrit.wikimedia.org/r/1101842

Change #1101842 merged by jenkins-bot:

[mediawiki/core@master] mediawiki.special.block: Fix table overflow/width

https://gerrit.wikimedia.org/r/1101842

I don't see any overlapping issues on beta on Firefox or Chromium.

Test environment: https://test.wikipedia.beta.wmflabs.org MediaWiki 1.44.0-alpha (e7131a7) 07:05, 16 December 2024.
Test browsers:

• Firefox 128
• Chromium 131