Help talk:Table

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)

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)

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)

plainrowheaders apparently not working

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

Non-sortable column with vertical header

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,

Number	ABC	class="nowrap ts-vertical-header " style="" | XYZ
1	2	3
3	2	1

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

Number	ABC	XYZ
1	2	3
3	2	1

References

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

Examples for mw-datatable

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)

wrong sort order between negative numbers differing in decimal places in wikitable sortable

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)