Help talk:Table/Archive 8

Archive 5

Archive 6

Archive 7

Archive 8

Archive 9

Archive 10

Partially collapsed table with vertical scrolling and show/hide links?

{{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}}
|}

References

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

Wikitext
{| 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}} |}

References

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)

Help needed for a timeline of images

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)

Sticky table headers?

Tracked in Phabricator
Task T42763

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
|}

Example table

StickyRowCol	StickyCol	StickyCol	StickyCol	StickyCol	StickyCol	StickyCol	StickyCol	StickyCol
StickyRow	data	data	data	data	data	data	data	data
StickyRow	data	data	data	data	data	data	data	data
StickyRow	data	data	data	data	data	data	data	data
StickyRow	data	data	data	data	data	data	data	data
StickyRow	data	data	data	data	data	data	data	data
StickyRow	data	data	data	data	data	data	data	data
StickyRow	data	data	data	data	data	data	data	data
StickyRow	data	data	data	data	data	data	data	data
StickyRow	data	data	data	data	data	data	data	data
StickyRow	data	data	data	data	data	data	data	data
StickyRow	data	data	data	data	data	data	data	data
StickyRow	data	data	data	data	data	data	data	data
StickyRow	data	data	data	data	data	data	data	data
StickyRow	data	data	data	data	data	data	data	data
StickyRow	data	data	data	data	data	data	data	data
StickyRow	data	data	data	data	data	data	data	data
StickyRow	data	data	data	data	data	data	data	data
StickyRow	data	data	data	data	data	data	data	data
StickyRow	data	data	data	data	data	data	data	data
StickyRow	data	data	data	data	data	data	data	data
StickyRow	data	data	data	data	data	data	data	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)

Set table column width to 150px

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)

Showing extra info when clicking a cell

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 |}

⇒

Caption text Example Example Example Example Example More ... Lots more information Example Example Example Example

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

Use of em and % values in preference to px values

Hello people,

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

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)

tables for mobile editors

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)

Collapsible Sections

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)

parameters and auto-sorting tables

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)

Can you center a wikitable?

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:

Caption text

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

{| 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)

Help with a table

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)

Is rowspan broken?

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

Name	President
J. Edgar Hoover	Harry S. Truman
	Dwight D. Eisenhower
	John F. Kennedy
	Richard Nixon
William Ruckelshaus

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:

FBI Director	President
J. Edgar Hoover	Harry S. Truman Dwight D. Eisenhower John F. Kennedy Richard Nixon
William Ruckelshaus	Richard Nixon

Or this:

FBI Director	President
J. Edgar Hoover	Harry S. Truman Dwight D. Eisenhower John F. Kennedy
J. Edgar Hoover	Richard Nixon
William Ruckelshaus

Is this what you wanted at first?:

FBI Director	President
J. Edgar Hoover	Harry S. Truman
	Dwight D. Eisenhower
	John F. Kennedy
J. Edgar Hoover	Richard Nixon
William Ruckelshaus

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)

Name	President
J. Edgar Hoover	Harry S. Truman
	Dwight D. Eisenhower
	John F. Kennedy
	Richard Nixon
William Ruckelshaus

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)

Need converter of 2-letter state abbreviations to full names

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)

Syntax for scope and style on same line

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

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

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.

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) 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)

A little help

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)

Side by side tables

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:

Year	Africa	Americas	Asia & Pacific	Europe
2014	2,300	8,950	9,325	4,200
2015	2,725	9,200	8,850	4,775

• Year	Africa	Americas	Asia & Pacific	Europe
  2014	2,300	8,950	9,325	4,200
  2015	2,725	9,200	8,850	4,775

• Year	Africa	Americas	Asia & Pacific	Europe
  2014	2,300	8,950	9,325	4,200
  2015	2,725	9,200	8,850	4,775

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:

Year	Africa	Americas	Asia & Pacific	Europe
2014	2,300	8,950	9,325	4,200
2015	2,725	9,200	8,850	4,775

Year	Africa	Americas	Asia & Pacific	Europe
2014	2,300	8,950	9,325	4,200
2015	2,725	9,200	8,850	4,775

Year	Africa	Americas	Asia & Pacific	Europe
2014	2,300	8,950	9,325	4,200
2015	2,725	9,200	8,850	4,775

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>

Year	Africa	Americas	Asia & Pacific	Europe
2014	2,300	8,950	9,325	4,200
2015	2,725	9,200	8,850	4,775

Year	Africa	Americas	Asia & Pacific	Europe
2014	2,300	8,950	9,325	4,200
2015	2,725	9,200	8,850	4,775

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>

Total number of matches played in official competitions only.

Player	Matches	Goals
Guðmundur Hrafnkelsson	407	0
Guðjón Valur Sigurðsson	364	1,875

Total number of goals scored in official matches only.

Player	Goals	Matches	Average
Guðjón Valur Sigurðsson	1,875	364	5.15
Ólafur Stefánsson	1,570	330	4.76

--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)