Help talk:Table/Archive 8

This is an archive of past discussions about Help:Table. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

{{COVID-19 pandemic death rates by country}}

Is there a simple way to convert this below to a partially collapsed table with vertical scrolling? Along with show/hide links?

{| class="wikitable mw-collapsible mw-collapsed"
![[COVID-19 pandemic death rates by country]]. 
|-
|{{Template:COVID-19 pandemic death rates by country}}
|}

The table reference will show up in the references section of the article it is in. I used {{talk refs}} here to place the references in this talk section.

There is discussion here:

• Template talk:COVID-19 pandemic death rates by country

--Timeshifter (talk) 19:41, 27 August 2020 (UTC)

@Timeshifter: This will do it

{| class="wikitable mw-collapsible"
![[COVID-19 pandemic death rates by country]]. 
|-
|{{scrolling window|link=Template:COVID-19 pandemic death rates by country|height=150px|title=New articles}}
|}

Unfortunately I may not have time to read through the discussion at present, gotta finish checking my watch list here and on meta, also multitasking with real world stuff. However, I'm fairly certain that the manual of style discourages this usage in articlespace. (please ping on reply)

𝒬𝔔 16:58, 28 August 2020 (UTC)

Thanks Quantocius_Quantotius. I added a link to Template:Scrolling window to Help:Table#Scrolling. I also added a link to Template:COVID-19 pandemic data which is one of the few scrolling tables I have seen in article space.

Is it possible with Template:Scrolling window to set it up with a link to fully expand a table? As with Template:COVID-19 pandemic data? And is it possible with Template:Scrolling window to fix the header row such that it stays visible while scrolling? As at Template:COVID-19 pandemic data.

I wish to know the minimal wikitext involved with Template:COVID-19 pandemic data to do those 2 things: Full expansion and fixed header. Template:COVID-19 pandemic data has so much wikitext. Can you pull out the basics and use it here with Template:COVID-19 pandemic death rates by country?

--Timeshifter (talk) 23:52, 28 August 2020 (UTC)

 Done, however review by a second set of eyes wouldn't hurt; I haven't really done serious css stuff for a few years now and I've managed to make a few (thankfully minor) errors in template coding in recent weeks. I took it a bit more slowly here to double check and I had a bit more time today but it's still possible I missed something.

Other than that let me know if there's any other features you want and I'll try to get to them before the end of the month. Courtesy ping to Dudley Miles since you're working on this as well.

I'm going to try to be around Sunday at least for 30 minutes if you have any immediate questions, if not you may need to wait until around the 21st to catch me again as the next two weeks should be bit busy for me, thanks. (please ping on reply)

𝒬𝔔 22:43, 4 September 2020 (UTC)

Thanks Quantocius Quantotius, but it is no longer necessary. See: User:Timeshifter/Sandbox119. --Timeshifter (talk) 01:18, 5 September 2020 (UTC)

An improved version is at Template:COVID-19 pandemic death rates. Does this look OK? Dudley Miles (talk) 08:36, 30 August 2020 (UTC)

It needs a collapse button that brings it back to the scrollable box. I asked for help here:

Template talk:COVID-19 pandemic data#Need a link to collapse it back to its original scroll box size.

Template talk:COVID-19 pandemic data/styles.css#Collapse link needed to collapse back to the original scroll box.

--Timeshifter (talk) 10:34, 30 August 2020 (UTC)

Comment. Dudley Miles and Quantocius Quantotius. Please see User:Timeshifter/Sandbox119. The scrollable table now has a sticky header row that stays visible while scrolling. --Timeshifter (talk) 01:26, 5 September 2020 (UTC)

Sticky header row problem has been solved. See:

Template:COVID-19 pandemic death rates

--Timeshifter (talk) 06:56, 6 September 2020 (UTC)

"Show all" and "Collapse" buttons are all working correctly on all of the partially-collapsed scrolling tables here:

COVID-19 pandemic by country and territory.

--Timeshifter (talk) 04:23, 29 October 2020 (UTC)

Hi, could a wiki table expert help us improve the Timeline of first images of Earth from space, please? There are more details in its Talk page. Thanks! fgnievinski (talk) 05:05, 30 November 2020 (UTC)

Is there a way to make the first row of a table (the header) sticky? So that it stays on screen no matter which part of the table is on screen? Otherwise reading long (and wide) tables is really hard.

--Xerces8 (talk) 14:57, 11 April 2020 (UTC)

Google pulls up some Mediawiki info on it:

https://www.google.com/search?q=mediawiki+Sticky+table+headers

--Timeshifter (talk) 17:22, 11 April 2020 (UTC)

@Xerces8: See also: Phabricator request for floating table headers. --Timeshifter (talk) 08:51, 14 April 2020 (UTC)

@Xerces8 and Timeshifter: I just came here to request the same thing, following my post at Wikipedia talk:Reliable sources/Perennial sources/Archive 3#Technical idea: make the header row of the table sticky. This would be hugely useful for pages like that one. Someone seems to have figured out how to do it at Template:2019–20 coronavirus pandemic data, but that may have involved Herculean amounts of coding (I see they've defined their own custom CSS class, I think). Does anyone have the technical expertise to solve this and add some instructions to this help page, or should we go to WP:VPT? {{u|Sdkb}} ^talk 00:28, 22 April 2020 (UTC)

• RS talk item was archived to Wikipedia_talk:Reliable_sources/Perennial_sources/Archive_3#Technical_idea:_make_the_header_row_of_the_table_sticky — GhostInTheMachine ^{talk to me} 10:45, 6 September 2020 (UTC)

Maybe ask at Template talk:2019–20 coronavirus pandemic data. --Timeshifter (talk) 00:37, 22 April 2020 (UTC)

Take a look in Template:2019–20 coronavirus pandemic data/styles.css at .covid-sticky bits. Graeme Bartlett (talk) 12:17, 22 April 2020 (UTC)

Maybe Bawolff can help. --MarioGom (talk) 12:54, 22 April 2020 (UTC)

Generally this stuff isn't mediawiki specific, but works the same as on other websites. See https://developer.mozilla.org/en-US/docs/Web/CSS/position#Sticky_positioning for details on how position:sticky. That said, I'm not sure how to do sticky headers in a table that's not scrollable (using only css and no js). The Covid template works since the entire thing is in a scrollbox. I'm not fully up to date on recent CSS stuff, so maybe there's a method I am unaware of. Bawolff (talk) 01:11, 3 May 2020 (UTC)

• User preferences includes a test gadget created by TheDJ Make sure that headers of tables remain in view as long as the table is in view (requires Firefox v59 or Safari). See MediaWiki:Gadget-StickyTableHeaders.js and MediaWiki:Gadget-StickyTableHeaders.css.
• Wikipedia:Village_pump_(technical)/Archive_154#Table_header_view from February 2018
• Wikipedia:Village_pump_(technical)/Archive_170#Sticky_table_headers from November 2018.
• See {{COVID-19 pandemic data}} and the CSS in {{COVID-19 pandemic data/styles.css}} for the current "best" version.

GhostInTheMachine ^{talk to me} 10:45, 6 September 2020 (UTC)

This code will make the column headers and the row headers sticky. If there are no row headers, then omit the "left:-1px;" and "z-index:1;" styles from the first column header. It works in Chrome and Firefox browsers for Windows desktop and Android mobile devices.

{| class="wikitable" style="max-height:100vh; overflow:auto;"
|-
! scope="col" style="position:-webkit-sticky; position:sticky; top:-1px; left:-1px; z-index:1;" | StickyRowCol
! scope="col" style="position:-webkit-sticky; position:sticky; top:-1px;" | StickyCol
|-
! scope="row" style="position:-webkit-sticky; position:sticky; left:-1px;" | StickyRow
| data
|}

Jroberson108 (talk) 22:05, 4 December 2020 (UTC)

Jroberson108. Thanks! I linked to this talk page section from here:

meta:Community Wishlist Survey 2021/Reading/Enable sticky table headers

Feel free to add this collapsed example table to Help:Table.

--Timeshifter (talk) 21:15, 7 December 2020 (UTC)

Also linked from: meta:Community Wishlist Survey 2021/Mobile and apps/Improve horizontal scroll of tables. --Timeshifter (talk) 21:26, 7 December 2020 (UTC)

Timeshifter. I am currently looking into moving the styles to a CSS file to simplify it for users. I have to do more research on the right way to add the CSS file and see if it should have it's own help page. I have the CSS file on my local and it seems to be working well. I am planning on setting class="sticky-headers" on the table with an optional class="sticky-headers-colrow" on a column header that also needs to be row sticky. Jroberson108 (talk) 22:12, 7 December 2020 (UTC)

(unindent). Jroberson108. Does this work with sortable tables too?

Also, I found this sticky table linked from the Phabricator T42763 thread:

• de:Red Hot Chili Peppers/Diskografie#Singles

And this one with sortable columns:

• de:Red Hot Chili Peppers/Diskografie#Auszeichnungen für Musikverkäufe

And class="wikitable floatable-header" here :

• Historic Forbidden/Limited Chart - Yugipedia - Yu-Gi-Oh! wiki.

--Timeshifter (talk) 03:47, 8 December 2020 (UTC)

Timeshifter. 1) Yes, it works with "sortable"; although, "sortable" doesn't work for mobile, at least on my phone. 2) The RHCP pages aren't using a table, but a chart table (de:Vorlage:Charttabelle), which looks like a table in a desktop browser, but changes in a mobile browser so that row data is displayed vertically as opposed to horizontally with the column headers listed at the top of the entire chart. In certain curcumstances, this might be a better responsive approach compared to a table; although, their header labels aren't sticky at the top and scroll out of view causing a potential disconnect with the data. 3) It looks like "floatable-header" takes a similar approach to what I did in making column headers sticky, but they didn't do anything with the row headers which scroll out of view causing a potential disconnect with the data. Also, their column headers aren't sticky on mobile, just desktop. Jroberson108 (talk) 04:37, 8 December 2020 (UTC)

Here's the code. Does anybody know how to set the width of column 3 to 150px? "width: 150px" for column 3 is in the code at the moment, but the browser ignores "width" and "max-width" in any column. The browser only obeys "min-width". I tried "table-layout: fixed", "word-wrap: break-word", and some other things, not having luck so far. Thanks. –Novem Linguae (talk) 16:43, 6 January 2021 (UTC)

Novem Linguae, if you look at the thread just above ("Use of em and % values in preference to px values"), you'll see Warning: Setting specific pixel sizes is deprecated, as it interferes with the ability of the browser to adjust content to suit the browser window, device size, user-end font size limits, and other constraints. It is strongly preferred to use relative sizes, in percentage or em values... Schazjmd (talk) 17:45, 6 January 2021 (UTC)

@Novem Linguae: The cells in column 3 use {{nowrap}}. This forces the column to be at least as wide as "People's Front for Democracy and Justice", so setting a smaller width has no effect. Browsers (at least my Firefox) will not respect a large width if it forces the table to be wider than the window, so setting a very large width in column 3 may have no affect unless the window is really wide or you zoom out a lot. On my screen at standard zoom this all means that width is effectively ignored in that particular column of that particular table. PrimeHunter (talk) 22:48, 6 January 2021 (UTC)

PrimeHunter, deleting {{nowrap}} worked perfectly. Thank you. –Novem Linguae (talk) 03:55, 9 January 2021 (UTC)

Is it possible to show more information when clicking a cell in the table? Barecode (talk) 20:27, 5 January 2021 (UTC)

It is Bad Form to have hidden content without a clear indication, but the cell could have extra, hidden content and a [show] button:

{| class="wikitable"
|+ Caption text
|-
| Example || Example || Example
|-
| Example
| Example
{{collapse top|bg="silver"|title=More ...}}
Lots more information
{{collapse bottom}}
| Example
|-
| Example || Example || Example
|}

See {{Collapse top}} for more details — GhostInTheMachine ^{talk to me} 18:53, 11 January 2021 (UTC)

Hello people,

Under #HTML attributes in this article there is this advice:

Instead of using absolute px pixel sizing, prefer relative values with % and em units. Content can automatically shrink to fit.

Instead of specifying a fixed width, consider using min-width or max-width instead. It usually does not make sense on mobile to have a table occupy only 50% of the width.

Doesn't this mean the various examples in this article should comply with that advice?

I can go through and amend if there is no objection and someone can check what I do. But if someone else prefers to do it I won't object.  ;-)

Cheers, Simon – SCHolar44 🇦🇺 💬 at 11:57, 18 December 2020 (UTC)

SCHolar44, the column width section states Warning: Setting specific pixel sizes is deprecated, as it interferes with the ability of the browser to adjust content to suit the browser window, device size, user-end font size limits, and other constraints. It is strongly preferred to use relative sizes, in percentage or em values.. I came here to see if there was a recent discussion that mentioned it, because the page gives examples using pixel sizes. There's a post from several years ago asking about the same thing, so it's been since at least 2016, but I can't find a discussion that led to the decision. Anyway, I agree that the page should be cleaned up to only use examples that comply with the recommended/strongly preferred guidance. Schazjmd (talk) 14:56, 20 December 2020 (UTC)

Note: I posted about this conversation on Wikipedia_talk:Manual_of_Style/Tables to encourage more editors to weigh in. Schazjmd (talk) 15:21, 20 December 2020 (UTC)

In Firefox browser I frequently click the zoom buttons in one of the top toolbars to increase or decrease the text size. But I also have "Zoom text only" checked in View menu > Zoom.

So I would not want em values used for images, or border width, or border spacing, or margins, padding, etc.. In other words anything non-text related.

But em is fine by me for widths of columns and tables. Since that is related to text sizing. --Timeshifter (talk) 05:02, 3 January 2021 (UTC)

Many thanks, Schazjmd and Timeshifter. I've taken your comments on board. Cheers, Simon – SCHolar44 🇦🇺 💬 at 05:50, 6 January 2021 (UTC)

Dear colleagues,

I have gone through the article, as promised, with the following actions:

• changed px values to em values (multiplication factor used: x0.077) wherever px values had been applied to content that was not text-related, i.e. images, border width, border spacing, margins, padding etc
• changed em values to px where they had been applied to images, border width, border spacing, margins, padding etc
• drafted a notice for the introduction to the article and updated the existing (upper) one in the section headed "HTML attributes".

I have pasted the amended article into one of my User pages. To see the changes, just copy the amended article, go into Edit mode in the Help:Table article, Select All and delete, paste in the amended article, click Show preview then Show changes. When you're finished, click on Cancel.

Two questions:

• You'll see that in the first place where I have changed the specification to em values, in the code under the heading "Multiplication table", I have only changed to ems for the width value, not the height. However, I see the example under the heading "Width, height" specifies style="width: 60%; height: 14em;". Is there a reason to use em or % for the height?
• Should we word the advice to indicate that % or em specifications are only needed for width values?

Please examine/critique carefully, and of course change at your will!

I look forward to seeing your comments. Cheers, Simon – SCHolar44 🇦🇺 💬 at 03:21, 18 January 2021 (UTC)

undent: Here is a diff.

changed em values to px where they had been applied to images, border width, border spacing, margins, padding etc This is the wrong direction. It's bad web design and Timeshifter's opinion on the particular matter is strictly his personal preference. The only thing that is reasonable is that images must be specified in pixel values (this is a web requirement, essentially). (I would also say it's generally not idiomatic to specify border widths in anything but pixels, but that's a question of idiom and not requirement or suggestion.)

Generally, what should be suggested is that inline styling in general should be avoided. class="wikitable" is usually sufficient. Where desired, inline styling should be kept to a minimum. This allows the particular skin in which the table is displayed, and the browser, and lastly the user with his own stylesheets whether onwiki or in his browser agent, maximum flexibility to do what it will to fit the content to the screen. --Izno (talk) 05:44, 18 January 2021 (UTC)

Hmm, I hear what you're saying, Izno. Your knowledge is obviously far in advance of mine; I don't have the background to implement explicitly what you have opined as over-arching principles. I have therefore decided not to carry this further and to delete my draft, knowing that your comparison is still available should anyone (or you) be interested to give clearer guidance on the px/em/% question. SCHolar44 🇦🇺 💬 at 11:22, 18 January 2021 (UTC)

there would be appreciated some additional guidelines on table usage, for mobile editors..have posted a comment indicating some recent difficulties here Wikipedia:Village_pump_(technical)/Archive_187#wikitable_width..many thanks Gfigs (talk) 09:50, 29 January 2021 (UTC)

Is there a way to make a table in which one row is collapsible and can be made visible by clicking [show] while other rows are always visible? Krisgabwoosh (talk) 20:33, 8 February 2021 (UTC)

What do the 'create', 'order', 'numeric', and 'ascending'/'descending' parameters and more mean, how do they function, and how do I use 'colspan' and 'rowspan', and use multiple headers or place headers in different locations on Module:AutosortTable, and how do I auto-sort tables and use the 'create', 'order', 'numeric', and 'ascending'/'descending' and the other parameters on tables? -- PK2 (talk) 10:35, 19 August 2020 (UTC)

@PK2: Strictly speaking none of those are parameters. Modules follow the format of

{{#invoke: Module_name | function_name | arg1 | arg2 | arg3 ...}}

see mw:Extension:Scribunto for more details.

Hence, create is the name of the function being called; order, numeric, and descending (there is no ascending) are arguments.

Order is for the sorting preference it takes a coma separated list of column numbers; if two values are the same the next lower preference is used.

Numeric also accepts a coma separated list of column numbers; it designates which use numeric sorting.

Descending is likewise a coma separated list of column numbers it inverts the normal sort order which is ascending by default.

I'm not clear why you would want to use rowspan. Recalling that, post-sorting, any rowspanning cells are cut into individual rows with repeated content and remain that way even if the original sort order is restored.

You autosort tables by converting them into the format used by this module (see Module:AutosortTable/testcases for examples) although in most cases I suspect you're better off using a standard sortable wikitable.

I apologize if I haven't answered your question in full as I'm not sure I fully understood it; if you are looking for someone to write up the documentation for this module I can potentially do that but my time for this is quite limited at the moment (and I have quite a few things on my plate already) so it may be some time before I can get around to it.(please ping on reply)

𝒬𝔔 16:58, 28 August 2020 (UTC)

P.S. Please allow a few days for replies, I can usually respond within the week.

Hello @PK2: I don't know if you (or possibly others) still care, but I have (somewhat) updated the in-code documentation of the parameters you mentioned (while adding a couple of new items). I have an urge to create proper documentation, that's on an actual /doc page and isn't so terse, but I haven't done that yet (and it may be a while before I do).

In case you haven't already figured out what you were wondering about, take a look at what I've done and see if it helps. I'd welcome any feedback. Regards, — JohnFromPinckney (talk) 23:51, 21 February 2021 (UTC)

I have a few questions for everyone:

1. Can you please make it possible for me to use parameters like 'colspan', 'rowspan', 'nosort' and 'data-sort-type', use multiple headers or place headers in different locations, style all or individual cells, rows, columns or headers, and replace the module equivalent of ! scope="row" with | scope="row" on Module:AutosortTable?
2. How do I auto-sort tables and use the 'create', 'order', 'numeric' 'ascending'/'descending', 'hidden' and the other parameters, and style all headers or individual columns on standard tables?
3. Why would someone use the 'hidden' parameter on tables?

Here is an example of a table:

Rank	Wikipedia project		Language	Script	WP code	Active users (log)	Launch date	Logo
	English name	Native name
1	English Wikipedia		English	Latn	en	5
2	French Wikipedia	Wikipédia en français	French	Latn	fr	4
3	German Wikipedia	Deutschsprachige Wikipedia	German	Latn	de	4
4	Spanish Wikipedia	Wikipedia en español	Spanish	Latn	es	4
5	Japanese Wikipedia	ウィキペディア日本語版 (Wikipedia nihongo-ban)	Japanese	Jpan	ja	4
Rank	English name	Native name	Language	Script	WP code	Active users (log)	Launch date	Logo
	Wikipedia project

-- PK2 (talk) 08:36, 28 February 2021 (UTC)

Hi, PK2. Let me address your questions in order:

1. I'm not personally inclined to add support for rowspan/colspan, as I'm not completely clear on what all their effects on accessibility are. More relevantly, how is a table supposed to be sorted when cells are joined using such span attributes? I don't think you need nosort for AutosortTable; just don't specify sorting on that column. The styling of rows and columns can be done now, if you only knew how (see my #2). And something (else) I don't know: why would you want to have | scope="row" in an accessible table?
2. I guess your repeated question here is the answer I was waiting for from you: the documention I added is not sufficient to explain these parameters' use. Okay, I'll try to get up some time/energy and create a dedicated documentation page, with better examples.
3. This one, I can help you on. Consider a table with different data columns (duh), one or more of which you do not (at the moment) want displayed on a given page (like maybe a list of all the Wikipedia versions, but without the magnitude of the user base displayed). However, you do want the table sorted by one of those hidden columns (for example, with EN-WP at the top, 'cause it's the biggest/has the most users).

That certainly is an example of a table. Um, what should we do with it? — JohnFromPinckney (talk) 15:36, 28 February 2021 (UTC)

I see that you can center a normal table with align="center" in the heading, but this doesn't seem to affect wikitables. Are wikitables always left-justified? --DawnDusk (talk) 17:20, 4 March 2021 (UTC)

I found it. One must use style="1em auto 1em auto" to center it. I found this on the Simple Wikipedia's help page, actually - perhaps it's worth porting here? --DawnDusk (talk) 17:28, 4 March 2021 (UTC)

(unindent). This page is fairly up to date (November 10, 2020):

• How to Center a Table with CSS (Quick Guide).

It says align="center" has been deprecated in HTML5.

It says to use CSS, and to set margin-left and margin-right values to "auto". Top and bottom margins can be set to whatever you want. Using your values, here is the short version:

style="margin:1em auto;"

1em is for top and bottom margins. Auto is for left and right margins.

Here it is added to the table from the insert table button on the editing toolbar:

{| class="wikitable" style="margin:1em auto;"
|+ Caption text
|-
! Header text !! Header text !! Header text
|-
| Example || Example || Example
|-
| Example || Example || Example
|-
| Example || Example || Example
|}

See also: Help:Table#Centering tables. It uses more specific CSS. Left and right margins only:

style="margin-left:auto; margin-right:auto;"

--Timeshifter (talk) 01:12, 5 March 2021 (UTC)

Is there some way I can get the table here to look better, thanks.--Prisencolin (talk) 06:17, 30 March 2021 (UTC)

Probably several. First (the question to always ask at the beginning): of what information is this a table? What "stuff" are you trying to show? For example, what does the "1.1" under the first "%" heading indicate? What are the percentages precentages of? (This question leads both to ideas about how to present the data and to formulating a caption, which this table lacks.)

Second: what is the connection between "Wan Chai", "Kwun Tong", and "Sha Tin"? They are all in the same table row, but why? If there is no connection, then I suspect you really need four separate tables, one each for HK Island, Kowloon, NT and "Islands" (although it seems that Hong Kong Island must be an island, no?). And what is the cell with the lonely little hyphen under "Islands"? — JohnFromPinckney (talk) 11:26, 30 March 2021 (UTC)

1. The percentages next to each cell are indicating the percentage of the population which was recorded in the census to be able to speak Shanghainese.
2. "Wan Chai", "Kwun Tong", and "Sha Tin" have no relation, hence why there isn't a header on the left side; they are just coincidentally next to each other. The chart is meant to be read top-down but I can see how it isn't obvious to some. Is there some easy way of making the divider between rows thicker?
3. I believe "Islands" supposed to be Islands District, which is officially part of the New Territories region today, I'm not sure why my source has it as a separate region from the three other main regions, the other two being the main Hong Kong Island and Kowloon (which is physically connected to mainland China). The dash just shows that there are not subdivisions to be listed under "Islands".--Prisencolin (talk) 07:09, 31 March 2021 (UTC)

   First of all, I have to apologize for not knowing the proper divisions of Hong Kong; I am bewildered by what my quick web browsing has turned up regarding geopolitical divisions. Even Wikipedia does not make clear for me (skimming hurriedly) what the three "things" (Hong Kong Island, Kowloon, New Territories) are: regions, districts, areas, ...? There appears to be an island and a peninsula, but I'm not clear what's what, so you will have to check for correctness. The "Sheung Wan", "Wan Chai", "Kwun Tong" items seem to be districts or parts of districts, so I've just sort of half-guessed and leave the details to you.

   So, then: I have taken the liberty of making a "live demonstration" of a starting proposal on the page itself (Permalink).

   – I split the data into three tables, per your point 2 above, one for each, um, region. The "Islands" column you had seemed so minimal, that I relegated the 0.5% to a note at the bottom, as there's not much to tabularize.

   – I added the wikicode appropriate for WP:ACCESS, with captions and scope attributes, and right-alignment for the percentages. The caption for the first table has <br /> tags as a small hack to nudge all three tables to have equally high (in line numbers) captions, for the appearance of tidiness. The three tables I have placed in columns (assuming a wide enough display) using {{Columns-start}}, which should responsively collapse for narrower displays (like phones).

   – The tables remain (now independently) sortable.

   – I also smushed the statistical stuff a little closer together, although I'm not sure how much it means to our readers there. You can, of, course revert all or some of my changes; I hope they constitute an improvement (or at least a learning/discussion opportunity), but do not have to be permanent. — JohnFromPinckney (talk) 16:54, 31 March 2021 (UTC)

See the example below. Hoover (left column) and Nixon (right column) should overlap.

Jpers36 (talk) 18:56, 1 April 2021 (UTC)

Hoover can't get to Nixon because Ruckelshaus is in the way. Haldeman and Ehrlichman are being kind of obstructive, too. Heh, heh.

Seriously, how can Hoover span four rows, as you've specified, when you've said Ruckelshaus needs to be in there, too. Something has to give, and the compromise is that all cells remain inside the table. It's actually a reasonable fallback solution, considering how easy it is for humans to miscount rows. — JohnFromPinckney (talk) 20:45, 1 April 2021 (UTC)

Nixon has a rowspan of 2, providing space for both Hoover and Ruckelshaus. Jpers36 (talk) 20:55, 1 April 2021 (UTC)

Ah, sorry, I hadn't noticed that. And now I'm flummoxed, too. — JohnFromPinckney (talk) 21:03, 1 April 2021 (UTC)

Maybe this:

Or this:

Is this what you wanted at first?:

Need some kind of invisibility powder to sprinkle on the border between the 2 Hoover cells. And need to sprinkle some on the second Hoover. --Timeshifter (talk) 06:30, 2 April 2021 (UTC)

Invisible borders would be bad here, e.g. giving wrong results for screen readers. rowspan is not broken but a row will usually render with height 0 if there is nothing to display in the row. You can force a minimum height on a cell with style="height: ...em;" Don't use px which varies too much between users. Below I used 3em on Nixon. It works for me but it may fail to overlap with Hoover if the Ruckelshaus row gets two lines. I don't know a general method which will always work. PrimeHunter (talk) 11:17, 2 April 2021 (UTC)

I would still qualify that behavior as broken -- there is a use case where it's valuable to display such overlaps even if technically "there is nothing to display in the row". Additionally, in other cases which are equivalent to my eye the overlap does render. But your workaround does do the job. Thanks! Jpers36 (talk) 11:46, 2 April 2021 (UTC)

If it's "broken" then it's broken by html and not by MediaWiki. rowspan is html. Browsers only display table cells large enough to fit the content and specifications. It's the same outside wikis. PrimeHunter (talk) 15:03, 2 April 2021 (UTC)

Such a converter, or regular expression, would make editing some state list tables much easier. Here is an example:

I fully replaced the data for all years for the state overdose death rates and counts here:

• United States drug overdose death rates and totals over time.

Pivot table function (from LibreOffice Calc) made this full update of all years possible. See the rates sandbox for how-to info. See also:

• https://elearn.ellak.gr/mod/page/view.php?id=3015

State rates:

• User:Timeshifter/Sandbox141

State death counts:

• User:Timeshifter/Sandbox142

The most time-consuming problem was dealing with the 2-letter state abbreviations in the source csv file. See:

• List of U.S. state and territory abbreviations.

LibreOffice Calc put the pivot table in alphabetical order of those 2-letter abbreviations. But that is not the same order as the full state names.

So I had to manually move the rows around in the Visual Editor. Then I could paste just the data next to the column of full state names.

I need a converter for the csv text file or the mediawiki table. Maybe a regular expression I could use in the wikitext editing window source editor. --Timeshifter (talk) 13:06, 9 April 2021 (UTC)

I've got a table where I want to specify style on the header lines. The table documentation says to use scope=col for headers. If I specify only scope or only style, everything seems to work. However, if I specify both, then it takes my style specification as header text, e.g., I get a column header of style="max-width:14em;" | Announced from

! scope="col" | Style=max-width:14em | Announced

Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:37, 21 May 2021 (UTC)

Omit the piping symbol before "Style". — JohnFromPinckney (talk) 01:40, 21 May 2021 (UTC)

Thanks: that worked. My next problem is how to reduce the font size. I tried

{| class="wikitable collapsible collapsed"
|+ Product timeline by announcement date
|- style=font:size:80%
! scope="col" | Number
! scope="col" Style=max-width:14em | Announced
! scope="col" Style=max-width:9em  | LTR #
! scope="col" Style=max-width:14em | Available
! scope="col" Style=max-width:9em  | LTR #
! scope="col" Style=max-width:14em | Withdrawn
! scope="col" Style=max-width:9em  | LTR #
! scope="col"                      | Name
|-
| 5665-295
| Jun 7, 1983
| [https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/1/897/ENUS283-141/index.html&request_locale=en 283-141]
| Jun  1983
| 283-141
|
|
| MVS/370 Data Facility Product Release 1
|-
| 5664-167
|
|
|
|
| Dec 31, 1993
| [https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/0/897/ENUS292-320/index.html&request_locale=en 292-320]
| VM/SP
|-
|  5664-173
|
|
|
|
| Dec 31, 1993
| [https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/0/897/ENUS292-320/index.html&request_locale=en 292-320]
| VM/SP HPO
|-
| 5664-308
|
|
|
|
|
|
| VM/XA SP
|}

and got

Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:14, 21 May 2021 (UTC)

I cleaned up your headers, and put the styling in the correct location. Also fixed a typo. No need for max-width when the text remains on one line.

{| class="wikitable collapsible collapsed" style=font-size:80%
|+ Product timeline by announcement date
|- 
! scope=col | Number
! scope=col | Announced
! scope=col | LTR #
! scope=col | Available
! scope=col | LTR #
! scope=col | Withdrawn
! scope=col | LTR #
! scope=col | Name
|-

Product timeline by announcement date

Number	Announced	LTR #	Available	LTR #	Withdrawn	LTR #	Name
5665-295	Jun 7, 1983	283-141	Jun 1983	283-141			MVS/370 Data Facility Product Release 1
5664-167					Dec 31, 1993	292-320	VM/SP
5664-173					Dec 31, 1993	292-320	VM/SP HPO
5664-308							VM/XA SP

You might want to increase the text size just for the top header line. And expose the column heads. Here are the changes:

{| class="wikitable sortable mw-datatable mw-collapsible mw-collapsed" style=font-size:80%
|-
! colspan=8 | <big>Product timeline by announcement date</big>

Product timeline by announcement date
Number	Announced	LTR #	Available	LTR #	Withdrawn	LTR #	Name
5665-295	Jun 7, 1983	283-141	Jun 1983	283-141			MVS/370 Data Facility Product Release 1
5664-167					Dec 31, 1993	292-320	VM/SP
5664-173					Dec 31, 1993	292-320	VM/SP HPO
5664-308							VM/XA SP

--Timeshifter (talk) 06:28, 21 May 2021 (UTC)

Thanks: I used maxwidth to leave as much room as possible for the Name column; some of the product names are longer then the ones I posted here. I used "|+" more to keep "Hide" from going in a column header than from any real desire for a caption, especially since wiki formats the caption for a very narrow line width when the table is collapsed: I may see how it looks with a blank caption.

Is the purpose of the mw-foo to make the table sortable?

Does using a second header row instead of a caption change the metadata that wiki extracts from the markup? Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:04, 21 May 2021 (UTC)

Don't know anything about metadata. The mw-foo is just what I have been using for collapsible tables. I think it is the more recent class for collapsible tables. See also: MW:Manual:Collapsible elements.

Your max-width settings were not effecting the columns with dates and numbers, because those dates, numbers, and headers were already short. So screen width will not effect them first. In fact the individual header words can not wordwrap. The wordwrap would occur between the word and the hash tag.

Before that happens the product name column would wrap.

I haven't figured out a way to spread out the caption of a collapsed table.

You could use my previous table that put the caption in a wide header. Then change the column headers to plain table cells. So they wouldn't show in the initial collapsed table:

Product timeline by announcement date.
Number	Announced	LTR #	Available	LTR #	Withdrawn	LTR #	Name
5665-295	Jun 7, 1983	283-141	Jun 1983	283-141			MVS/370 Data Facility Product Release 1
5664-167					Dec 31, 1993	292-320	VM/SP
5664-173					Dec 31, 1993	292-320	VM/SP HPO
5664-308							VM/XA SP

--Timeshifter (talk) 13:39, 21 May 2021 (UTC)

(edit conflict)Firstly, 80% is too small; please don't use that. See MOS:SMALL / MOS:SMALLFONT for more.

Secondly, please don't use collapsed, as it, too, limits accessibility, as explained at MOS:DONTHIDE.

Thirdly, Timeshifter is right about max-width; you don't need it, and it's generally better to not constrain columns, because some user is going to come along with a different user-agent than you have and see things different than you do, anyway. In general, let the data determine the widths. In this case, the long product names will automatically consume as much space as available before breaking into multi-line display; I'd say that's exactly what you want.

And finally, Chatul, you were on a good path by using |+ as you did; tables usually should be captioned, and you've got a good caption to use. Try:

Product timeline by announcement date

Number	Announced	LTR #	Available	LTR #	Withdrawn	LTR #	Name
5665-295	Jun 7, 1983	283-141	Jun 1983	283-141			MVS/370 Data Facility Product Release 1
5664-167					Dec 31, 1993	292-320	VM/SP
5664-173					Dec 31, 1993	292-320	VM/SP HPO
5664-308							VM/XA SP

Try this stuff out and see how it works for you. — JohnFromPinckney (talk) 13:39, 21 May 2021 (UTC)

(Unindent). Another possibility is to go ahead and collapse the table, but link to a page with the expanded table. This is done for some of the partially collapsed tables in this popular article (in the Statistics section):

• COVID-19 pandemic by country and territory#Statistics - For example; from above one of those tables it says:

"See COVID-19 pandemic deaths for expanded tables and more info."

I thought of a way to show just the table caption in spread out form. I had forgotten about class=nowrap for the caption only. You could even add a caption border and padding. The table still wordwraps as the browser window narrows.

--Timeshifter (talk) 14:31, 21 May 2021 (UTC)

For background, User:Chatul/References#Timeline is part of User:Chatul/References, which contains notes to myself that I may want to excerpt from when editing articles relating to, e.g., IBM software. It may be useful to others, but most likely only for copying text and markup. I would expect users of this material to only read enough to identify the material they want to excerpt. I tend to collapse tables there so as to not obscure other content. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:18, 21 May 2021 (UTC)

If you do some of this stuff on other wikis, then you may need to use style=white-space:nowrap to spread out the caption text when the table is initially collapsed. class=nowrap is not on all wikis. --Timeshifter (talk) 15:56, 21 May 2021 (UTC)

Thanks. I'll keep that in mind. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:34, 21 May 2021 (UTC)

You suggest again to go ahead and collapse the table, despite the accessibility problems I mentioned?

If you're going to hide the table anyway and point to another page for all the data, why not just omit the collapsed table completely and point to another page for all the data?

I don't believe partially collapsed tables pose an accessibility problem.

You thought of a way? I already included class=nowrap in my example above yours.

Chatul has since pointed out that their target is a user sub-page, where I think collapsed tables aren't quite so egregious (and I've got some collapsed-by-default content on my user page, so I'm no saint myself). I just wish to avoid recommending or condoning the use of content that some users cannot access. It certanly shouldn't be in mainspace articles. — JohnFromPinckney (talk) 16:30, 21 May 2021 (UTC)

I don't see an accessibilty issue for a user subpage with this use case. Putting the data on another page would make it more awkward to copy from multiple places.

I will be using class=nowrap. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:34, 21 May 2021 (UTC)

(unindent). John. You wrote: "I don't believe partially collapsed tables pose an accessibility problem." Is this official MOS policy? Can you show me where it says that? Do screen readers see the underlying table somehow because it is only partially collapsed instead of fully collapsed? If so, that is great. I will use more partially collapsed tables in articles. I can think of many cases where it would be useful. Actually I would like to see the references for this. I find the MOS to be out of date at times concerning access issues. John, I did not notice your use of nowrap before I thought of it. You need to reread WP:AGF. --Timeshifter (talk) 02:30, 22 May 2021 (UTC)

Hey, can I get a little help with a type of table I want to create? It's the inverse of the example on #Floating table. I've uploaded an example of what I need on imgur: https://i.imgur.com/esAYjjV.png. I'd also suggest someone put the answer in the main help page so other people who might not understand find it. Thank you. --81.196.174.24 (talk) 00:38, 12 June 2021 (UTC)

Nevermind, found the solution after some fiddling. Posting here in case someone needs it.

1	2	3	4	6	7
			5

--81.196.174.24 (talk) 01:21, 12 June 2021 (UTC)

Looks like rowspan=2 is working for you. This below will work too if you don't want 2 separate cells for 4 and 5. It just puts a break between 4 and 5.

1

2

3

4 5

6

7

In rows where you have set the height (see Help:Table#Height) the text is centered vertically by default. You can align the text to the top or bottom via style=vertical-align:VALUE for the whole row, or for individual cells.

1

2

3

4

5

6

7

1

2

3

4

5

6

7

--Timeshifter (talk) 04:38, 12 June 2021 (UTC)

Thanks for the replies. No, I most definitely wanted two separate cells, I wanted 4 and 5 to be able to be sorted as different cells, in case I had several more instances in other rows of 4 and/or 5 and the readers wanted to sort either by 4 or by 5, if that makes sense. There's a reason I put "sortable" in my example.

Looks like rowspan=2 is working for you.

Ah, rowspan was the first thing i tried, I just didn't know how to get the 5 below the 4 without breaking the table. I would just put it next to the 4 in the code and it'd make a new column or something. --2A02:2F07:B10C:E300:7144:16E6:515C:6CA3 (talk) 11:14, 12 June 2021 (UTC)

While I'm here, I don't suppose there's a way to integrate that 4 next to the 5 in the table's code? For example, if I wanted to make this,

1	2	3	4	6	8	9
			5	7

the code would be a mess. Isn't there any way to make a sortable table for what I want where the values are in their proper order in the code as well as on display? --2A02:2F07:B10C:E300:7144:16E6:515C:6CA3 (talk) 11:14, 12 June 2021 (UTC)

If you got it to work, then that must be the correct order in the wikitext. :)

class=sortable doesn't do anything unless there are some headers.

--Timeshifter (talk) 11:47, 12 June 2021 (UTC)

In § Side by side tables, it instructs to add the html tag <ul> (unordered list), and further states that if the user wishes their tables to be fully left-aligned, to substitute <ul style="margin-left:0px;"> in place of the plain tag. Wouldn't the same no-indent result be achieved by omitting the UL tag entirely, or will there be some effect that's displayed when more that two tables are horizontally stacked? — CJDOS, Sheridan, OR (talk) 20:16, 26 May 2021 (UTC)

Can you demonstrate other options? --Timeshifter (talk) 13:38, 27 May 2021 (UTC)

The reason why I said what I did above, is because I was playing around with the idea of horizontally stacking two tables below a third table, and noticed that to my annoyance, the side by side tables were indented off the left margin. I eventually learned what the initialism UL meant in the html tag, and when I removed the Unordered List tag, my side by side tables aligned left without any indentation, exactly as I wanted. I ultimately didn't use side by side tables in what I was working on, but I thought maybe the Help:Table page needed an update. Give me some time to construct example tables here, and I'll have an demonstration for you. — CJDOS, Sheridan, OR (talk) 18:06, 27 May 2021 (UTC)

• I made the bottom-left tables collapsible, because this was the layout is what I was working on, but otherwise is irrelevant to the concern raised.

Example A

Side by side tables, with Unordered List tag:

Notice in the above example, the left table is indented off the margin. The table directly above it which is not horizontally stacked, is not indented (for comparison of how it should look).

Example B

Side by side tables, without Unordered List tag:

In the above example, none of the tables have indentation, because I removed the <ul> tag. Help:Table currently suggests that to achieve this result, I should add <ul style="margin-left:0px;"> rather than removing the Unordered List tag entirely. I'm sure there's a reason why the Help page is written that way, but I wanted to inquire about this. — CJDOS, Sheridan, OR (talk) 18:29, 27 May 2021 (UTC)

I should add that if I copied the relevant section of Help:Table as it is shown currently, the tags have line breaks between them, which I did not include here. If I had, then the side by side tables would have padding between them. The above examples is how I was doing it (without padding), and I didn't want the padding confused for margin indentation. — CJDOS, Sheridan, OR (talk) 18:36, 27 May 2021 (UTC)

Simplifying so I can visualize this better. Cleaned up some formatting too. I added a space after the first instance of </li>

I don't know why <ul> was used in Help:Table.

I did some more tests, and I see no reason to keep <ul> </ul>

So I removed them from the side by side sections of Help:Table.

I also removed <ul style="margin-left:0px;"> since it is now unnecessary. --Timeshifter (talk) 19:19, 27 May 2021 (UTC)

@CJDOS and Timeshifter: The <ul> is there because it is required for valid HTML. List items (<li>) are children of lists (as the name should lead you to expect). Lists are marked up as <ul> (for unordered lists) or <ol> (for ordered lists). If you need links to Internet reference works beyond our own articles just say so and I can plunk 10 or 20 here pretty quickly; otherwise GIYF. Therefore, the ul elements you removed should be readded.

Also, Timeshifter: please revert all of your unexplained removal of the quotation marks enclosing the property lists in the wikicode, like:

• style="display: inline-table;" → style=display:inline-table;
• lang="html" → lang=html
• class="wikitable" → class=wikitable
• style="text-align:left" → style=text-align:left
• scope="col" → scope=col and scope="row" → scope=row

etc. This is all invalid syntax and makes for a poor example when used on a help page. — JohnFromPinckney (talk / edits) 21:47, 27 May 2021 (UTC)

The quotation marks are only necessary if there is a space that needs to be enclosed by the quotation marks.

Wikitext is not HTML. So unless you can point to a problem caused by not having the <ul></ul> tags, then they are not needed.

I looked at the example side by side tables and images in Help:Table. In Firefox, Chrome, and Edge. In both desktop and mobile view. I narrowed the browser windows until the tables and images wrapped to the next line. They are working perfectly. And better than before because there is no indentation. --Timeshifter (talk) 23:36, 27 May 2021 (UTC)

Response to first two lines, originally from 23:22: I realize you don't care about anybody else but yourself and all you want to do is slap some code together that looks to you as though it works in your operating system on your device at your resolution, but as one of the ten most frequented websites in the world we owe it to our readers to provide exemplary code and explanations whenever we can. That means using correct semantics and syntax and trying to provide valid output usable for the greatest number of users. It means producing (or trying to produce) valid HTML, accessible content, responsive displays of information, etc.

The lack of <ul> produces invalid HTML. I suggest you trying running your variant of the page through the validator at https://validator.w3.org/ and comparing the number of errors found with the version which uses elements and syntax correctly. There are errors either way, unfortunately, but a few more with the ul tags missing. I cannot point to a case where some nuclear power plant suffered a meltdown because quotation marks or <ul> were omitted; I do believe, however, that it is thoughtless to omit the usual details with the excuse that there's currently no space in some style attribute, and it's quite ridiculous, IMO, that you went out of your way to remove quotation marks in correctly formed code. We do our readers and other editors a disservice by showing "seems-to-work" code instead of giving them examples they can follow without problems.

It is true that wikicode is not HTML, but by adhering to coding standards—other pages, and even other places on this same page, use scope="col", for example—we enhance readability and increase the chance of working/valid code (for all users), and reduce the amount of time that gets wasted when somebody tries to add a second property-value pair to a style attribute that doesn't work, because there were no quotation marks previously. Let's try to provide good, robust examples instead of (in case this is what you were aiming at) saving the space of a few quotation mark characters.

Response to last line, from 23:36: Congratulations. I don't give a damn. I'm talking about valid code and clear examples, not whether you think it works perfectly on your machine at this time. Try to see past your own display boundaries. — JohnFromPinckney (talk / edits) 23:55, 27 May 2021 (UTC)

Please do not edit other people's comments. It is against WP:TALK. I removed your comment from the middle of my comment. And please stop making personal attacks.

There have been infrequent discussions about this over the years. And you are making the same mistake others have made. I have been editing this help page for years. Others try to insist that Wikipedia editors must use XHTML or HTML or XML. They are all wrong. Wikitext is not HTML, XHTML, nor XML.

A space in a parameter value necessitates the use of quotes around the value. That is true also in HTML. Look it up. --Timeshifter (talk) 00:11, 28 May 2021 (UTC)

And I have now removed your comment from the middle of my comment. In future, please try to leave your comments as they are once you've signed them. It's hard to know when you're "done" so that the rest of us are allowed to converse with you. I have readded your original timestamp to your original comment, to which my first response is aligned. My second response follows your later addendum, which still has the later timestamp.

Please, please stop going on about how you are right because you have edited this page before. It is really off-putting, and proves nothing useful. I do not insist that editors must use XHTML (or HTML or XML); what I do want is (1) consistency and (2) valid HTML as output. Your refusal to recognize the fact that HTML requires <ul> as a parent for <li> is disheartening, especially when you say you have been editing this help page for years. Longevity isn't what's important here, correctness is. — JohnFromPinckney (talk / edits) 00:24, 2 June 2021 (UTC)

I apologize: I did not intend to start a heated debate. I would recommend putting the article back the way it was before my inquiry, until this can be properly confirmed. I only noticed an issue with side by side tables being indented from the margin, and the solution that I came up with appeared to me to fix the problem without complicating it with more code. The crux of my question was if <ul> was there for a reason, despite what results I might have achieved on my own display by removing them. — CJDOS, Sheridan, OR (talk) 00:48, 28 May 2021 (UTC)

No need to apologize. JohnFromPinckney makes comments around various table talk pages, and contributes both good and bad ideas. As we all do. But in this case he is flat wrong. --Timeshifter (talk) 01:00, 28 May 2021 (UTC)

I agree with Timeshifter: you needn't apologize. (I disagree that I am flat [or contoured] wrong, but that's a separate matter.) In fact, there is a reason for <ul>, it's because it's part of valid HTML. I'm sorry I didn't get to answer your question sooner before Timeshifter became so active. I try not to cross paths with them, and was holding back. Not your fault. — JohnFromPinckney (talk / edits) 14:28, 28 May 2021 (UTC)

I think we should make valid html but I suggest to simplify the coding for editors by hiding it away in three new templates {{Wrap tables begin}}, {{Wrap tables mid}}, {{Wrap tables end}}, instead of the complicated:

<div><ul> <!-- The <div><ul><li> code displays tables side by side when window width allows it -->
<li style="display: inline-table;">
...
</li> <li style="display: inline-table;">
...
</li>
</ul></div>

Editors know templates. The html may look scary to many, and it's easily broken by a poor edit. PrimeHunter (talk) 23:22, 15 June 2021 (UTC)

That looks good, PrimeHunter.

isaacl found a 3rd simple solution:

<div style=display:inline-table>

--Timeshifter (talk) 02:35, 16 June 2021 (UTC)

Someone who uses a screen reader (Graham87) said that the div example works fine. See this talk diff.

I updated the Help:Table sections on side by side tables and images.

--Timeshifter (talk) 13:58, 17 June 2021 (UTC)

"plainrowheaders" class which left-aligns the row headers and removes the bolding

That's not happening here. — 𝐆𝐮𝐚𝐫𝐚𝐩𝐢𝐫𝐚𝐧𝐠𝐚 ☎ 06:03, 1 July 2021 (UTC)

It would if you used scope attribute properly. Replace the style=text-align:left with scope="row" on each row header (and while you're at it, add scope="col" to the column headers) and you'll get the results you want. — JohnFromPinckney (talk / edits) 20:09, 1 July 2021 (UTC)

Aha! Right, thanks. — 𝐆𝐮𝐚𝐫𝐚𝐩𝐢𝐫𝐚𝐧𝐠𝐚 ☎ 22:52, 1 July 2021 (UTC)

And now a not-irrelevant question: is the "number" on that table the most important thing about each community area? Or is it the name? It seems that the names are treated as row headings, meaning they're the most important, but the numbers are in the first column, as if they should take precedence. I'm uninformed on the article's topic, but it appears to me that the numbers could (and should) be moved to the second column, with the row headers (<th> generated by ! and scope="row") applied to the first column, as readers (and some editors) expect. — JohnFromPinckney (talk / edits) 20:09, 1 July 2021 (UTC)

I'm uninformed on the article's topic

So am I. I'll leave it as it is then. — 𝐆𝐮𝐚𝐫𝐚𝐩𝐢𝐫𝐚𝐧𝐠𝐚 ☎ 22:52, 1 July 2021 (UTC)

How do we do this? I get a bunch of gibberish in the column header. From class="wikitable sortable", I get horizontal

class = "nowrap" style="line-height:99%;vertical-align:bottom;padding:21px .4em .2em;background-position:50% .4em !important;min-width:0.875em;max-width:0.875em;width:0.875em;overflow:hidden;"

above the vertical text that's supposed to be in the column header.

For example,

— kwami (talk) 12:17, 6 August 2021 (UTC)

@Kwamikagami: Never place a pipe before {{vert header}}. Omit |stp=1 in unsortable columns. Don't add class="unsortable" or any other class when {{vert header}} is used. It adds its own classes, overriding whatever is before it. PrimeHunter (talk) 12:33, 6 August 2021 (UTC)

Thanks! I wasn't familiar with vert headers. — kwami (talk) 20:09, 6 August 2021 (UTC)

Hello, I've notice that the mw-datatables are not working (they might be elsewhere, but just not in this article, I haven't checked yet — but I can't find what is wrong with the table in this article). Can someone else spot what is wrong? I'm using Firefox on Windows with the default legacy skin, by the way. Thanks. — Eric0892 (talk) 04:39, 13 August 2021 (UTC)

I also tried using Chrome, but that also doesn't work. — Eric0892 (talk) 04:40, 13 August 2021 (UTC)

Can you clarify what you mean by "not working" and "this article"? Are you talking about this section of Help:Table? In any case, do the notes about is not working in some skins and the phab tickets listed in that section relate to your "not working"? — JohnFromPinckney (talk / edits) 12:33, 13 August 2021 (UTC)

The samples in that section are not working. As to the skins issue, I was always using the default skin and it did work a few days ago. I'll add that to the Phabricator issue. — Eric0892 (talk) 18:04, 13 August 2021 (UTC)

I've been sorting this table by the last column and there seems to be an issue with the decimal places in negative numbers- The ascending sort actually descends from negative 0.001 to negative 0.012 and then jumps to the positives. It does not seem to be connected to the "increase" and "decrease" macros. -- Theoprakt (talk) 09:20, 23 October 2021 (UTC)

Items in the last column of that table use {{increase}} or {{decrease}} followed by a number. In the HTML source for the article, typical items look like this:

<img alt="Increase" src=...> 0.021
<img alt="Decrease" src=...> 0.004

Sorting puts all the "Decrease" items together (before "Increase") then sorts by numbers. The fix would be very ugly and involve Help:Sorting#Specifying a sort key for a cell. Apart from the wikitext bloat, the really ugly feature is that each number would have to be duplicated which is a maintenance nightmare. Johnuniq (talk) 09:42, 23 October 2021 (UTC)

Thank you. So the macros turn the sort to alphanumerical, which is why even after inserting minus signs the sort order is wrong. -- Theoprakt (talk) 10:38, 23 October 2021 (UTC)

See the below default table:

Why is the border missing from the right side of the header? Rgrds. --Bison X (talk) 21:35, 28 October 2021 (UTC)

I see that it is the default table from the insert table button on the editing toolbar.

It looks fine to me. No missing borders. I am using Firefox on Windows 10 Pro.

Looks fine in Chrome and Edge too.

--Timeshifter (talk) 21:46, 28 October 2021 (UTC)

I'm using Firefox on Windows 10. Do you see a border on the far right of the 3rd "Header text" phrase? Rgrds. --Bison X (talk) 21:55, 28 October 2021 (UTC)

Bison X. I see a border on the far right of the 3rd "header text" cell.

Maybe you have some personal CSS or JS messing things up. See:

User:Timeshifter#JS and CSS_customization.

Also, do you have the same problem in Chrome or Edge?

I am looking at this on a desktop PC.

--Timeshifter (talk) 22:03, 28 October 2021 (UTC)

Ok, I tried Chrome & it looked fine. In firefox, the table is missing right border lines after all 3 of the "Header text" phrases & a border line between the "header text" & the rest of the table. I must need to download some updates unless others have the same problem. Thanks for troubleshooting for me. Rgrds. --Bison X (talk) 22:11, 28 October 2021 (UTC)

Bison X. If that doesn't work, you might want to completely uninstall Firefox and all your addons. Then do a clean install of Firefox without addons. See if that works. Then add one addon at a time, and see if the problem shows up again. --Timeshifter (talk) 22:45, 28 October 2021 (UTC)

@Timeshifter: I'm late to the party but it can happen in Firefox if you enable this at Special:Preferences#mw-prefsection-gadgets: Make headers of tables display as long as the table is in view, i.e. "sticky". MediaWiki talk:Gadget-StickyTableHeaders.css#Borders in sticky headers is possibly about it. The post doesn't clearly say which border problem it discusses so you may have to check with the poster ;-) PrimeHunter (talk) 03:51, 21 December 2021 (UTC)

Bison X. See above PrimeHunter post.

PrimeHunter. I just activated that preference and the internal header borders disappeared in the table in this thread. I am still using Firefox on Windows 10 Pro. See related problem:

• User talk:Tol/Archives/2021/12#Firefox. Scrolling table with sticky header missing header cell borders

--Timeshifter (talk) 09:38, 21 December 2021 (UTC)

I disabled that preference & the boarders appeared. Thank you for the solution. Rgrds. --Bison X (talk) 10:40, 21 December 2021 (UTC)

Is there an external or internal tool that helps you visually create and edit tables (colors, alignment...) without having to be a programmer.

Not just with tables but almost everything. --Omar.idma (talk) 19:08, 1 January 2022 (UTC)

Omar.idma. I love the title of your post. :)

I am in source mode. When I click the table icon (under Advanced) on the editing toolbar this is what shows up:

{| class="wikitable"
|+ Caption text
|-
! Header text !! Header text !! Header text
|-
| Example || Example || Example
|-
| Example || Example || Example
|-
| Example || Example || Example
|}

This is what you get when you save it ("publish" button):

Caption text

Header text	Header text	Header text
Example	Example	Example
Example	Example	Example
Example	Example	Example

You can fill it in while in source mode. Or use the Visual Editor (VE). With VE you directly fill in the cells without having to fool around with wikitext.

The Visual Editor is not available for use on discussion (talk) pages. You can experiment with it on your user page or user sandboxes. See the VE section at the end of Help:Table. VE makes it easy to add or delete rows or columns.

Colors and alignment are more advanced. Let others do that until you get more familiar with the basics. --Timeshifter (talk) 23:15, 1 January 2022 (UTC)

This page says "nested tables should be avoided whenever possible" (Help:Table#Nested_tables), but implements nested tables for all the "Rendered result" parts of the page. This doesn't render nicely on smaller devices and should instead float under its "Wiki source" counterpart on smaller screens. You could instead use markup similar to this which is responsive:

<ul>
  <li style="border: 2px solid rgb(0, 255, 0); display: inline-table; padding: 0.5em;">
    '''Wiki source'''
    {{Pre|<nowiki>...</nowiki>}}
  </li>
  <li style="border: 2px solid rgb(0, 255, 0); display: inline-table; padding: 0.5em;">
    '''Rendered result'''
    {| class="wikitable
    ...
    |}
  </li>
</ul>

Here is one example from the page redone to be responsive.

• Wiki source

  {| class="wikitable"
  |+ The table's caption
  ! Column header 1
  ! Column header 2
  ! Column header 3
  |-
  ! Row header 1
  | Cell 2 || Cell 3
  |-
  ! Row header A
  | Cell B
  | Cell C
  |}

• Rendered result

  The table's caption

  Column header 1	Column header 2	Column header 3
  Row header 1	Cell 2	Cell 3
  Row header A	Cell B	Cell C

Jroberson108 (talk) 16:01, 7 January 2022 (UTC)

Note: No indentation in this reply. To avoid problems.

2 divs would work too. And there is no initial indentation. See:

• Help:Table#Side by side tables

<div style="display:inline-table; border: 2px solid rgb(0, 255, 0); padding: 0.5em;">

{| class="wikitable"
|+ The table's caption
! Column header 1
! Column header 2
! Column header 3
|-
! Row header 1
| Cell 2 || Cell 3
|-
! Row header A
| Cell B
| Cell C
|}

--Timeshifter (talk) 20:41, 7 January 2022 (UTC)

Yeah, that works a little better. Guess I missed that section of the page. Jroberson108 (talk) 23:25, 7 January 2022 (UTC)

There are several wishlist items this year that relate to tables, both for editors and readers. I particularly encourage folks to go support these:

• Formatting columns in table
• Advanced table tools on Visual Editor
• Table sorting on mobile
• Floating table headers

Cheers, {{u|Sdkb}} ^talk 22:58, 29 January 2022 (UTC)

Hey Jroberson108 and Tol. The above may be of interest. --Timeshifter (talk) 08:12, 30 January 2022 (UTC)

@Timeshifter: Yeah, I saw and updated [T42763] for sticky table headers. I may be mistaken, but votes at this point might be meaningless since votes are probably what created the phabricator tickets to begin with; although, it might bring more help for implementation. Jroberson108 (talk) 08:51, 30 January 2022 (UTC)

@Jroberson108: Voting just started. See: meta:Community Wishlist Survey 2022. The team prioritizes what they work on partially by voting results. So it can bring in more people to work on T42763. --Timeshifter (talk) 09:30, 30 January 2022 (UTC)

Is there any information on a possible Wikidata integration that this page is missing? Like, if an editor wants to create a comparison table of items of a same instance on Wikidata comparing certain statements?--Iara Ai (talk) 19:04, 12 January 2022 (UTC)

The page is mostly about how to make tables, not where to get content to put in them. If you want a table dealing with Wikidata items, you will have to find out (for yourself, or with help somewhere else) and then put that info in a table (which this page is intended to help you with). — JohnFromPinckney (talk / edits) 02:19, 13 January 2022 (UTC)

If anybody finds some how-to pages about Wikidata and tables, please share them here, and we can put links to them in Help:Table. --Timeshifter (talk) 02:48, 13 January 2022 (UTC)

The main method I know is to use Module:Wikidata table which I helped to develop — Martin (MSGJ · talk) 11:39, 24 February 2022 (UTC)

How can I get the following table to floatright? 'class="wikitable floatright"' does not perform as I expected from reading this documentation:

{| class="wikitable floatright" |- | || colspan="2" | [[File:Humility and arrogance.png|150px|center]] |- | || colspan="2" | Humility and Arrogance |- | || How do you know that? || I know the truth. |- | In armed conflict || How can we protect ourselves without escalation? | Collateral damage is unfortunate but necessary. |}

	Humility and Arrogance
	How do you know that?	I know the truth.
In armed conflict	How can we protect ourselves without escalation?	Collateral damage is unfortunate but necessary.

ALSO: Is there a way to specify imagesize in "em" units rather than pixels or "thumb"?

The section on "Wikitable as image gallery" begins, "This section is still recommending deprecated fixed-pixel sizes for images, and should be updated with relative sizes in em units." Is there a way to replace, e.g., "150px" with a specification in "em units"?

(And is "thumb" better than, e.g., "150px"?)

Thanks, DavidMCEddy (talk) 05:48, 15 March 2022 (UTC)

Trying to cleanup up this article right now... specifically at Nickelodeon Kids' Choice Awards#Locations and Nickelodeon Kids' Choice Awards#Ceremony hosts.

I don't think we need one long table with 2 columns, creating excessive whitespace. What would be the best/preferred solution to this- splitting the tables in question into two separate tables (for example, two/three 2x17 tables) or keeping it as one table, but changing the amount of columns instead?

In regards to the 'locations' table, I'm talking about something like this:

versus this:

Or is there some other alternate way(s) that might be even better? Thanks in advance. Magitroopa (talk) 22:49, 16 March 2022 (UTC)

Your second set of years will work. From here:

Help:Table#Side by side tables

I don't know what else to do.

--Timeshifter (talk) 23:21, 16 March 2022 (UTC)

@Magitroopa: Per MOS:NO-TABLES, since the "Locations" table doesn't need sortable and the structure and data are simple (i.e. "year" is recognizable without label), you could convert it to a list and use Template:Columns-list to wrap it into columns. Not sure why 1994 has two locations?

Locations:

Alternatively, you could combine the "Locations" and "Ceremony hosts" tables.

Jroberson108 (talk) 01:20, 17 March 2022 (UTC)

@Jroberson108: I think combining the sections/tables might actually be best here, as opposed to the current two long tables. So maybe instead having a 'List of ceremonies' section followed by the table briefly started above, and then subsections within for 'Locations' and 'Host' that would give the prose text currently listed in those sections.

And FYI in regards to two locations for the 1994 show- that's because the main show/ceremony was held at the Pantages Theatre with Lawrence & Cameron hosting, along with an east coast 'portion' from Universal Studios Flordia, which is where Weiner hosted from with an audience + some performances there as well. Magitroopa (talk) 01:30, 17 March 2022 (UTC)

@Magitroopa: Based on the info you provided, I adjusted 1994 in the table above so it is apparent who hosted where. Also, commas now separate hosts since names can wrap in middle on small devices. Jroberson108 (talk) 01:55, 17 March 2022 (UTC)

The Nested Tables section says Why <nowiki>, seemingly out of a clear blue sky, and then doesn't say anything about <nowiki>. That apparently appeared in this June 13, 2020 edit but I'm not sure what it was intended to convey to the reader then or is intended to convey now. I came here to try to get a handle on hidden tables, and I am pretty foggy on the details of that even without wondering what I'm missing because of the Why <nowiki>. I looked at the wikitext around that in the current page version, which says:

* Why <syntaxhighlight lang="moin" inline><nowiki/></syntaxhighlight>. <!-- Removing the <nowiki/> above to see. -->

but that didn't help much. I tried removing the <nowiki> preceding that line and refreshing the page, but that didn't help either. Does this need to this be clarified, or am I just exceptionally dense this morning? Wtmitchell (talk) (earlier Boracay Bill) 10:11, 8 April 2022 (UTC)

You're right, there was no need for it. In fact there was no need for that example at all. Nesting tables is discouraged, and there is a far simpler example beneath it which adequately explains the technique in case it was ever needed. --Jules (Mrjulesd) 15:52, 10 April 2022 (UTC)

Hello!

Can someone help me with this request? :) - Klein Muçi (talk) 15:16, 20 April 2022 (UTC)

Not very easy. The styling for wikitables is:

/**
	 * wikitable class for skinning normal tables
	 * keep in sync with commonPrint.css
	 */
	table.wikitable {
		margin: 1em 1em 1em 0;
		background-color: #f9f9f9;
		border: 1px #aaa solid;
		border-collapse: collapse;
		color: black;
	}
	table.wikitable > tr > th,
	table.wikitable > tr > td,
	table.wikitable > * > tr > th,
	table.wikitable > * > tr > td {
		border: 1px #aaa solid;
		padding: 0.2em;
	}
	table.wikitable > tr > th,
	table.wikitable > * > tr > th {
		background-color: #f2f2f2;
		text-align: center;
	}
	table.wikitable > caption {
		font-weight: bold;
	}

You could use a TemplateStyle to adjust this to how you like, and then apply it to your table.

Otherwise you would have to use inline css for every element; very messy. Jules (Mrjulesd) 05:29, 21 April 2022 (UTC)

@Mrjulesd, the problem is that I'm really bad with CSS editing so I wouldn't know how to do that in practice. :/ Is that an easy/fast thing to do? Maybe you can do it for me and I can save it somewhere? I just wanted to remove the frame (4 lines: top, bottom, left and right) that outlines the table while keeping everything else intact. - Klein Muçi (talk) 09:31, 21 April 2022 (UTC)

What is wrong in the following example?

Before table.

Table 1 cell 1

Table 2 cell 2

After table. Should not be indented, but it is.

How to make it work properly? — Mikhail Ryazanov (talk) 12:51, 2 January 2022 (UTC)

(reply not indented to save confusion)
One quick solution would be to add a third column on the left (with a fixed width) to provide the indent.
Before table.

After table. No longer indented — GhostInTheMachine ^{talk to me} 13:09, 2 January 2022 (UTC)

Another simple fix would be to add <div>...</div> tags around the table.
Before table.

After table. — GhostInTheMachine ^{talk to me} 13:16, 2 January 2022 (UTC)

Thanks! The second approach seems to be more adequate, since it uses "natural" indents instead of a hard-coded number (which might be different in different skins and might change in future).

If this effect (demonstrated in my first example) is indeed a bug in the parser, maybe it should be investigated and repaired? At least, it would be very useful to mention such problems and workarounds in the help.

And by the way, is there any reliable way to include tables in nested lists in general? For example, tables don't work "as is" even in simple bulleted lists:

• Item before.
• {| class="wikitable"

! Header |- | cell |}

• Item after.

I always struggle with this stuff (especially on discussion pages) and couldn't fine any clear solution... — Mikhail Ryazanov (talk) 13:48, 2 January 2022 (UTC)

Thanks from me as well! Do we know exactly what causes the issue (e.g. whether it is the nested table)? If so, we could add this solution to Help:Table#Indenting tables. —AlphaMikeOmega (talk) 16:46, 30 April 2022 (UTC)

(This reply also not indented in attempt to avoid confusion)

It seems that the wikiparser does not close off list items (<li></li> and <dd></dd>) after a table. That's why the After table. Should not be indented, but it is. in the OP's shaded bit is indented; it's (still) part of the <dl><dd> content initiated by the colon just before the table. I did some other tests with an HTML table (<table><caption> etc., not wikimarkup like {| class="wikitable") inside an asterisk-generated bulleted list, and the results were similar; my table appeared nicely, but everything following it (inside or outside my bullet list, including headings) was indented, as part of the identation accompanying the table's list item.

For the basic question asked in the OP, I would consider just adding styling like {| class="wikitable" style="margin-left:4em" Introductory text.

Concluding text. And I realize I'm not using nested tables as mentioned in the original question, as that aspect doesn't really seem germane; it's rather just the problem of a table in a list item.

And as far as the later question goes, about putting a table in an unordered list, I was unable to make it work using asterisk markup, and didn't even try with your {| class="wikitable" coding; I got good results only by forcing the list-item closure by inserting the HTML directly (um, that is, both list markup and table markup, manually; click edit to see my code):

I introduce this list of items, the third of which is a table.

• Item 1
• Item 2

• Caption text 4

  Header text	Header text	Header text
  Example	Example	Example
  Example	Example	Example
  Example	Example	Example

• Item 4

And now some concluding text. Happily, it is NOT indented.

Now, while this allows things to "work" on some discussion page, I can't say it's really practical.

If this is a bug in the parser, I guess it should be reported on phab. Or maybe it's already there; I'll go have a look after this. — JohnFromPinckney (talk / edits) 00:49, 3 January 2022 (UTC)

(This reply also not indented in attempt to avoid confusion)

Mikhail Ryazanov. See: Help:Table#Nested tables. Nested tables are very confusing for screen reader users. A better solution is here:

• Help:Table#Side by side tables

I removed the nesting. And instead of colon indentation I added the left margin to the first div styling:

<div style="display:inline-table; margin-left:4em;">

Before table.

After table.

Before table.

<div style="display:inline-table; margin-left:4em;">
{| class="wikitable"
! Table 1
|-
| cell 1
|}
</div> 
<div style=display:inline-table>
{| class="wikitable"
! Table 2
|-
| cell 2
|}
</div> 

After table.

As for a bulleted list with tables I did a Google search and found this thread:

• https://www.mediawiki.org/wiki/Topic:Q9xbaa4rctdx3vn1

It agrees with JohnFromPinckney. --Timeshifter (talk) 04:10, 3 January 2022 (UTC)

How can you make column 5 appear with the same height as the first 3 columns? I use "rowspan="2" but it would not work. I don't want that blank space on top of it. Thanks!--TerryAlex (talk) 19:47, 16 May 2022 (UTC)

Do you mean like this?

--Jules (Mrjulesd) 20:46, 16 May 2022 (UTC)

Thanks!! :)--TerryAlex (talk) 21:54, 16 May 2022 (UTC)

The advice on indenting tables is bad. A leading colon does not indent; rather, it produces a description list, but without a term, which results in invalid HTML. "The way you'd normally indent anything" is NOT by using a colon, but by using {{block indent}} or CSS. Trying to "indent" something in the middle of a list results in mangled HTML with lists opening and closing repeatedly, which is a disaster for accessibility. Hairy Dude (talk) 18:59, 17 May 2022 (UTC)

Hello, I'd like to create a table that looks like this:

I.e. the title of the last column should extend to the left as much as it needs space even over the otherwise more narrow width of the column. To create the table above I've used the "colspan" attribute, but that means that the column title is no longer associated to the last column which I assume will be bad for screen readers. Do you have an idea how it would be possible to get the visual result without destroying the logical structure for screen readers? Thanks a lot in advance, --Marsupium (talk) 09:19, 7 June 2022 (UTC)

@Marsupium: I don't think there is a proper way to do that. Alternatively you could use {{abbr}} like p. or {{Vertical header}}. You can use {{soft hyphen}} on long words with multiple syllables so a column can be rendered more narrow when needed. PrimeHunter (talk) 10:22, 7 June 2022 (UTC)

Thanks for your answer! Using abbreviations isn't an option cuz the use case is the transcription of a book on Wikisource so should match the original, see here for a scan of the original. I've done some search on using a "scope" attribute and a workaround could be to use it and set the "dir" attribute of the table from right-to-left, but that sounds like a messy solution, so I guess I might simply have to live with the column remaining slightly wider than desired. :-) --Marsupium (talk) 10:44, 7 June 2022 (UTC)

@Marsupium: This is a help page for the English Wikipedia. I meant no proper way here. Maybe Wikisource accepts more manipulation to try to follow source layout. You can try something like <div style="position: relative; right: 2em;">page</div>. The number can be varied. Don't use px, it relies too much on circumstances for the viewer. The suggested code can also depend on circumstances so you may want to test with different browsers, zoom levels and font sizes if you care about the precise result. PrimeHunter (talk) 11:25, 7 June 2022 (UTC)

Sorry, I should've mentioned that the use case isn't here with the question! Thanks for the the position: relative workaround, it could indeed work. But I think now I've even found a clean solution using id and headers attributes as described by MOS:DTT#Complex tables. (Noting it here as reference for the next one running into a similar problem.) Thanks a lot again! --Marsupium (talk) 11:51, 7 June 2022 (UTC)

The following table (with {{football kit box}} templates inside each cell) looks fine on desktop view. However, on mobile view, horizontal scrolling is needed to view all the cells. I've been told that scrolling is discouraged. How can I fix the issue? Nehme₁₄₉₉ 22:23, 14 June 2022 (UTC)

Monza's first kit in 1912 was blue-and-white.

In 1920 the kit changed to blue-and-white halves.

The first red-and-white kit appeared in 1932.

In 1937–38 and 1961–62, Monza wore stripes.

Variations of a full-red shirt were worn between the 1930s and 2010s...

...which alternated with the white-stripe kit, first introduced in 1971.