Help talk:Table

Dark Mode issue: Tables with "style=background: none" are difficult to read.

When viewing tables with the background set to transparent/none, the text is made a dark grey (#202122) on a black background, making it difficult to read. This can be seen on the Help page under the "Non-rectangular tables" section in "Workarounds":

Help:Table#Non-rectangular tables

Notably, this behavior is different depending on if the background is set to "transparent" or "none": transparent has links be in their usual blue/purple colors, while none has links also be set to that gray color.

I'm sorry if this isn't the right place to report this; There were many places that seemed like they could be viable candidates. Dinjoralo (talk) 14:11, 20 March 2026 (UTC)

@Dinjoralo: See: Help:Advanced table features#Avoid background:none or transparent.

There are multiple sections on color starting here:

Help:Advanced table features#Colors in tables.

--Timeshifter (talk) 17:34, 20 March 2026

@Dinjoralo: I see the problem in dark mode. I removed that section from the help page until someone can fix it. I don't have the time right now. Here it is:

Cell borders can be hidden by adding border: none; background: none; to the style attributes of either the table or the cell, though this may not work in older browsers. Another use case for this is for implementing aligned multi-column tables: Wikitext {| class=wikitable style="border: none; background: none;" ! colspan=2 rowspan=2 style="border: none; background: none;" | [[File:Pfeil_SO.svg |none|link=|20px]] ! colspan=3 | To |- ! Solid !! Liquid !! Gas |- ! rowspan=3 | From ! Solid | Solid–solid transformation || Melting || Sublimation |- ! Liquid | Freezing || {{sdash}} || Boiling/evaporation |- ! Gas | Deposition || Condensation || {{sdash}} |} Produces To Solid Liquid Gas From Solid Solid–solid transformation Melting Sublimation Liquid Freezing — Boiling/evaporation Gas Deposition Condensation — The removal of the link on an image is dependent on it being purely decorative (as it will be ignored by assistive devices). Wikitext {| class=wikitable style="border: none; background: none;" ! scope=col | Year ! scope=col | Size | rowspan=5 style="border: none; background: none;"| ! scope=col | Year ! scope=col | Size | rowspan=5 style="border: none; background: none;"| ! scope=col | Year ! scope=col | Size |- | 1990 || 1000<br>(est) || 2000 || 1357 || 2010 || 1776 |- | 1991 || 1010 || 2001 || 1471 || 2011 || 1888 |- | colspan=2 style="text-align: center;"|⋮ | colspan=2 style="text-align: center;"|⋮ | colspan=2 style="text-align: center;"|⋮ |- | 1999 || 1234 || 2009 || 1616 || 2019 || 1997<br>(est) |} Produces Year Size Year Size Year Size 1990 1000 (est) 2000 1357 2010 1776 1991 1010 2001 1471 2011 1888 ⋮ ⋮ ⋮ 1999 1234 2009 1616 2019 1997 (est)

--Timeshifter (talk) 16:28, 21 March 2026 (UTC)

Understood. I saw a table like this in an article, and didn't know if the original had a specific reason for using those styles. I'll go ahead and edit that article to remove the background color from the table. Dinjoralo (talk) 16:55, 25 March 2026 (UTC)

Potential glitch

For a while now, I’ve had an issue where I can’t select a large range of cells that requires scrolling down without the page forcing me to scroll back up. For example, at Foreign relations of Palau, if I try to select all the countries under the “Country” column in the table, I would normally click on “Australia,” hold the button, and scroll down to “Trinidad and Tobago.” However, I’m no longer able to do this because the page keeps scrolling back up. Is anyone else experiencing this? Semsûrî (talk) 09:10, 30 March 2026 (UTC)

I've never done that. But if I want to copy a column I go into the visual editor. Then I click on the top cell of what I want to copy. Then shift-click on the bottom cell of what I want to copy. Then ctrl-c to copy the selected cells. --Timeshifter (talk) 14:10, 30 March 2026 (UTC)

I did not know of that trick. Thank you. Semsûrî (talk) 15:19, 30 March 2026 (UTC)

@Semsûrî: You're welcome. See also: Help:Creating tables#Insert blank row/column and the following sections on moving, deleting, and copying columns. And: Help:Table#Column operations. --Timeshifter (talk) 15:32, 30 March 2026 (UTC)

Help. Collapsible tables

Note: Catcus_DeMeowwy. Discussion has been moved here from Help talk:Collapsing tables and more. See: Help:Collapsing tables and more.

Hi folks. Not expecting much because I get that people are busy. I am confused with the template: is it possible to format a table so that rows after a certain point are hidden until you click [show], basically a wikitable mw-collapsible innercollapse class inside of the table, so that the section below is hidden? My attempts all broke the table. Table WIP is at User:Catcus_DeMeowwy/Chinese_herbology#Usage_of_some_Chinese_herbs for reference.

Other talk topics asking the same have no replies/solution. I have left other attemps (template:hidden_begin) in tact to show my working. Catcus DeMeowwy (talk) 11:49, 1 May 2026 (UTC)

Bumping topic at 21:24, 3 May 2026 (UTC) ~ ~Catcus DeMeowwy (talk)

~ ~Catcus DeMeowwy (talk) 21:24, 3 May 2026 (UTC)

@Catcus DeMeowwy: See Help:Collapsing tables and more#Collapsible tables. The class is added to the table, not a row. Trying to add markup around specific rows is going to break the table markup. Jroberson108 (talk) 05:00, 4 May 2026 (UTC)

Need numbers with ~ in front to sort correctly

Need option for ~ which is often used in front of numbers in tables. For example in this table:

• Casualties of the Gaza war#Civilian to combatant ratio

See Template talk:Circa/doc/sortable and:

• Help:Sortable tables#c. for circa

Need a version of this template for when ~ is used in front of numbers in tables.

Or better yet the mediawiki software needs to ignore ~ if data-sort-type=number is used in the column head.

See Help:Sortable tables#Forcing a column to have a particular data type. --Timeshifter (talk) 18:56, 5 May 2026 (UTC)

@Timeshifter: On that cell, set data-sort-value="" to the same numeric value excluding the tilde. Jroberson108 (talk) 05:42, 6 May 2026 (UTC)

@Jroberson108: Thanks. I created this section:

Help:Sortable tables#~ for approximately --Timeshifter (talk) 21:49, 6 May 2026 (UTC)

Making two table the same layout?

@Noleander In Special:Permalink/1353013986#Water sources and sinks, there's two tables that ideally should be rendered with the same width columns without resorting to ugly hacks like fixed pixel widths (which I'm not willing to sink to). The biggest variation is in the first column, with the longest cell being 9 Mouth of Atbarah River in the second table. Is there some way to say (in both tables) Make this column the correct width to contain "9 Mouth of Atbarah River"? That should get both of them layed out the same while still allowing the formatting to adapt to whatever local fonts and screen-size are in use. RoySmith (talk) 17:18, 7 May 2026 (UTC)

Or, more generally, is there some way to say "Make these two tables have the same width columns, whatever that turns out to be at render time?" RoySmith (talk) 17:20, 7 May 2026 (UTC)

I'm not enough of a table-smith to know how to accomplish that. I'm sure the table rendering software dynamically sets column widths based on a variety of factors. Forcing table columns to a specific width (even if it is only "match that other table") may run contrary to the spirit of "rely on the table rendering software to set the column widths." But maybe some table guru knows a way. Noleander (talk) 17:58, 7 May 2026 (UTC)

I don't know why one would want the 2 tables to have the exact same column widths.

And why are you linking to an old version of the page? When I look at the latest version (Nile#Water sources and sinks) the 2 tables are fairly similar in column widths. Except for the first column on the left.

You could force the width in various ways. See

• Help:Width of tables, columns, and cells

--Timeshifter (talk) 21:33, 7 May 2026 (UTC)

I want them to have the same widths because the two table display the same type of information and I want to make it easy for a reader to visually follow a column from one to the other. RoySmith (talk) 21:41, 7 May 2026 (UTC)

OK, though I don't think it is that hard to follow down. Dig around that help page I linked to. --Timeshifter (talk) 22:02, 7 May 2026 (UTC)

Hello, RoySmith. Your desire to have at least the left-most columns of similar, vertically stacked tables is a worthy one. I know of many music-related articles which take care to do this. See, for example, the Year-end charts tables for Rihanna's Rated R album. The upper table (2009 year-end chart performance for Rated R) uses the same width as the lower table (2010 year-end chart performance for Rated R). It does this (I may have done it myself, years ago, but I don't care to check) by previewing the similar tables, and determining the widest natural cell in the first column. By trying style="width:24em;", style="width:18em;", style="width:19em;", etc., you can find the smallest width that comfortably holds the content. Then you can add that constraint to all the matching columns of parallel tables.

We made similar suggestions when trying to work out a manual of style for discographies; see these examples. Or (more Rihanna again) Rihanna albums discography, Rihanna singles discography, and Eminem singles discography, etc. We constrained the left-most column or two artificially, but the Year column (on singles tables) is automatically always the same width, and after that the number of columns can vary, but the reader isn't struggling to parse the rows so much. See?

Also check out the code for the individual chart columns, e.g., style="width:2.8em;font-size:90%;". Here, it's extremely useful to have the columns all the same size, even though some headings like "SWI" need more space than others, like "US". Just use a uniform width (in ems, of course) that suits the page.

You don't have to (and IMHO shouldn't) try to constrain all of the columns, nor the table width, because it's okay for the right-most column(s) to be a bit "ragged". The human eye is happy to match the orderly-looking items at the left, and figure out the variable details to the right. The user agent (browser) is doing the rendering for you; let it. And you mentioned ugly hacks like fixed pixel widths which is, I agree, a Bad Thing^TM. But by using em units, you flexibly constrain the table (a bit) depending on the font size. If you use px units, you don't know what the reader will see, because you can't know their standard font size or zoom rate, etc.

I hope this helps, even months after your query. — JohnFromPinckney (talk / edits) 14:23, 15 October 2026 (UTC)

@JohnFromPinckney Thanks for the reply. That got me thinking on this some more and I came to the realization that I might be able to do exactly what I want by adding an invisible data row which contains the longest string in that column of either table. I asked Claude and he came up with essentially the same idea :-) I'm not sure how to implement that concept in wiki markup, but I've been playing around in my sandbox.

Technically, what I want is "the string that renders the widest". Depending on the end-user's fonts, may not be "the string with the most characters", but that should be a reasonable approximation and at worst I could include multiple invisible rows with the various candidates for "widest". RoySmith (talk) 15:10, 15 October 2026 (UTC)

No, I hope I didn't imply that you should look for the cell with the most characters. I meant to use the one that takes up the most space when rendered.

And I would like to counsel against adding extra invisible rows (and I wouldn't know how to do that either). To what end? What HTML do you hope to end up with, and what will screen readers and other user agents do with that result? Why not just use the single style constraint as I suggested? Try adding ! scope="col" style="width:11em"| to the first column of both tables, and see what you think.

I have taken the liberty of mucking around in your sandbox (I hope you don't mind), but I have immediately reverted my changes. See what you think of this version. By the way, I don't know why you are starting your tables at font-size: 85%; but that's really the lower limit of readability (cf. MOS:SMALL) and makes your superscripts and footnotes even smaller. And the caption(s) should be simple; it might be better all around to move the legend to a spot after the table(s). Those centered bullet items look a little funny.

Finally, I don't see why you have two tables; they look identical, just with different data rows (for whatever reason). The difference between the tables should be reflected in the captions. Of course, maybe this is just a dummy example you worked up by splitting an existing, larger table. Yes? If so, carry on. :-)

Please take a look, and accept my apologies if I have barged in unwantedly. Hoping this helps, — JohnFromPinckney (talk / edits) 15:56, 15 October 2026 (UTC)

Playing in my sandbox is perfectly fine. As for the font size 85%, I just grabbed the existing markup from Nile as a starting point for my exploration. RoySmith (talk) 16:11, 15 October 2026 (UTC)

The only reason I have the two different tables in the sandbox was just to play around with. I've lost track of the original revision that prompted me to ask about this during WP:FAC, so I just took the one table that currently exists and split it up into two, one with longer entries, the other with shorter ones, just to give me something to experiment on. At this point, it's really become an academic exercise in trying to figure out how to make this work. Your point about my idea not playing well with screen readers is completely valid. RoySmith (talk) 16:14, 15 October 2026 (UTC)

@JohnFromPinckney and RoySmith: If the goal is to match the column widths on multiple table stacked vertically, then I would agree with JohnFromPinckney's approach. Find the widest width for each column and apply the style to each respective column. Consider removing the nowrap class and <br> use in headers, and use ! scope="col" style="max-width:11em"| instead so it can wrap naturally on smaller devices where you usually can't see multiple tables at the same time. Also, for sortable tables, consider using {{sort under}} to move those sort buttons under the header text to narrow those columns some, especially the numeric ones, since it looks like all the headers have more text than their data cells. Jroberson108 (talk) 17:10, 15 October 2026 (UTC)

The link to {{sort under}} was purple, so I must have seen it before, and then forgotten. It's too bad, too, because that's a handy little template. Thanks, Jroberson108, for the reminder (and the work implementing it). — JohnFromPinckney (talk / edits) 20:53, 15 October 2026 (UTC)

Thinking about it, maybe max-width won't work if one column is normally narrower than another that has wider data cell text. It would have to be width, unless the headers remain uniform and the widest part. Jroberson108 (talk) 17:25, 15 October 2026 (UTC)

See also: Help:Advanced table features#Side-by-side columns of tables, images, lists and the related sections before and after it. You could place divs around the 2 tables, and then mark each div with a maximum width using the units of your choice.

<div style="display:inline-table; max-width:Xem;">
-- first table --
</div>
<div style="display:inline-table; max-width:Xem;">
-- second table --
</div>

This has the added advantage that if the screen is wide enough, the tables will go side-by-side.

Or you could put both tables in the same div and keep them in the same column. You could try adding more columns too. Another column will be below the first column unless the page is wide enough to allow 2 side-by-side columns. --Timeshifter (talk) 20:06, 15 October 2026 (UTC)

Obsolete attributes

8rz, at Help:Table#Cell content indenting and padding, why are we encouraging the use of cellpadding= and cellspacing=? These have been obsolete since HTML 5 (2014). --Redrose64 🌹 (talk) 14:06, 23 September 2026 (UTC)

I am aware of their obsoleteness. Having been editing on Wiki for years, I found about the difference between spacing and padding yesterday, so I added their definition to help future editors distinguish between the two.

One example I've come across is in {{tennis bar}} which uses cellpadding=0; cellspacing=0 in its code. Replacing cellpading with style=padding:0 (example) fixes 1/2 of the deprecated code, but because there is no replacement for cellspacing= (as listed in Wikipedia:HTML5#Table attributes), it leaves whitespace between the cell (276) and the text (Sampras) after it.

Pinging @Timeshifter: who have done the most editing on table-related help pages recently to chime in. 8rz (talk) 15:02, 23 September 2026 (UTC)

I noticed a couple uses of this phrase, or a variation: "Allowed, obsolete but rarely used" on Wikipedia:HTML5#Table attributes. I also notice multiple breakdowns at Wikipedia:HTML5#Scope of what HTML 5 alone has difficulty with.

For Help:Table, other table help pages, I suggest explaining what HTML 5 will do, and then why deprecated stuff may be better at times. --Timeshifter (talk) 16:41, 23 September 2026 (UTC)

@8rz: In cellpadding=0; cellspacing=0 the semicolon is invalid - if a tag has two or more attributes, they are delimited with whitespace, nothing else.

style=padding:0 is also invalid; any attribute value that contains a colon must be quoted, as in style="padding:0"

The replacement for cellspacing=0 is style="border-spacing:0" but that should not be necessary, since zero is the initial value. More at the CSS 2.1 spec, section 17.6 Borders. --Redrose64 🌹 (talk) 22:18, 23 September 2026 (UTC)

Fixed the aforementioned template. Many outdated "tables" use the above attributes. They would need to be changed as they are encountered. 8rz (talk) 23:49, 23 September 2026 (UTC)

@Redrose64: In wikitext style=padding:0 works fine without the semicolon or the double quotes. If you add more styles, then the semicolon is needed to separate them: style=padding:0;margin:2px, but the double quotes are not necessary unless there is a space: style="padding:0; margin:2px". Also, when the parser hits the closing quotation mark, it knows the style declaration has ended, even without a trailing semicolon. And units are not needed for the zero in style=padding:0 since zero is zero regardless of unit. --Timeshifter (talk) 04:30, 24 September 2026 (UTC)

Please read what I wrote. My only mention of a semicolon was its non-validity between two attributes - of course they're required between declarations. I never said they were required after the last declaration, either. I also never said anything at all about units. --Redrose64 🌹 (talk) 18:33, 24 September 2026 (UTC)

I was just providing additional info for all. My main point was that style=padding:0 is not invalid. Also, style=border-spacing:0 is valid without the double quotes. Because wikitext has its own rules, and does not follow all HTML or CSS rules. --Timeshifter (talk) 20:29, 24 September 2026 (UTC)

I was just providing additional info for all You replied to me, specifically. --Redrose64 🌹 (talk) 17:02, 25 September 2026 (UTC)

Accessibility standards for tables

Hi all! Does Wikipedia follow (or strive to follow) WCAG guidelines?

WCAG 2.0 AA guidelines suggest avoiding merged cells in tables, however they are all over the place. Just curious if we are 1) aiming to follow said guidelines, or 2) using the correct markup to make these tables accessible. With a mission of accessible information for all, it seems like that would align with Wikipedia values. Ads Augs (talk) 22:07, 10 October 2026 (UTC)

@Ads Augs: Can you link to the specific guideline? And please link to an example table with the problem. --Timeshifter (talk) 01:19, 11 October 2026 (UTC)

Merge Help:Table and Help:Basic table markup

There is a lot of duplicate info on Help:Basic table markup and Help:Table. Seems like a lot of this was done during the last cleanup and restructuring of Help:Table a few years ago? The former seems less developed, so I would suggest gutting any remaining useful parts or better instructional methods, then deleting that page.

Table wikitext syntax explanation is repeated in:

• Help:Basic table markup#Introduction (main description) / Help:Basic table markup#Using double marks with tables.
• Help:Table#Wikitext markup. More flushed out.

Table wikitext syntax example is repeated in:

• Help:Basic table markup#Example table.
• Help:Table#Wikicode syntax tutorial (table/caption/rows/cells sub-sections).

The latter, I feel, is overly basic being divided into steps, and takes up too much vertical space due to the repeat wikitext examples. The former's approach seems better with a single wikitext/render example followed by its prose dissection. Help:Basic table markup#Cell contents on new lines info is also repeated, though its approach is not as concise as Help:Table#Wikitext markup and Help:Table#Adding cells.

HTML attribute syntax explanation is repeated in:

• Help:Basic table markup#HTML attributes (main description) / Help:Basic table markup#Common attributes.
• Help:Table#HTML attributes. More flushed out.

HTML attribute syntax example is repeated in:

• Help:Basic table markup#HTML attributes ("Adding ..." sub-sections).
• Help:Table#Adding attributes.

The latter, I feel, reads better with its concise info and prose dissection of the wikitext/render example as opposed to the former's "sectioned" approach that takes up too much vertical space just to explain syntax.

Table wikitext versus HTML is repeated in:

• Help:Basic table markup#How tables are formed
• Help:Advanced table features#Other table syntax

Repeated in different formats, where I feel the former is easier to read with its prose dissection of the wikitext/HTML/render example that maintains the table structure. Although MOS discourages HTML tables because wikitables are easier to customize and maintain, they exist on:

• 15,053 user pages
• 4,425 "Wikipedia" pages
• 1,120 template pages
• 559 other (non MOS/Help/Talk) pages (some may be HTML explanations)

Thoughts and opinions on the merge? Jroberson108 (talk) 17:31, 16 October 2026 (UTC)

@Jroberson108: Whatever you want to do is fine. Getting rid of duplicate or bad info is a good idea. --Timeshifter (talk) 18:10, 16 October 2026 (UTC)

I'm done with merging and minor restructuring. Help:Basic table markup should not be needed anymore. Jroberson108 (talk) 09:11, 23 October 2026 (UTC)

@Jroberson108: Do whatever you feel is best. Please update {{Table help}} too. And please fix any links towards Help:Basic table markup. --Timeshifter (talk) 22:44, 23 October 2026 (UTC)

Side by side tables

Concerning Help:Advanced table features#Side-by-side tables and the related help sections that follow.

Jroberson108. Is there anything wrong with what I did here:

• User:Timeshifter/Sandbox336

--Timeshifter (talk) 07:09, 6 November 2026 (UTC)

Yes, you changed the table's display from the default "table" to "inline-grid" (inner grid). The section says put it on the div wrapper. Visually it may look ok, but it can cause accessibility issues in some browsers, per MDN. I added the same link to the section. It's important to follow MOS and other accessibility guidelines like MDN's. It's more than just being able to "read" a table, but announcing the caption and headers properly in the right structure, as well as some other things.

As far as inline-table goes, increase the cells in each row and you will see mobile horizontal scroll doesn't work anymore, as mentioned in the section. Jroberson108 (talk) 08:18, 6 November 2026 (UTC)

There needs to be an example table shown there of that loss of mobile horizontal scroll by using inline-table. You did not link to any kind of guideline on that. So readers need proof.

And what specific accessibility issues is MDN referring to? And MDN is referring to HTML tables, not wikitables. There might be a difference. So I need to see it to believe it. --Timeshifter (talk) 19:53, 6 November 2026 (UTC)

I disagree with overcomplicating a simple section that demonstrates how to do something. To achieve this, "do this" with example. The only reason the "don't do" note is there is because there is a history of doing it. We don't need to convince or prove it to someone, just follow the example. Are you going to add examples for every possible "don't do" display type too along with what screen readers actually read in those situations? It's overkill. Keep it short and simple.

And, there is no difference when translated. See Help:Table#Wikitext and HTML example. Jroberson108 (talk) 21:27, 6 November 2026 (UTC)

I don't see any problems with horizontal scrolling on mobile with wider tables using display:inline-table; or display:inline-grid; on the top line of the table wikitext. See added sections at User:Timeshifter/Sandbox336.

What are the accessibility problems from using display:inline-grid;? The MDN page does not say. And it mentions no problems with display:inline-table; --Timeshifter (talk) 00:29, 7 November 2026 (UTC)

There is more than just what you "see", hence my earlier statement: It's more than just being able to "read" a table. I see no reason to doubt MDN's findings. If you are really interested, then I suggest you research it. Jroberson108 (talk) 00:39, 7 November 2026 (UTC)

MDN said: "In some browsers, changing the display value of a <table> element to block, grid, or flex will alter its representation in the accessibility tree. This will cause the table to no longer be announced properly by screen reading technology."

Graham87, using his screen reader, had no problems with any of the tables using display:inline-table; in the table wikitext at User:Timeshifter/Sandbox335.

In the past I remember having weird problems now and then with display:inline-grid; in div wrappers. display:inline-table; worked most consistently.

So I think it should be recommended exclusively just to make things simpler, and to respect the MDN guidline.

And I have not seen any horizontal scrolling problems in mobile by using display:inline-table; on wide tables. See the sandboxes.

You even recommended it in an edit summary I happened to see again just now: "Move 'inline-table' to table. Div not needed if just tables.". Concerning the 3 side-by-side tables.

If there was a horizontal scrolling problem in the past, I am not seeing it now after multiple tests.

I see another problem though. See latest sandbox: User:Timeshifter/Sandbox337. I have looked at it in Firefox and Chrome. Note that in mobile the caption is bunched up just above the first column. Most visible in the second table on that page. Only on mobile. --Timeshifter (talk) 02:41, 7 November 2026 (UTC)

I can see the horizontal scrollbar missing under the table when visiting User:Timeshifter/Sandbox336#Wider_tables._display:inline-table;. Just resizing the browser window is enough to show it missing. It's missing on my Android phone browser too. My edit summary was prior to fixing that section. This still stands: Do not use display: inline-table; on a table, as it can break the responsive scrolling behavior on narrow screens (e.g., horizontal scrollbar). Jroberson108 (talk) 02:43, 7 November 2026 (UTC)

OK. Are you on a PC? What version of Windows? What browser? Is it only one browser? Someone might pass this info to the browser developers. What browsers on the Android phone?

Do you have a problem with horizontal scrolling when display:inline-table; is used on divs used with wide tables? See example here: User:Timeshifter/Sandbox337.

I noticed a peculiar mobile problem there (struck out above) because at one point I had display:inline-table; on both the table and the div. See diff.

It looks like there is no way to use any display:inline-VALUE; in the table itself without possible problems according to MDN and your tests.

In divs I have had the best luck using display:inline-table; over anything else. For years.

I added divs with display:inline-table; around the tables here: Help:Advanced table features#Side-by-side tables with single caption. Instead of using it within the table. --Timeshifter (talk) 03:40, 7 November 2026 (UTC)

It is not a browser or OS issue. MediaWiki or Wikipedia adds the responsive styling. This display just happens to break it. It looks like there is no way to use any display:inline-VALUE; in the table itself without possible problems according to MDN and your tests. Correct, which is included in the section's note. I still recommend using inline-grid on the div instead of inline-table since the latter adds extra anonymous row/cell boxes that aren't needed. Don't ask me to explain. The example is simple enough to follow. I recall testing the example that said These tables below wrap better with display:inline-table; instead of display:inline-grid; and found no difference. I recall there was a difference when used on the table though, so assumed you meant table, not div. Do you have an example of inline-grid on a div not working correctly? Jroberson108 (talk) 04:00, 7 November 2026 (UTC)

See again: User:Timeshifter/Sandbox336#Wider tables. display:inline-table;. I am on Win 11 Pro. In both Firefox and Chrome horizontal scrollbars show up when the table is wider than the screen. In both desktop and mobile.

On my iphone SE 2020 the scrollbar only shows up temporarily, and then disappears. It shows again when vertical scrolling. Then disappears. In all cases the full table can be seen by dragging it.

I see the same thing on the iphone with inline-grid in the table. Or with nothing in the table. So I think this is default horizontal scrolling with wide tables on iphones.

I discovered something this time when using inline-table within the table wikitext. On Chrome in the iphone the caption is stacked up above the first column. So that is another problem with using it in tables. It doesn't happen in Firefox in the iphone.

Please tell me your desktop PC specs and browsers. Is it Windows, Apple, or what? It would be nice if this gets fixed. You say you are seeing no horizontal scrollbar even on desktop? On your mobile phone is it possible you are not seeing the temporary horizontal scrollbar? It is very thin at the bottom of the screen, and can be hard to notice. It disappears fast.

I no longer see a problem with inline-grid in the divs for the 2 tables at the bottom of Help:Advanced table features#Side-by-side tables.

since the latter adds extra anonymous row/cell boxes that aren't needed. Don't ask me to explain. Do they show up to the reader? If not, how do they matter?

Bottom line is we need to offer both display options for divs. Whatever works. I really have seen one work better than the other at times. When I google the 2 display options there is complex reasoning about which works better when. But it is easier to try both, and keep the one that works better.

--Timeshifter (talk) 19:28, 7 November 2026 (UTC)

Apple's WebKit may inject their own styling. The responsive horizontal scrollbar that Wikipedia adds should show up right under each table. This does not occur in all of my tests. Instead, the default horizontal scrollbar at the bottom of the entire page is the only way to scroll those tables, which tables can overflow past the main content area and cover other elements.

For the caption, Wikipedia aligns them center, and responsively aligns them left on mobile so that it is visible without having to scroll right to see if one exists on wider tables. If using inline-table causes an issue on iPhone, then that's a good reason not to use that display. I don't have an iPhone, so I can't test it. It probably has something to do with my earlier statement on inline-table adding extra anonymous row/cells that aren't needed because its children are not table elements (its meant for use on content that has a table's inner structure). See anonymous boxes. No, you don't "see" the anonymous additions, its used in the layout tree.

If adding inline-grid to the div causes similar or other issues, then inline-block on the div is the only other option, and has the least overhead added and works for this application, but it default aligns to the bottom and will require vertical-align: top; each time. Or we can just remove all that and rely on the flex template that solves adding a gap without the horizontal layout issues mentioned. Using templates and classes are preferred over inline styles because they are tested more and a fix can be deployed/applied easily without having to find-and-replace usage like with inline styles. I already fixed that template so that tables maintain their responsive horizontal scrollbars. Jroberson108 (talk) 20:29, 7 November 2026 (UTC)

Side by side tables. Part 2

See: User:Timeshifter/Sandbox340 It's a couple wide plain tables without divs or display. On my iphone in Firefox and Chrome I see the standard default scrollbar at the bottom of the screen that disappears fast. Have to scroll up and down vertically for it to return. On the PC the scrollbars are directly under the tables in Firefox. But in Chrome there is only a scrollbar at the bottom of the window.

User:Timeshifter/Sandbox337. Wider tables in divs using inline-grid. User:Timeshifter/Sandbox341. Wider tables in divs using inline-table. User:Timeshifter/Sandbox342. Wider tables in divs using inline-block.

For the above 3 sandboxes I see the standard temporary scrollbars in Firefox and Chrome on my iphone. On my desktop PC I see the scrollbar at the bottom of the window with both browsers.

Doing some tests with a list of images: inline-block on the divs here worked the same as inline-table on the talk page I copied it from:

• User:Timeshifter/Sandbox338

Can {{Flexbox wrap}} achieve the same result? A template that one only needs parts at the top and bottom of the image list would be great. Does one exist? And does it work on cell phones?

User:Timeshifter/Sandbox339 has the image list without divs. So it forms a column of images.

Of course, I need flexbox tests for multiple inline tables, and combinations of inline images and tables.

So we can now offer people 3 display:inline- choices to try out for divs: grid, table, block

What is the order of recommendation? And why? --Timeshifter (talk) 22:51, 7 November 2026 (UTC)

If you are only seeing the scrollbar at the bottom of the entire page, then that is not the missing table's responsive scrollbar that should appear under the table, not at the bottom of the page.

Not sure what you mean by A template that one only needs parts at the top and bottom? That template wraps everything as well as each block (table or image). That's the only way to do flex.

You already said inline-table causes caption issues on iPhone, so not sure why you even kept that one in the list. It breaks layout, so it is out.

I disagree, don't advice people to use one of the display options that are not fully tested and likely to be misapplied. Just in our testing alone we found issues with some that should not be used in certain ways. Instead, use the template that again is more tested and easier to fix over some untested advice. Editors using these inline styles are not going to fully test and just trust it works. Jroberson108 (talk) 23:42, 7 November 2026 (UTC)

I tried using {{Flexbox wrap}} on this list of images here:

User:Timeshifter/Sandbox339

I used {{Flexbox wrap|start}} and {{Flexbox wrap|end}} on the top and bottom. It did nothing.

So I used it with just the top 3 images. I also added {{Flexbox wrap|break}} between the 3 images. I used flex=none to push the images together. That is not mentioned in the template doc. (since fixed).

inline-table does not break layout. And it does not cause caption issues in divs. Only when used inside a table. Both Firefox and Chrome. See it here inside the table wikitext:

User:Timeshifter/Sandbox336#Wider tables. display:inline-table;

In divs: Grid, table, and block all do not show the horizontal scrollbar directly below the table. Both in my PC, and in my iphone. --Timeshifter (talk) 00:56, 8 November 2026 (UTC)

The flex=none" property is in my example code, otherwise I wouldn't have included an example. Yes, it's doc could use more explaining. I suggest mentioning it on the talk page since the maintainer knows more. Are you sure that in divs, the horizontal scrollbar doesn't show? I'm still on Windows 10. If that's the case, then more reason to only use the flex template.

I looked over your three pages. Yeah, these don't work.

• User:Timeshifter/Sandbox342: inline-block
• User:Timeshifter/Sandbox341: inline-table

User:Timeshifter/Sandbox337 inline-grid did work for me, but not sure what else issues might be found later on. Again, best to only use the flex template. Jroberson108 (talk) 01:07, 8 November 2026 (UTC)

I added some related info to that template's doc. Jroberson108 (talk) 01:45, 8 November 2026 (UTC)

Plain wide tables in sandbox340 only have the temporary scrollbars at the bottom of the screen in iphone Firefox and Chrome.

• User:Timeshifter/Sandbox343: {{Flexbox wrap}}

On PC in Firefox and Chrome: Horizontal scrollbar only shows up at bottom of window. On iphone: horizontal scrollbar does not show up at all in Firefox or Chrome.

I don't like flexbox wrap because it does not have an easy way to push the images and/or tables as close as with the divs.

I like the divs because I haven't found hardly anything they can't do in the way of inline stuff and columns. See the discussions at Template talk:Column-generating template families.

Horizontal scrollbars aren't really needed on cell phones. We can easily drag the wide tables right and left with our finger. And a horizontal scrollbar at the bottom of the window on a PC works fine.

I need to look at my Win 10 Pro PC. --Timeshifter (talk) 01:53, 8 November 2026 (UTC)

Plain and flexbox tables all show the table's horizontal scroll.

it does not have an easy way to push the images and/or tables as close as with the divs Request a gap parameter. It uses 1em, as mentioned in the section.

Horizontal scrollbars aren't really needed on cell phones. Incorrect assumption. They keep the content in the main content area. Jroberson108 (talk) 02:05, 8 November 2026 (UTC)

"Plain and flexbox tables all show the table's horizontal scroll." On Win 11 Pro PC plain tables have the scrollbar right next to the table. Flexbox tables only have the scrollbar at the bottom of the window.

I haven't seen a table-adjacent scrollbar on my iphone in Firefox or Chrome in any of the tables and sandboxes we have discussed in this thread. Including plain tables.

But on my iphone I see the temporary scrollbars in Firefox and Chrome for all the div options we have discussed: Grid, table, and block. Do these keep the content in the main content area? --Timeshifter (talk) 02:51, 8 November 2026 (UTC)

I hope you are dragging your Windows browser edge far enough to see the scrollbar. It only shows at mobile widths, which are less than 640px, at least on Vector (2022) (same width for MinervaNeue). I just resize all the way in and come out some to see them.

I wonder what width your iPhone is and if you are in portrait?

For me, the table scrollbars do not show on Windows or Android for inline-table and inline-block on a div wrapper. It's the same issue as using inline-table on the table. Jroberson108 (talk) 03:04, 8 November 2026 (UTC)

I just carefully retested responsive table scrollbars on everything, but did find Firefox had a difference. I'm no longer testing ones on the table since they all cause accessibility issues or fail. I'm only testing ones on the div or that template. Windows 10: Brave, Chrome, Edge, and Firefox. Android: Brave, Chrome, and Firefox.

• inline-table and inline-block failed everywhere.
• inline-grid only failed in Firefox (Windows and Android).
• Flexbox wrap passed everywhere.

And I did check to make sure Firefox on Windows and Android do show table scrollbars on plain tables (no display style), which they do.

Note, I mainly use Brave these days. Too bad we don't have someone with an Apple computer to test.

If your browser does not normally show a table scrollbar for a plain table (no display style) or adds it itself, then those tests don't help. Only test where the scrollbar would normally show so that you can see if the display style breaks that responsive behavior. Pretty much you just need to test what's left: inline-grid and that template. The template seems the better choice in my opinion since for me it does not remove the scrollbar in all cases while the former does remove it on Firefox. From what you said earlier, it sounds like iPhone just adds scrollbars to the tables on its own, so iPhone tests don't help to figure out where the scrollbar is removed due to the display style or template. Jroberson108 (talk) 05:11, 8 November 2026 (UTC)

I have test results now at the top of these pages linked below. This way they can be updated as needed. There are many mistakes in my previous posts. This way I can easily correct, clarify, and update my notes.

User:Timeshifter/Sandbox340. Plain wide tables. User:Timeshifter/Sandbox343. Wide tables with {{flexbox wrap}}. User:Timeshifter/Sandbox337. Wide tables in divs using display:inline-grid. User:Timeshifter/Sandbox341. Wide tables in divs using display:inline-table. User:Timeshifter/Sandbox342. Wide tables in divs using display:inline-block.

I have test results now at each sandbox. Tests using my Win 11 Pro PC, and my iphone SE 2020. I need to test on my Win 10 Pro PC. --Timeshifter (talk) 21:32, 8 November 2026 (UTC)

I remember years ago you said you didn't use your iPhone much. I take it that hasn't changed? I'm struggling to understand your iPhone experience. "sloppy and sliding around"? Some of it sounds like if you long tap or tap once on the table, then you can scroll just the table left and right without needing to pinch/zoom?

To clarify on Android, I don't have to pinch/zoom when the table's scrollbar is present, I can just scroll the table left and right with its normal, readable font-size, which is how it should be. When that table scrollbar is not present, the table extends past the main content area and you have to pinch/zoom out to see the whole table (can become unreadable) and/or use the page scrollbar to scroll all content left and right, which is how it should not be.

Wikipedia adds that responsive scrollbar when the screen is less than 640px wide so the table stays in the main content area in the same readable font size as you scroll it left and right, so no pinch/zoom or page scrolling should be needed. What is the viewport width of your phone in portrait orientation? Get "Viewport" (not "Screen") at findscreensize. All my Android browsers say 360 x (661 or 669). Because my width is 360px, the horizontal scrollbars show on each table that extends past the main content area, which is greatly needed on my 360px wide screen.

Your Windows 11 tests match my Windows 10 and Android tests. For the plain table tests, it works in all Windows/Android browsers, and from your response, tapping the table once allows scrolling of just the table in iPhone Chrome/Firefox without the need to pinch/zoom. inline-table and inline-block are obviously problematic across the board, so I'm ignoring those to simplify testing. inline-grid only causes issues in Windows/Android Firefox, and from your response, iPhone Chrome/Firefox too. Also, you forgot to do the template one: User:Timeshifter/Sandbox343. Jroberson108 (talk) 23:00, 8 November 2026 (UTC)

I see you updated the Flexbox wrap template test. To clarify, what is needed is the ability to scroll the table left and right instead of the page, not that the scrollbar must be visible. On iPhone, from your response, it seems you can scroll the table, but you can't always see the scrollbar except when scrolling, which is something iPhone did probably to improve aesthetics (hide bar until used?). On Android and Windows, the table scrollbar is always visible. So your flexbox wrap test worked in all browsers just like my tests. From these results, it seems pretty obvious we should use Template:Flexbox wrap and not any display styles. Note, I did request a "gap" parameter to lessen that space, which does seem useful in certain circumstances. Jroberson108 (talk) 01:05, 9 November 2026 (UTC)

I still don't use the iphone much. From Google AI:

The CSS viewport size of the iPhone SE (2020) is 375 × 667 CSS pixels in portrait mode and 667 × 375 CSS pixels in landscape mode. Display & Viewport Specifications CSS Viewport (Portrait): 375 × 667 px CSS Viewport (Landscape): 667 × 375 px Physical Screen Resolution: 750 × 1334 pixels Device Pixel Ratio (DPR): 2.0 (each CSS pixel maps to 2×2 physical pixels) Physical Screen Size: 4.7 inches diagonal

The results for the 3 display choices are almost exactly the same. There are no table-adjacent scrollbars in Win 11 Pro PC or iphone, except for the inline-grid in the Chrome browser in the PC . It is the only example. None of the wide tables can be dragged right or left individually in both PC and iphone except for that one example.

{{Flexbox wrap}} has table-adjacent scrollbars on Win 11 Pro PC in both Firefox and Chrome. In the iphone there are no table-adjacent scrollbars for both browsers. But they are not necessary. The individual tables can be dragged left and right to see the whole table. I added the flexbox sandbox link to the above table.

Flexbox is definitely the winner. It needs the option for narrower spacing between items. As narrow as with the divs. --Timeshifter (talk) 01:15, 9 November 2026 (UTC)

He's pretty quick to respond and accommodating. Glad we agree. Thanks for the tests. This confirms that Apple hides the scrollbars purposely: "scroll indicators aren’t always visible". Jroberson108 (talk) 01:22, 9 November 2026 (UTC)

See: mw:Help:Tables#Note about large tables (noresize class).

<div class=noresize>

All below have div class=noresize

User:Timeshifter/Sandbox344. Divs with display:inline-grid User:Timeshifter/Sandbox345. Divs with display:inline-block User:Timeshifter/Sandbox346. Divs with display:inline-table

Inline-table was not helped. Grid and block looked great in PC and iphone. Grid and block tables had adjacent scrollbars on Win 11 Pro PC. With grid and block in the iphone all tables could be dragged individually left and right.

Do you have any ideas how to unbunch the captions? --Timeshifter (talk) 03:38, 9 November 2026 (UTC)

I see the weird caption in Android too. I would avoid trying to add that inside something that has its display changed. Jroberson108 (talk) 06:08, 9 November 2026 (UTC)

I am going to try a few things. nowrap stuff, etc.. Do you have any ideas? What specifically do you have against grid and block? They work great, and I have used CSS with display to make many changes. And it can be done without having to deal with inadequate or nonexistent template parameters.

How does flexwrap work? Does it use display? --Timeshifter (talk) 15:23, 9 November 2026 (UTC)

We just tested and went over the accessibility and responsive issues with those displays? Let the discussion at the template cook a little. As a developer, I can understand the need to have to think about potential issues. Jroberson108 (talk) 16:19, 9 November 2026 (UTC)