Wikipedia talk:Manual of Style/Tables

Vertical alignment

Regarding vertical alignment in tables, I am wondering if there is any consensus on using them or not. I ask because when it comes to awards tables for films or actors, tables often default to middle alignment. However, I've noticed that this can be a problem in mobile view because a reader can see the award details in the right column before they can see what the film title is. So if there are numerous awards for a given film, a reader would have to scroll to the "center" of the group of rows to identify the film, then scroll back up to start actually understanding the awards. And as we know, mobile views make up the majority of views now, and I suspect it is even more for entertainment and arts-based articles. Does that make sense or not? I would like to encourage more use of vertical alignment but wanted to find out if there has been any kind of discussion like this before. Erik (talk | contrib) ^{(ping me)} 13:34, 5 January 2019 (UTC)

It’s hard (for me at least) to visualize the issue based on a text description. Can you share a link to an article or two (or even better, to a specific section within an article or two) where this issue arises so other editors can better understand the issue? CUA 27 (talk) 23:18, 5 January 2019 (UTC)

CUA 27, To clarify, I should have stated that I think vertical alignment should be "top" and not "middle" (which is the default). I bring this up because at Hong Chau, another editor removed the top alignment from the awards table. So on mobile, it looks like this (same thing would happen if the mobile device was held horizontally). I think middle alignment is less of a big deal on a desktop, and it is probably relatively unconventional to see top alignment used instead, but I don't think that should mean inconveniencing mobile readers. Erik (talk | contrib) ^{(ping me)} 17:37, 6 January 2019 (UTC)

Just to add I'm the one who had been removing the vertical top - My reasoning for doing so was that it's not a common layout on any actor/actress article and I personally felt the layout looked ridiculous,

I've since learned it was done for mobile users however we generally don't accommodate mobile users as such (Article layouts vary from device to device so what may look fine to Eric may look odd to everyone else (case in point being my userpage - looks fine on a 1280x800 device but anything higher or lower and it looks odd)

Thanks, –Davey2010^Talk 20:35, 7 January 2019 (UTC)

Is there an option for us to use stylesheets or some other CSS to make mobile and desktop show this differently like some templates/modules can? --Gonnym (talk) 20:39, 7 January 2019 (UTC)

(edit conflict) We are used to the middle positioning because the table code started out with a desktop bias. The top positioning only looks "ridiculous" to you because you are unused to it. Mobile web browsing has surpassed desktop web browsing, including on Wikipedia. Top positioning does not inconvenience desktop-view readers, and it would convenience mobile-view ones. "It looks weird" isn't a compelling reason. Erik (talk | contrib) ^{(ping me)} 20:47, 7 January 2019 (UTC)

Hi Gonnym, As far as I know no ?, The only best solution or compromise I have is simply to remove the rowspans, Thanks, –Davey2010^Talk 21:07, 7 January 2019 (UTC)

If the use of vertical alignment would help with mobile (and specifically with the wikitable class), then it should probably be submitted to Phabricator instead of piecemeally added. --Izno (talk) 22:23, 7 January 2019 (UTC)

The last two days, I was waiting for user Phabricator to reply... I see now that it is not an editor. :-P I can put in a request, but in the meantime, there is no consensus for anyone to override this particular approach. WP:DTT highlights things not to do, and vertical alignment = top is not among them. And Help:Table outlines how to do this if preferred. No editor should go around stripping down tables (or articles) when it is not necessary. Erik (talk | contrib) ^{(ping me)} 14:38, 9 January 2019 (UTC)

The default with styling (any styling) is that we don't move from the defaults without especial good reason (this is because of how Cascading Style Sheets work). If it's really as good a reason as you think that we should have these, it shouldn't essentially be added everywhere. --Izno (talk) 14:49, 9 January 2019 (UTC)

I'm not sure what you're saying. I would be fine with top becoming the default parameter. Middle has been the default parameter because we're used to desktop views. Change has to happen somehow. If it's not overnight, it is still no reason to ban that approach. There are all kinds of tables across Wikipedia using CSS in different ways. Picking the bottom parameter for vertical alignment would be problematic as far as I can tell (I can't think of any good reasons to do that). But there is a plausible reason (or so I like to think) to use the top parameter, even in an ad-hoc manner, and again, it should not be banned. Erik (talk | contrib) ^{(ping me)} 14:56, 9 January 2019 (UTC)

If it's a website style question, yes, actually, 'banning' or at least strongly discouraging any use of inline styles is the preference. One reason not discussed there is that inline styles take precedence over everything, including the reader's personal CSS file, without exceptional work on the part of the reader. Because we do have multiple form factors (mobile and desktop), changing the inline style ("ad hoc") makes it worse for one form factor at the expense of the other. What you could do if you thought there was actual consensus for your change would be to make a suggestion either at Mediawiki talk:Mobile.css or on Phabricator (your post at the bug reports talk page will not actually raise the suggestion to the level of the technical developers; you need to file the task on Phabricator). But, I don't think you do have consensus that this is unequivocally a good change for all users of the mobile platform. --Izno (talk) 15:23, 9 January 2019 (UTC)

Abstractly: I think I'd support this change. As a comparison, when I'm looking at spreadsheets (e.g. google sheets) I often change the alignment to "top" (and "left" if everything is in LTR languages) for a more logical reading experience. Otherwise our eyes are zig-zagging up and down as they move across a row. This proposed change on-wiki would potentially help a lot of users on both desktop and mobile, if a wide table has been squashed in a narrow view-window causing each column to be overly thin (which happens a lot).

Specifically: It would be helpful to do some wider testing, with dozens-to-hundreds of pages, across many wikis, to determine if there are any immediately obvious negative side-effects. If there are not, it could be proposed (with accompanying screenshots or demo-links) at m:Tech for further sanity-checking, and then filed as a Phabricator task request along with the supporting evidence.

I suspect the easiest way to do this testing would be using a CSS extension such as Stylus - I've whipped up a simple style override here that seems to work (? patches welcome if I missed something!) - and then testing that extensively against pages like those within Wikipedia:Featured lists (and at other wikis), with the un-altered page also open in another window/browser to compare. Hope that helps. Quiddity (talk) 20:29, 9 January 2019 (UTC)

Filmography example

Hi! We're having a discussion on WP:VG regarding for gameography table formatting, in order to comply with the MOS and its design and accessibility rules. Upon showing this example to the group (as it is the closest to what we're after), some editors pointed out that it's non-standard in the way that rows start in the table's second cell (the title) rather than the first (year). What's you're input on this? Is the MOS wrong regarding this example? ~ Arkhandar ^{(message me)} 11:01, 21 January 2019 (UTC)

@Arkhandar: To ping someone properly, you need either to make a new block including your signature, or you need to re-sign the old block. --Izno (talk) 20:41, 21 January 2019 (UTC)

@Arkhandar: You must both add new text pinging someone and re-sign. Not one or the other. --Izno (talk) 00:56, 22 January 2019 (UTC)

@Izno: Done! Wouldn't expect any less strictness from the MOS community :D ~ Arkhandar ^{(message me)} 10:39, 22 January 2019 (UTC)

@Erik, CUA 27, Davey2010, Izno, and Quiddity: ~ Arkhandar ^{(message me)} 10:38, 22 January 2019 (UTC)

I've tried skimming the discussion here but cannot tell what you mean by "the way that rows start in the table's second cell (the title) rather than the first (year)". Can you elaborate with a simple-table example? Erik (talk | contrib) ^{(ping me)} 15:00, 22 January 2019 (UTC)

@Erik: Thanks for taking the time to analyze the issue. Maybe if I give a couple of examples it will be easier to understand. Basically they're saying that the following table (the filmography) example is "wrong" and non-standard because its "scope="row"" is on the second column rather than the first.

Alleged "incorrect" example

Year	Title	Role	Notes
1961	Barabbas	Patrician in Arena	uncredited

While the following is what it should look like according to them. Note the "scope="row"" is now on the first column.

Alleged "correct" example

Year	Title	Role	Notes
1961	Barabbas	Patrician in Arena	uncredited

Now, personally, I think it makes more sense to have it the way it is on the MOS. But since some people are arguing that it's "wrong" I'd like to get you're input. Hope the examples helped. ~ Arkhandar ^{(message me)} 15:56, 22 January 2019 (UTC)

On the surface, they look the same to me, aside from the year values being bolded. I plead ignorance on what using scope="row" in either column is intended to do? Why have it at all? (I'm not an editor deeply vested in MOS:TABLE matters, just to give you a heads-up. Was only here to post the above thread.) Erik (talk | contrib) ^{(ping me)} 16:07, 22 January 2019 (UTC)

@Arkhandar: Semantically/logically/abstractly: I think the relevant docs are https://www.w3.org/TR/WCAG20-TECHS/H43.html and https://www.w3.org/TR/WCAG20-TECHS/H63.html - If I understand those correctly, then it is acceptable to use different columns (not just the first) as a heading row. The intent of the markup is primarily to make things clearer to people using screen-readers, especially when they're navigating through a very complex table with many colspans/rowspans - i.e. we should use the heading column to denote the primary info that applies to each cell. So for the "List of games developed" the primary information is the game title, not the year, because it isn't a timeline(?).

Aesthetically/subjectively: I can understand the concerns about this being non-standard, and looking 'odd'. It looks a bit odd to me! But when in doubt, I usually check recently Featured items, and List of Hot Country Singles & Tracks number ones of 1995 was recently promoted with that styling, as was List of longest-living members of the British royal family, so I guess it's debatable! Hope that helps. Quiddity (talk) 00:47, 23 January 2019 (UTC)

@Quiddity: Thank you! Your reply is thorough and simple to understand. It's nice to have that cleared up! Aesthetically, while it does look different, it makes sense to highlight the primary info, regardless in which column it is. I actually prefer it that way, but I was worried it would violate markup or layout rules. I'll quote your answer on WP:VG to clear up things on that side. Once again, thanks for your time! ~ Arkhandar ^{(message me)} 01:01, 23 January 2019 (UTC)

@Quiddity: I think the more interesting notes are in the "notes" block of H63:

Note 1: For simple tables that have the headers in the first row or column then it is sufficient to simply use the TH elements without scope.

Note 2: For complex tables use ids and headers as in H43: Using id and headers attributes to associate data cells with header cells in data tables.

Note 3: Some users may find it easier to work with several simple tables than one more complex table. Authors may wish to consider whether they can convert complex tables to one or more simple tables.

When headers are not as in a simple table, they must use IDs and the headers attributes, and broadly, that's not the case. --Izno (talk) 04:06, 23 January 2019 (UTC)

Numbering

I am a little bit confused about this:

A: List of highest-grossing films

Rank	Film	Year	Director(s)	Studio(s)	Worldwide gross	Ref.
1	K.G.F: Chapter 1	2018	Prashanth Neel	Hombale Films	₹220 crore (US$26 million)	[1]
2	Hebbuli	2017	S. Krishna	SRV Productions	₹100 crore (US$12 million)	[2]
3	Raajakumara	2017	Santhosh Ananddram	Hombale Productions	₹75 crore (US$8.8 million)	[3]
4	Kirik Party	2016	Rishab Shetty	Paramvah Studios	₹50 crore (US$5.9 million)	[4]
	Mr. and Mrs. Ramachari	2014	Santhosh Ananddram	Jayanna Combines	₹50 crore (US$5.9 million)	[5]
	Mungaru Male	2006	Yogaraj Bhat	E. K. Entertainers	₹50 crore (US$5.9 million)	[6]
5	Doddmane Hudga	2016	Duniya Soori	Ajay Pictures	₹40 crore (US$4.7 million)	[7]
	Krantiveera Sangolli Rayanna	2012	Naganna	Sri Sangolli Rayanna Cine Combines	₹40 crore (US$4.7 million)	[8]
	Uppi 2	2015	Upendra	Upendra Productions	₹40 crore (US$4.7 million)	[9]
6	Kotigobba 2	2016	K. S. Ravikumar	Rambabu Productions	₹35 crore (US$4.1 million)–₹38 crore (US$4.4 million)	[10]

B: List of highest-grossing films

Rank	Film	Year	Director(s)	Studio(s)	Worldwide gross	Ref.
1	K.G.F: Chapter 1	2018	Prashanth Neel	Hombale Films	₹220 crore (US$26 million)	[1]
2	Hebbuli	2017	S. Krishna	SRV Productions	₹100 crore (US$12 million)	[2]
3	Raajakumara	2017	Santhosh Ananddram	Hombale Productions	₹75 crore (US$8.8 million)	[3]
4	Kirik Party	2016	Rishab Shetty	Paramvah Studios	₹50 crore (US$5.9 million)	[4]
	Mr. and Mrs. Ramachari	2014	Santhosh Ananddram	Jayanna Combines	₹50 crore (US$5.9 million)	[5]
	Mungaru Male	2006	Yogaraj Bhat	E. K. Entertainers	₹50 crore (US$5.9 million)	[6]
7	Doddmane Hudga	2016	Duniya Soori	Ajay Pictures	₹40 crore (US$4.7 million)	[7]
	Krantiveera Sangolli Rayanna	2012	Naganna	Sri Sangolli Rayanna Cine Combines	₹40 crore (US$4.7 million)	[8]
	Uppi 2	2015	Upendra	Upendra Productions	₹40 crore (US$4.7 million)	[9]
10	Kotigobba 2	2016	K. S. Ravikumar	Rambabu Productions	₹35 crore (US$4.1 million)–₹38 crore (US$4.4 million)	[10]

Which is correct? A and B? - Siddiqsazzad001 <Talk/> 05:48, 26 January 2019 (UTC)

What is the difference? --Izno (talk) 14:55, 26 January 2019 (UTC)

B is correct. Kotigobba was the 10th highest, not the 6th highest, as there are nine films ahead of it. CUA 27 (talk) 21:13, 3 February 2019 (UTC)

Yes, B is correct; the 7th through 9th items to appear in the list are all tied for 7th. That said, it seems highly unlikely to me that more specific figures cannot be found, since obviously none of these film grosses would have been exactly tied and someone is rounding excessively. So, the entire problem goes away if more precision is used.  — SMcCandlish ☏ ¢ 😼  08:48, 3 December 2019 (UTC)

Duplication of information in article and table.

Does anyone know what the MoS says about duplication of information in an article and table? An article I've been working on for a while had someone a few days ago remove several paragraphs because it the information could be found in the table below. Is it acceptable to duplicate that information or was the other user right to remove that? Kylesenior (talk) 08:53, 3 February 2019 (UTC)

Per WP:RAWDATA "articles with statistics should include explanatory text providing context". CUA 27 (talk) 21:12, 3 February 2019 (UTC)

@Kylesenior and CUA 27: i definitely think accessibility is optimised by having info in multiple formats (paragraphs, tables, and diagrams), as long as it's not repeated in the same format. Can we say that explicitly somewhere so people have something to cite if their consecutive contributions get deleted? Irtapil (talk) 05:54, 7 May 2020 (UTC)

Empty cells

Is there any guidance on how to handle cells that don't have any information (either because it is missing or inapplicable)? Should an emdash (—) be used as a placeholder? Or should it be left blank? A quick web search seems to tell me that screenreaders will read empty cells as "BLANK", so this is more of a concern about visuals rather than accessibility. Opencooper (talk) 02:32, 25 March 2019 (UTC)

Horizontal alignment

Is there some reason why there is no style guidance for alignment of content within cells. Based on my observation and experience with tabular information, text and dates are usually left aligned. Numbers are usually right aligned, or center aligned if the column has the same number of digits. What I see across enwiki are examples of center aligned columns that, to me, look amateurish. I would like to get other's views on this, and see if maybe we should formalize something into the MOS.- MrX 🖋 12:57, 27 March 2019 (UTC)

This is similar to the #Vertical alignment discussion. Generally, I don't think horizontal alignment is a point of conflict; if you see columns you think should be aligned left, just align them left. And so forth. --Izno (talk) 22:04, 27 March 2019 (UTC)

It has become a point of conflict recently, and in the past if I recall correctly. That's why I brought this here.- MrX 🖋 12:20, 28 March 2019 (UTC)

In my experience, left align works well for text and center align works well for numbers. The table formats in the examples in the article all look fine to me and should be a useful reference for readers. CUA 27 (talk) 18:54, 30 March 2019 (UTC)

@CUA 27: Center align works well for numbers seems to be you opinion, but I don't know what it's based on. I do know that it is non-standard when one looks at tabular data on the internet, in books, on business documents, etc. It looks amateurish. Given the low participation on this page, I think I might start a discussion on the village pump to get more people involved.- MrX 🖋 11:36, 5 April 2019 (UTC)

As in most things, it generally depends; I'm not sure a concise rule is desirable. Often columns with individual words can look best if center-aligned, while row headers, regardless of length, generally look best if left-aligned. Columns of integers can look very good center-aligned, while numbers with decimal points generally look best if the decimal is lined up (which may or may not be right-aligned). This to me is a case where we need to leave it up to individual editors to hash out on talk pages. CThomas³ (talk) 01:07, 28 November 2019 (UTC)

Columns of integers *with the same number of digits can look very good center-aligned (otherwise it not only looks horrible, but also hinders visual comparison). In fact, columns of decimals with the same number of digits before and after the decimal point can also look very good center-aligned, so it's the decimal point, actually, that needs to be aligned (whether explicit or implicit, as it is with integers). And there are templates to do this—e.g. {{decimal cell}}, {{decimal-align}}—when the figures don't come from the sources with the same number of decimal places, without making them appear to be more precise than they are there.

This should be included in the MOS. Guarapiranga (talk) 03:33, 28 November 2019 (UTC)

The software left-aligns by default, on purpose, and 99.9% of our content is laid out that way. I.e., it's a massive operational consensus on what to usually do. I.e., don't do something different unless there's a very good reason to. Just had essentially the same discussion yesterday on this same page (2 threads below); someone felt sure that WP looked crappy and unprofessional because all our tables and similar widgets weren't centered in mid-page, the way he'd presumably style his blog or something. There are serious usability and accessibility reasons (not to mention internal productivity ones) for not screwing around with centering and other layout futzing. For content inside table cells in particular: yes, there are good cases for other alignments, such as getting a column of figures to line up over the decimal point. And everyone with functional eyes already knows this. We do not need more WP:CREEP rules when WP has been humming along for 18 or so years using exactly the same left-dominant alignment for everything, with the exact same handful of exceptions. This does not come up often enough to be a big MoS thing. If someone is being boneheaded and wants to argue with you about it, just point them back here, or point them to the fact that virtually everything on WP is left-aligned, except for a limited but specific pattern of exceptions, and this is thus obviously how our editorial community wants it and what our readership expects. If they want to play the "there isn't a rule that stops me, so I will do any damned thing I feel like", point them at WP:GAMING and WP:WIKILAWYER and WP:NOT#BUREAUCRACY. And, we don't need to add more stuff to MoS about decimal alignment, either; the fact that pages like MOS:NUM use it, and we have templates for it, is already proof it's accepted practice.  — SMcCandlish ☏ ¢ 😼  08:50, 28 November 2019 (UTC)

I find it interesting you feel there is a need for the MOS to say that Wikipedia tables are are set flush-left, and allowed to grow rightward, not centered on the page, but not to say that numbers ought to be aligned at the decimal point, SMcCandlish. How come the arguments you laid out above apply here and not there? Guarapiranga (talk) 10:41, 28 November 2019 (UTC)

Also, if it's the software that left-aligns by default, that's not an operational consensus, but simply the preference of whomever designed it (or perhaps even a behaviour that was created without any particular consideration, simply bc English is read from left to right). Guarapiranga (talk) 10:46, 28 November 2019 (UTC)

Are you even reading what you're writing? The very fact that English is read that way is why it's preferable, and why we do it that way. It's at the core of the usability matters. And your assumption is incorrect anyway; if you go to he.wikipedia.org (Hebrew is a R-to-L language), you'll find the content, including tables, is overwhelmingly right-aligned. Ergo it is not possible this was just some random accident of a developer who didn't give it any thought. Our content intentionally aligns to match reading direction. On to the other bits: Whether to use columnar arrangement on the decimal is entirely context-dependent (though certainly common), and there isn't any kind of frequent "I'm going to impose my own design whims" usability problem being introduced by people doing unhelpful alternative alignments of number columns in tables. I.e., editors don't fight about it, so we don't need a rule about it. They just do what makes sense for the columns in question. When it comes to major blocks of content, though, we do pretty frequently have people trying to redesign Wikipedia's presentation paradigm, and it causes conflict, so we need to address it more directly. Perhaps more to the point, it's long-standing guideline wording, so removing it needs a consensus discussion, especially since doing so might have massive site-wide implications across potentially hundreds of thousands of articles. By contrast, we should not add new rules to an already over-long set of guidelines without good evidence that confusion and/or strife about that exact matter is common and intractable. If we did not take this "keep what lasts, resist adding more" approach to MoS (and to all other WP:P&G material), what would happen of course is that every long-standing rule that someone doesn't like would be subject to continual editwarring to undo it, meanwhile every random peeve and nitpick people could think of would get inserted, and we'd have guidelines and policies that were ten times as long but one tenth as useful. It's important to remember that these pages are not a style guide for the world and how to write throughout it; it is and only is a consistency-generating and dispute-reducing internal tool for production of this particular website. MoS should never, ever get near the comprehensive detail of The Chicago Manual of Style or New Hart's Rules, since no one would read, remember, or follow it.  — SMcCandlish ☏ ¢ 😼  19:22, 28 November 2019 (UTC)

There seems to be diverse opinions about this. Does anyone think that this is something we should submit to an RfC? @SMcCandlish: @Guarapiranga: @Cthomas3: @CUA 27: @Izno:. - MrX 🖋 23:20, 2 December 2019 (UTC)

Why not? Guarapiranga (talk) 00:13, 3 December 2019 (UTC)

@SMcCandlish:: we should not add new rules to an already over-long set of guidelines…

Except of course if it's you adding the rule that Wikipedia tables are are set flush-left, and allowed to grow rightward, not centered on the page. Good for thee, not for me? Guarapiranga (talk) 00:24, 3 December 2019 (UTC)

I added an observation not a rule, and that was over a year ago, with no objection. It is part of the guideline now; the WP:BRD onus is on you, not me. I think I detect the fallacy of the revelation of policy at work here, as if our WP:P&G came mystically from the gods rather than being written by us. :-) Every line-item in our P&G was inserted by one us, and neither is it less valid for having been added by an editor, nor is an editor's viewpoint on its validity irrelevant for having been the writer. We just don't need to keep adding more and more of them (much less contradicting them) without a showing that a1) the would-be change codifies actual practice (i.e., operational consensus) and is not an attempt to change it, and a2) that norm is ignored enough times by random individuals for us to bother recording the norm to forestall future dispute; or b) an explicit consensus to insert it has arisen, e.g. from an RfC, but that isn't going to happen without a1 and a2 being preconditions anyway. For more information, see WP:MOSBLOAT. And, no, a handful of editors wanting to center things doesn't indicate "diverse opinions" at any level approaching WP:CCC standards, when tens of thousands of editors are consistently doing tables flush left. We already knew there were a few individuals here and there trying to apply their own layout ideas like centering, or the line-item wouldn't have been added and wouldn't have met without opposition in being added. Anyone can open an RfC any time they want, of course, but when the outcome is this obvious it will just be a waste of other editors' time.  — SMcCandlish ☏ ¢ 😼  08:44, 3 December 2019 (UTC)

When should headings be plural (if at all)?

E.g. Country or Countries? Guarapiranga (talk) 23:52, 20 November 2019 (UTC)Í

Usually singular unless there's a good contextual reason to use the plural. WP:SINGULAR has us use singular for titles (absent a special reason not to in some particular case), and our article heading style (MOS:HEADING) is based on the title style (per WP:MERGE and WP:SPLIT, small articles can become sections, and large sections can become articles). Our table header style is, in turn, derived from the article section header style.  — SMcCandlish ☏ ¢ 😼  18:14, 27 November 2019 (UTC)

@SMcCandlish:: WP:SINGULAR has us use singular for titles … article heading style (MOS:HEADING) is based on the title style … table header style is, in turn, derived from the article section header style.

Doesn't that imply that the Country table header in Lists of countries ought therefore to be plural rather than singular? (I don't have a preference; just wanted to use a consistent form.) Guarapiranga (talk) 03:22, 28 November 2019 (UTC)

I don't see any such table heading at that page. However, that page is a good example of "unless there's a good contextual reason to use the plural"; several of its section headings are properly plural, either because using the singular would not be idiomatic in English, or because the nature of the sub-topic is itself plural. In short, all of this is basically a WP:Use common sense matter.  — SMcCandlish ☏ ¢ 😼  08:38, 28 November 2019 (UTC)

I'm of course referring to each of the pages listed on the index page, which are all called List of countries by ____, SMcCandlish, not to the index page itself. Ok, so the header should be Countries, not Country then. Got it. Guarapiranga (talk) 10:35, 28 November 2019 (UTC)

Yeah, it's contextual. "List of country by foo" isn't proper English. A heading or header might more sensibly use country or countries depending on the meaning. E.g., in a article like a list of sports arenas, it might have sections with titles like "By size", "By age", "By country". But in a table of stats about the human geography of continents, it might have columns like "Population", "Countries", "Languages", etc.  — SMcCandlish ☏ ¢ 😼  19:29, 28 November 2019 (UTC)

I just reread this, and I am no longer in doubt: the Country column header in Lists of countries ought to be singular, not plural. Column headers are field names; they should only be plural if the content for any given row may be plural, otherwise it ought to be singular (e.g. the Members column heading in List of regional organizations by population is plural, as each organisation has more than one member, and the Organisation column heading is singular bc each record, i.e. each row, refers to a single organisation). — Guarapiranga ☎ 05:12, 9 June 2022 (UTC)

margin:auto vs margin-left:0

I reverted SMcCandlish's addition last year saying: Wikipedia tables are are set flush-left, and allowed to grow rightward, not centered on the page. Why should that be standard? What other publication left justifies tables instead of centring it horizontally across the page? Personally, I always felt the left-justified tables in Wikipedia look crude and amateurish. Guarapiranga (talk) 22:24, 26 November 2019 (UTC)

And I've put it back, since it describes actual practice. See also the WP:PROPOSAL-related banner at the top of this page. If you want to change how 99.9% of WP's tables are done, then feel free to open an RfC about that. The main reason we do not center tables and other such content here is WP:NOTPAPER. Centering works well in, say, a book or a magazine. Centered tables look like total crap on a wide monitor, and it's a usability/accessibility problem. With small tables, the result can be downright confusing, and readers may actually miss the table completely.  — SMcCandlish ☏ ¢ 😼  18:09, 27 November 2019 (UTC)

Prose

There is a section of this article that has bothered me for an extremely long time and I'd finally like to bring it up: the idea that prose is inherently preferable to tables. I find this to be nonsense of the highest order. Tables are fantastic for centralizing key pieces of information in a format that is quick and easy to parse. Prose is the exact opposite of that. Am I alone in this? I've felt insane for years because I've seen so many articles have useful tables removed and converted to prose that is nowhere near as useful. I have only ever seen this specific part of the guideline used to justify making articles worse, not better. Lazer-kitty (talk) 19:26, 2 December 2019 (UTC)

The wording could probably use some clarification. But WP certainly has no shortage of tables, and they increase not decrease with frequency over time. At worst, it seems that some overly rigid interpretation of this passage may lead to some strife at particular articles; it's clearly not resulting in wholesale removal of tables. If we had some specific examples of articles being made worse (and examples that most editors would feel that way about), then perhaps how to adjust the text to discourage certain kinds of "prosification" would be easy to devise.  — SMcCandlish ☏ ¢ 😼  08:53, 3 December 2019 (UTC)

"it's clearly not resulting in wholesale removal of tables"

The Arsenal F.C. article has a very useful table of shirt manufacturers/sponsors throughout the club's history. The vast majority of major football club articles used to have such tables and they were removed in favor of prose. I find it absurd and laughable that anyone would think this information could be as easily and quickly parse in prose as it is in a table. I hesitate to even provide this example for fear it's going to be removed again.

"If we had some specific examples of articles being made worse"

I am currently engaged in a discussion regarding 2020 Formula One World Championship wherein some editors insist that several pieces of information should be removed from the entry list table and either outright deleted or moved to prose. Again, it is absurd to me that editors don't understand how quickly and easily information can be gleaned from a table. I will have to look through my contribution history to recall other examples of this conflict but I have encountered numerous editors across numerous articles who fail to grasp the inherent usability advantages of displaying certain discrete pieces of information in a table. And they all seem the think the prose section of this guideline gives them carte blanche to downsize or remove as many tables as they want.

I would personally suggest simply removing the prose section entirely. I don't see that it provides any value, and I strongly disagree with the broad assertion that prose should be preferred in articles. Some information is better displayed in tables, and other information is better written as prose. We should be allowed to determine which is better suited for each job. Lazer-kitty (talk) 13:02, 5 December 2019 (UTC)

Support and changed. Please feel free to wordsmith it (NTS). Guarapiranga (talk) 19:56, 5 December 2019 (UTC)

I see you didn't like my proposed changes, Izno. Care to join the discussion? Guarapiranga (talk) 00:07, 6 December 2019 (UTC)

The issue I have is that you made the changes before SMC had an opportunity to reply to LK. --Izno (talk) 01:41, 6 December 2019 (UTC)

Now we have a concrete change proposal to discuss recorded in that revision. All in the spirit of WP:BRD. Guarapiranga (talk) 02:13, 6 December 2019 (UTC)

Thanks for generating a useful proposal for discussion. I support the proposed revision. CUA 27 (talk) 05:24, 6 December 2019 (UTC)

I really like your proposed change, Guarapiranga. I feel very strongly about this topic - as should be clear from the above, ha - so my ultimate preference would still be to simply remove the entire section, but I can admit that's probably unreasonable. I agree with CUA 27 below - neither prose nor tables are inherently better than the other. They are simply different tools for different purposes, and can often complement each other. So I would support the proposed revision but I would also suggest adding a brief sentence that explicitly states neither prose nor tables are preferred, e.g. "Prose and tables are each suitable for different use cases and neither should be considered inherently preferable to the other." Lazer-kitty (talk) 15:57, 7 December 2019 (UTC)

I agree that LK’s modification improves upon G’s helpful proposal, as it makes more explicit the implicit message we had been trying to convey. I support the proposed change. CUA 27 (talk) 16:38, 7 December 2019 (UTC)

Of course. :) --Izno (talk) 03:21, 6 December 2019 (UTC)

That version looks like an improvement to me, and it seems like the majority here agree on it, can we please update it to that version? To me this looks like a consensus, but I'm not sure how to update it to that version without overwriting later edits? @Izno, Lazer-kitty, CUA 27, and Guarapiranga: Irtapil (talk) 06:12, 7 May 2020 (UTC)

Arriving slightly late to the conversation, but wanted to state that neither prose nor tables are inherently better as a blanket rule of thumb. I don’t think it’s productive to convert a useful table to prose just for the sake of it; a better approach may be to add text that explains the table. Certain subjects and information (e.g., sports) naturally lend themselves to table format. Many high-quality newspapers and magazines present sports information in tables. In conclusion, I would be fine with editing the prose section to state they are complements and one is not better than the other, and I’d also be fine with just deleting the entire section if the group cannot agree on the right language. CUA 27 (talk) 05:17, 6 December 2019 (UTC)

• Oppose removal - should make wording stronger and link to all the problems they cause. Last thing we need is more non mechanical readable content that causes those that use screen readers to get even less info from articles. Must always think of what is the best format for all our readers to get serviceable info from an article. At best charts or visualization should have the right coding or alternative text that conveys the type of visualization and some information so all can get data from them (but this never happens) Wikipedia:Manual of Style/Accessibility. Also must think of how much space charts take up....as we all know the more scrolling readers have to do the less of the article they will read Research:Which parts of an article do readers read. Also last thing we need is huge charts taking up space and causing mobile view problems in even more articles and sections in articles.--Moxy 🍁 16:56, 7 December 2019 (UTC)

@Moxy: I think accessibility is better optimised by having the information presented in multiple formats. There are probably far more people with ADHD, dyslexia, or low English fluency than people with sufficiently severe vision loss to use a Screenreader. Obviously just serving the majority is not acceptable, but we don't have to choose, we can have both.

Some articles might temporarily have just one, but it's a collaborative project, so if info is added as tables it can be explained in prose by a subsiquent editor who is more articulate but might not have access to the books or other references the first editor had. And if an article is a wall of text that is impenetrable to people with dyslexia or ADHD, young readers, others with low literacy, etc. then other editors can come along and add tables and diagrams.

If we are too rigid about format then we'll inevitably end up making the info inaccessible to some people. Or just end up with less info overall by deterring editors who might not be confident writers. Irtapil (talk) 06:12, 7 May 2020 (UTC)

Would it be acceptable to state that prose is not inherently preferable to tables BUT that tables should not be used (or their use should be minimized) if they cannot meet accessibility guidelines? Therefore if someone like myself wants to maintain tables I would be forced to put in the work to make them accessible. This might have the effect of improving accessibility across Wikipedia if there are many likeminded editors.

I don't entirely agree with your reasoning regarding the size of tables and user scrolling behavior. To me this research indicates that we should put the most pertinent information in an article at the top (the inverted pyramid) and structure it in whatever way allows the user to most quickly and efficiently access it. Sometimes this is prose, sometimes this in a table. We should be able to make that decision without being hamstrung by a guideline that dictates prose is always preferable. Lazer-kitty (talk) 18:11, 7 December 2019 (UTC)

@Lazer-kitty: I would be keen to be on the table tidying team if it means we get to keep more tables.

I have a bit of a bad habit of over complicating tables, but I'd be happy to adapt them to be more readable, if people gave some constructive actionable feedback instead of just deleting my tables, and if there were some guidelines for tables that were better than "use text instead".

I've been wondering if merged cells cause trouble? but repeating the same info in consecutive cells makes it more difficult for most people to see the pattern quickly.

I've also been wondering what the best approach would be for information which would not be very relevant to people with major vision deficiencies? e.g. if someone is reliant on a Screenreader then the details of the character shapes in different styles of writing are not very relevant to them? so the accessibility guileless are maybe not as important for content that's only relevant to people with fairly good vision? or am i missing something?

Irtapil (talk) 05:46, 7 May 2020 (UTC)

I would advise minimal uses when posible bUT never eliminating them. Agree 100% they definitely have their place but should be governed how image galleries are .... based on accessibility concerns, undo weight due to size or prominence of placement and of course sources were statements appear to aid our readers in research and verification.....pls see When to Use Tables and How to Make Them Accessible to Screen Reader Users - University of Colorado.--Moxy 🍁 22:17, 7 December 2019 (UTC)

It seems to me that to maintain WP:accessibility all that's required in non-list articles is for the tables to be discussed and integrated in the text flow, rather than shown orphaned with no clear connection to it. Guarapiranga (talk) 22:26, 7 December 2019 (UTC)

From Moxy's ref above:

When to Use a Table
… Tables are just as valuable to someone who is blind as to someone who is sighted. They provide information about relationships, simply explaining how one piece of information relates to another, and how sets of information relate to one another. Tables also make it easier to sort through a lot of information more quickly.

When Not to Use a Table
The biggest problem is when a developer uses a table in order to format a page. …

That's clearly not the cases we're discussing. We're talking about tables with actual content. hiGuarapiranga (talk) 22:31, 7 December 2019 (UTC)

@Guarapiranga: that's definitely not the main point being made on the Urdu alphabet talk page. If it's an accessibility issue the guideline should be to have text as well as tables, not that text is "preferred" (which implies text instead of tables). There are far more people who have ADHD, dyslexia, or low fluency in English than people with vision problems severe enough to need a screen reader. I sometimes attempt a screen reader if i can only find an idea presented as a long form text, but screen readers are kind of rubbish, tables or diagrams would be much better than a Screenreader. Irtapil (talk) 05:29, 7 May 2020 (UTC)

I definitely agree with the original post in this by @Lazer-kitty:.

When i look something up on Wikipedia I'm always looking for quick reference tables, infoboxes, maps, phylogenetic trees, etc.

Possibly I'm foolish to admit this, since for some reason our society seems to think reading a lot, reading quickly, and spelling correctly are a key indicators of intelligence or some other vague virtue. "He didn't read the book, he just looked at the pictures" is a cliché about a stupid lazy person? But I used to waste ages reading every word of genetics papers, but after years (longer than i should have taken to realise) i realised that the successful scientist didn't read every word, they read the abstract and looked at the figures, and only went to the text for specific details (e.g. the exact quantities of chemicals to use if they wanted to replicate the method).

The current version of this page doesn't even point out very prominently that some types of information are far more appropriate to present as a table? e.g. a paragraph that went through giving the names and pronunciations of the few dozen letters in an alphabet would be kind of impenetrable to almost everyone? but I've got people deleting my tables on alphabet pages.

I've had tables i made deleted on two different articles recently, maybe they were just bad tables, but the discussion page on one of the applicable articles has dissolved into a debate about tables not being recommended at all, and cites this info page as supporting evidence.

I suppose it's ironic for someone who struggles a bit with languages to find them so interesting, but i think that's kind of why i find them so interesting.

I think the messages should be that tables need to have explanatory text AS WELL not instead. The people who don't like tables can scroll past them like i do with long sections of text.

Irtapil (talk) 05:05, 7 May 2020 (UTC)

Better formmating with rowspan?

Any thoughts on how to format the table at ANSI_escape_code#Escape_sequences better? The mix of rowspan and large chunks of text that wrap make this difficult to read. Zebra-stripes, maybe, but I can figure out how to implement that. -- RoySmith (talk) 16:03, 18 December 2019 (UTC)

Multiple sections inside a table?

I thought this page has guidance on that, but it doesn't. Anyone has ideas? For example:

Usual	Table	Stuff	Here
Random section header
Usual	Table	Stuff	Here
Random section header
Usual	Table	Stuff	Here

Howard the Duck (talk) 16:26, 2 May 2020 (UTC)

Generally, just don't do this. --Izno (talk) 16:51, 2 May 2020 (UTC)

@Izno and Howard the Duck: why not? and what would be preferable? Irtapil (talk) 06:18, 7 May 2020 (UTC)

@Irtapil: I don't necessarily know why, just that we don't do it. I've never seen well-written articles (not necessarily WP:FA or WP:GA) doing this.

The preferable way is to end the table, make a section header outside of any table, then create a new table. Howard the Duck (talk) 05:43, 23 May 2020 (UTC)

Yes, I know that, but there should be something about this somewhere in the MOS. Howard the Duck (talk) 18:42, 2 May 2020 (UTC)

Why? The whole page advocates for use of tables only as data tables. Including random headings means you are not providing a data table. At least one spot advocates against colspan/rowspan mid table because of its accessibility implications. Between those, there's probably sufficient text. --Izno (talk) 19:10, 2 May 2020 (UTC)

I'm working on a series of articles where all articles have to look (and feel) the same, and I'm stuck on an argument that you can't have section headers inside tables. (These are still data tables, but there are cases where you'd have to split them into sections.) I suppose we needed something explicit about this, but I suppose what you said may work. Howard the Duck (talk) 19:19, 2 May 2020 (UTC)

Where to ask for help for a specific table

Here or somewhere else?--Prisencolin (talk) 06:32, 25 May 2020 (UTC)

Prisencolin here is fine. I can take a look. --Izno (talk) 14:50, 25 May 2020 (UTC)

Izno List_of_common_Chinese_surnames#Surname_list. Other than looking like an absolute mess, are there any specific MOS guidelines it violates? Can't imagine having text go past the actual width of the article whitespace isn't one of them...--Prisencolin (talk) 19:12, 25 May 2020 (UTC)

@Prisencolin: Well, that's a bit of a mess. Yes, I see some minor improvements to be made and I might take a try at them.

Otherwise, on most skins, the width is not an issue, though it can be an annoyance (I browse on Timeless and I can say I am annoyed :). I doubt the utility of presenting 15-some-odd Romanizations (including the non-Chinese), as well as the 'ranking' of the names. --Izno (talk) 03:22, 27 May 2020 (UTC)

@Prisencolin: Okay, I've taken care of some of it. We can't really shrink it without saying goodbye to some of the columns (or moving some to another table if we think the content is useful). Does removing any of those seem like a good idea to you? --Izno (talk) 00:40, 5 June 2020 (UTC)

Filmography v discography

As far as I understand the guidelines, the primary info in a row should come first. In the case of filmography, this would be the film. Recently, I've noticed that several filmography FLCs have reverted to the year being the first-row header. I'm a bit confused as to which one is right, especially as we have an example of a filmography table on this page which has the film first. Filmographies do things one way, as seen here and discographies another, example here. My understanding is that the discography version is better for readers with accessibility issues, especially those using screen readers but I'm not 100% sure on this. Filmographies used to follow the example shown on the page but have recently reverted. My question is should the convention be for the primary source of information to come first to come, in this instance the film, or not? NapHit (talk) 20:44, 27 May 2020 (UTC)

@NapHit: Filmographies used to follow the example shown on the page ...: The filmography example on Wikipedia:Manual of Style/Tables and the Aniston filmography both have rows beginning with the year and then the title. Perhaps you instead meant to say discographies differ from the example? At any rate, this MOS seems to be presenting examples of how to use tables, as opposed to recommending a preferred version for a given domain. As far as accessibility, I think "scope" can be specified if the "primary info" is not in the first column. That said, I would generally place the key that is used to sort the default table in the first column; however, I don't believe that is formalized in a written guideline.—Bagumba (talk) 04:12, 28 May 2020 (UTC)

Thanks for your response Bagumba. The page I was referring was this page. They have a different style for filmographies than the one on this page. I was curious if there had been a discussion regarding this as the film used to come first in these tables. I think I was under the impression there was a formal guideline when it appears there wasn't and isn't one. I suppose if the film was specified as the scope that would be better than the year? NapHit (talk) 11:30, 28 May 2020 (UTC)

@NapHit: You might also consider leaving a notification about this at WP:FILMOGRAPHY. Regards.—Bagumba (talk) 11:35, 28 May 2020 (UTC)

@NapHit: I brought up the same question a couple of years ago (you can look above), and the conclusion is that in terms of accessibility it makes no difference. It's just a matter of style. Honestly though, the current version looks awkward. It gives emphasis to the year rather than the title itself. And with no rowspan in the years, it looks and reads even worse. The previous version's rationale could be easily interpreted as the titles being the main content with the years next to them as a kind of timeline of sorts to inform the reader. I would've preferred them stylized this way. ~ Arkhandar ^{(message me)} 00:00, 7 July 2020 (UTC)

Explanatory notes for tables

What is current best-practice for adding notes to tables, such as for defining/explaining headers, abbreviations, symbols, or formatting? Lots of filmography tables use a row background color and dagger symbol, with a separate "table" used to define its meaning, so it is not semantically connected. Some tables have fairly long column-titles for narrow contents, which makes the column wide and hard to track across visually. Sometimes a regular <tag|ref> is used (or a separate "notes" group), which makes the marker clickable but entails being scrolled all the way to the page end (and having to jump back again) for simple understanding of concise info. Rarely I see the ref-group immediately below the table, which seems the most useful place. But sometimes it's regular text (not clear that it's notes for the table) rather than small and width-matched to the table. And other times it's in a final row of the table itself (rowspan=X for full width), which makes the best formatting result but is semantically wrong and breaks with sortable tables. Rarely I've seen a container table or frame used to bind the ref-group to the table size and position, which also works, but is a bit of formatting abuse for something that seems so simple. DMacks (talk) 03:05, 13 July 2020 (UTC)

I don't know if it's on this page or anywhere else, but keys should be provided before a table as this makes the notation used in the table accessible (to sighted and unsighted readers), rather than 'as part of' (as in a 'footer' of the table) or below the table. These keys can provide color and symbol meaning.

I do not think such a key is necessary for notes using a notes group of some sort. For table notes, I would prefer to let those filter into the set of other notes usually at the bottom of the page (not the {{reflist}} notes but the {{notelist}} notes). I would not worry about where those land. Users who need to access them can use their browser back button or indeed scroll to return to where they were after clicking the note. (That's if they don't read the note using either nav popups or the hovercards gadgets.)

Abbreviations should use <abbr>...</abbr> or {{abbr}}. Off the cuff, I think you could use this with symbols and the HTML semantics would be acceptable, but I am pretty sure I would not favor that use.

Regarding explaining headers, that also can and should be provided prior to the table if necessary. (There is the HTML-standard-deprecated attribute summary for tables that you can use, but it hides that explanation of table use away from sighted readers, which I believe is why it is deprecated. You really shouldn't use it.) --Izno (talk) 15:48, 13 July 2020 (UTC)

Lacking guidance on left vs. center justification

I came here since I'm reviewing a featured list candidate, List of Broadway Theaters, and I'm wondering which columns ought to have text be left-aligned and which ought to have it centered. There appears to be no guidance on that, though. What is the general/best practice? (please use {{ping|Sdkb}} on reply) {{u|Sdkb}} ^talk 20:05, 5 September 2020 (UTC)

In general it advised to align text left and numbers right. Both is based on ease of scanning. Finding a name in a list works easiest if they al start in the same location. Comparing numbers is easiest when they align the corresponding decimal positions. Centering is sometimes useful for short codes. Years are a special case and could be left aligned because they are almost always equally long.{{ping|Sdkb}} −Woodstone (talk) 06:16, 25 September 2020 (UTC)

Discussion on Help_talk:Table#Use_of_em_and_%_values_in_preference_to_px_values

There is a discussion on Help_talk:Table#Use_of_em_and_%_values_in_preference_to_px_values about changing the examples to comply with the recommendations on the page that say to avoid using pixel sizes, if anyone is interested in weighing in. Schazjmd (talk) 15:20, 20 December 2020 (UTC)

In the absence of comment, a draft of the proposed changes has been prepared. Please comment or edit here. SCHolar44 🇦🇺 💬 at 03:28, 18 January 2021 (UTC)

Wikipedia:WikiProject Discographies has an RFC

Wikipedia:WikiProject Discographies has an RFC for a possible alternative format for singles discography tables. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. Heartfox (talk) 01:33, 22 January 2021 (UTC)

Conflicting guidance on headers

Previous discussions on this topic: See #Filmography example, and #Filmography v discography.

Problem: there is potentially conflicting guidance in MOS:TABLE and WP:DTAB (part of MOS:ACCESS) on which column should be the rowheader in data tables of creative works (and in any other case where there is a "year" and "title" column):

• The "Discographies" and "Filmographies" examples in TABLE use "year" as the header for each row, while DTAB seems to discourage this, saying "Because the row header ... may be spoken before the data in each cell when navigating in table mode, it is necessary for the column headers and row headers to uniquely identify the column and row respectively." If this is strictly true, MOS examples like this don't appear to follow DTAB guidance:

Current

1968	Rosemary's Baby	Girl at Party	Film; uncredited
1968	The Wrecking Crew	Freya Carlson	Film

• If "title" should indeed be the rowheader instead of "year", there is a separate question to answer.

Exhibit A

1968	Rosemary's Baby	Girl at Party	Film; uncredited
1968	The Wrecking Crew	Freya Carlson	Film

Exhibit B

Rosemary's Baby	1968	Girl at Party	Film; uncredited
The Wrecking Crew	1968	Freya Carlson	Film

Can the "year" column still be on the left of the "title" header, like in Exhibit A, or should the "header" row always come first, like in Exhibit B?

Here is a history of the two tables in question in MOS:TABLE, which may be useful:

• January 2013: ([1]) Discography table had no headers. Filmography table added, with title headers.
• May 2019: ([2]) Discography table gained year headers.
• May 2019: ([3]) Filmography table changed from title to year headers.

I have placed notices of this discussion at WT:ACTOR (since this discussion concerns the guidance in WP:FILMOGRAPHY), at WT:DISCOG (for the same reason), and at WT:ACCESS and WT:WPACCESS. — Goszei (talk) 06:38, 24 March 2021 (UTC)

I'm interested to see how this discussion goes, as I was (once) active with work on WP:DISCOGSTYLE (which never quite made it to MoS status) and we discussed these things at some length. My clear preference is the form at Exhibit B, since it shows what the table's a list of in the left-most row. Additionally and appropriately, it applies scope="row" to that column's entries (film names). That's (not coincidentally) the form we use in WP:DISCOGSTYLE for the singles table.

One of the edgy points of the discussion was that many people like to put (or are used to putting) the year first, as if that's what's defining the data. We see this especially often in tables for awards (Oscar, Emmy, etc.), but shiploads of articles use the year-first form for filmographies. Somewhere (I have no idea where), we determined that a year-first format can be maintained if the actual main item (column) gets the scope="row" treatment, as in Exhibit A. It's kind of a compromise solution for (may I resprectfully say: stubborn/uneducated?) Wikipedia editors.

The compromise compromise solution is the form you haven't labelled, the Filmography status quo. It leaves year first (although that's not what it's a table of) but it at least comfortingly slaps the scope="row" into the 1st-column cells, so it "looks" "right".

WHAT TO DO: Well, the first thing I notice (finally...) is that the guidance here for Discographies is in conflict with WP:DISCOGSTYLE; the year column should be removed from the "Multi-column standard with subcolumns" section as non-DISCOGSTYLE-compliant and also redundant. The Title column should get scope="row" added. Then (says I), the "Multi-column mixed sortable unsortable" section should be changed, swapping Year and Title content, but leaving scope="row" in the first row.

If we were to make such changes, it would help shape future usages in a Good Way™ and may help in arguing with (pron.: educating) editors when retroformatting existing tables. It'll be a long, long battle, but still... Thanks for pointing this out, Goszei. — JohnFromPinckney (talk) 08:03, 24 March 2021 (UTC)

A problem I've just noticed with the above: WP:FILMOGRAPHY is at variance with my noble recommendations (and WP:DISCOGSTYLE). It is, I now realize, the unlabelled status quo version above Exhibit A. Now I'm wondering how open the Film folks are to rethinking their recommendations. — JohnFromPinckney (talk) 08:22, 24 March 2021 (UTC)

I am very much against "forcing" 'title' to be the first column – 'title' vs. 'year' as the first column should very much be an "open choice" for editors and WP's, and in the case of 'Awards' tables, anything other than 'year' as the first choice could very well be problematic in many cases. So hopefully the former "guidance" on this is out-of-date and is no longer correct, as the old guidance on 'rowspan' was dropped for similar reasons. --IJBall (contribs • talk) 13:02, 24 March 2021 (UTC)

Exhibit B is still preferred for navigation purposes alone for screen-readers et al. While the exhibit A is sufficient from an accessibility point to indicate the focus of the row of interest, my understanding is that screen readers have a much easier time moving through tables where the main focus is the first column. Izno (talk) 16:27, 24 March 2021 (UTC)

(From the purely aesthetic, I am not a fan of mid-row table headers.) Izno (talk) 16:32, 24 March 2021 (UTC)

So "Exhibit A" is actually acceptable? I've wondered about this for some time, as it would seem to solve some problems... --IJBall (contribs • talk) 18:29, 24 March 2021 (UTC)

How are making it harder for screen readers to navigate the table (and they're the "target market" for all this markup in the first place), and making the table aesthetically weird and visually confusing by putting rowheaders in mid-row, "seemin[ing] to solve some problems"? Rather the opposite, I would say. — SMcCandlish ☏ ¢ 😼  03:34, 25 March 2021 (UTC)

• Use the version listed above as "Current". The argument that 'making the rowheaders be (in this case) the work titles, even in a chronological table, is needed to make it clear what the table is about' is bogus reasoning. That is the job of the introductory material immediately above the table, and/or some combination of the summary and caption attributes of <table>. Meanwhile, putting rowheaders in mid-row (Exhibit A) is actually a screen-reader as well as a sighted-reader impediment to understanding. Exhibit B isn't a problem in alphabetical-by-subject tables, but is not helpful when our intent for a table is to be chronological, which is almost always the case for lists of works as well as for many other table types. That is, a "title title of the work must be rowheader and before the date and other data" is not a fixed rule we can sensibly impose.

  In short: The first column should contain the rowheaders, and should be whatever the table is sorted by (or default sorted by, in the case of re-sortable tables).

  PS: Yes, I agree that the two (three?) guidelines, and any non-guideline style essays, all need to agree on whatever the final outcome of this discussion is, per WP:POLICYFORK and WP:ESSAYFORK.
   — SMcCandlish ☏ ¢ 😼  03:34, 25 March 2021 (UTC)

Obviously, I'm fine with this, as this is how WP:FILMOGRAPHYs and 'Awards' tables are already organized generally. I agree that "forcing" a 'Title'-first formatting in tables would be a terrible outcome, as lots of tables should be organized chronologically. P.S. 'Exhibit B' isn't a problem, as long as the 'Year' column isn't rowspanned – this, in fact, is the issue with many 'Discography' tables in which WP:DISCOGSTYLE is ignored and the 'Years' are rowspanned regardless because some editors have an obsession with this. --IJBall (contribs • talk) 12:25, 25 March 2021 (UTC)

Hi, IJBall. You agree that "forcing" a 'Title'-first formatting in tables would be a terrible outcome, as lots of tables should be organized chronologically. Why can't the tables be Title-first, and arranged (meaning ordered) chronologically, too? Would that work for you?

In case it's not clear (to the extent that you or anyone else cares), I'm not arguing that year data is unimportant, only that the tables are lists of films or TV appearances or awards, which is why (IMO) they belong in the first position. The year data is relevant and should be provided, but to the right of the main whatevers. — JohnFromPinckney (talk) 15:32, 25 March 2021 (UTC)

No, as per SMcCandlish's point. It's fine that WP:DISCOGRAPHY decided that their tables should be 'Title' first. But for other WP's, it was decided that if you are going to order tables chronological, 'Year' first makes the most sense, as that is what is organizing the order of the table. Ruling that out as an option seems like a massive overreach, and really is an unjustified encroachment on editorial freedom and WP independence... Now, that said, I do wonder the 'Current' version becomes problematic if the 'Year' column using 'scope=row' is also rowspanned – if so, that needs to be made clear, so we can be clear about this. --IJBall (contribs • talk) 19:41, 25 March 2021 (UTC)

Yeah, this rowspan stuff causes accessibility problems.  — SMcCandlish ☏ ¢ 😼  10:11, 3 April 2021 (UTC)

Football box collapsible

Bolivia v Argentina

13 October 2020 2022 World Cup qualification	Bolivia	1–2	Argentina	La Paz, Bolivia
16:00 UTC−4	Moreno 24'	Report	L. Martínez 45' Correa 79'	Stadium: Estadio Hernando Siles Attendance: 0 Referee: Diego Haro (Peru)

Hello, is the format above considered a kind of table that is recommended and not mandatory in sports articles, especially if the articles contain details and an extensive context? It seems to me that it can be considered a table. It also makes browsing such articles on mobile devices much easier. Thank you--Sakiv (talk) 22:17, 5 June 2021 (UTC)

Requirement for key?

Is there any guidance for using a key if a table uses abbreviations in its headers? For example, consider Template:NBA player statistics start, which uses basketball domain specific abbreviations. While it provides a tooltip, those are not accessible on mobile without a mouse (though apparently it's not an issue for screen readers per MOS:NOHOVER). The question has come up whether Template:NBA player statistics legend is overkill.—Bagumba (talk) 13:32, 19 June 2021 (UTC)

Bagumba, Why isn't this answered by MOS:NOHOVER which includes an explicit exception for use of the {{abbr}} template? I now realize you were asking whether both should be included. If the implication is that use of both is overkill, I agree. S Philbrick(Talk) 14:03, 19 June 2021 (UTC)

No, my question is whether it's a concern that mobile users won't have access to the abbreviation meanings without a key.—Bagumba (talk) 15:24, 19 June 2021 (UTC)

I do not know of and can't find any such guidance, although I was hoping Wikipedia:Manual of Style/Abbreviations would have something explicit for us. The closest I could find there was If it is necessary to abbreviate in small spaces (infoboxes, navboxes and tables), use widely recognised abbreviations.

Assuming the NBA legend template (and the statisics template itself) use widely recognised abbreviations, then they're okay to use, but I, for one (even as a sometime observer and [long-ago] player of basketball), would benefit from the explanatory legend, as I doubt I would know more than half of those headings without hovering. Beyond that, of course, there seems to be no hover-responsive tooltip for the symbols (dagger, double-dagger, asterisk) or the bolding, so there's no chance of even a desktop user knowing what is meant. So, specifically, that legend template is, IMO, certainly not overkill, but in general, the only guidance I can offer is the implicit rule that we communicate clearly and understandably to our readers (even those who don't follow basketball). — JohnFromPinckney (talk / edits) 23:04, 20 June 2021 (UTC)

Yes, I didn't find Wikipedia:Manual of Style/Abbreviations#Use sourceable abbreviations applicable here. While the average reader may be expected to recognize NZ for New Zealand or GNP for gross national product, it doesn't seem reasonable to expect the average reader to know basketball-specific abbreviations; mobile users without a mouse wouldn't be able to hover either.—Bagumba (talk) 10:17, 21 June 2021 (UTC)

JohnFromPinckney, There are at least two ways helping the reader understand the heading which may be abbreviated for space considerations.

Option 1 - Use a key, typically a template which contains the abbreviations and an explanation of each one. As an example see April Sykes

Option 2 - Use the abbr template to popup an explanation when hovering a mouse over the abbreviation. As an example see Jimmy Black (basketball)

There are some articles which use both Michael Jordan. That seems like an unnecessary redundancy but it's a featured article so some people apparently like it.

I fully understand and buy into the arguments in favor of option one. In fact, when I first started this initiative that's exactly what I did. See this version of Sytia Messer]. The table includes shortened headings, and the legend includes an explanation. Please note that this improvement to the article was reverted. My discussion with the editor was mildly contentious Wikipedia_talk:WikiProject_Basketball#Proposal_for_player_stats, and I still don't feel I fully understand the objection. My best guess is that my table included some stats not explained in the "standard" templates, so my creation of a template supporting all the fields was not acceptable for some reason. I'd be happy to included a key/legend, although if I do so I will probably drop the abbr. Any thoughts on how I persuade other editors this is a good idea? S Philbrick(Talk) 18:02, 22 June 2021 (UTC)

Well, there are the arguments of clarity and accessibility. Usually, discussions of "accessibility" revolve around color-blindness and screen reader users, which don't apply in this case; the use of {{abbr}} means users of screen readers should have no problems there (and colors aren't relevant). The guidance at MOS:NOTOOLTIPS seems to be stuck firmly in the "think-about-screen-readers" mode, and does not seem to consider mobile users, which I understand to now be the majority of our readers.

I think the legend template (Option 1) is justified to cater to those who visit using smart phones and don't know the terminology. Otherwise, they may be puzzled as to why we're providing miles-per-gallon stats. I can't offer any more than that. It seems like common sense to me, but, uh, that's not always enough. — JohnFromPinckney (talk / edits) 23:21, 22 June 2021 (UTC)

I added Wikipedia:Manual of Style/Tables#Explanatory notes and legends since this has come up before on this page, it's come up for me recently editing articles, and there seems to be a strong consensus, especially looking at Wikipedia:Featured lists. Feel free to tweak or discuss or object. -- Beland (talk) 23:22, 9 January 2024 (UTC)

The section added by User:Beland seems to be self-serving and written to support his otherwise not so strong arguments on Talk:List of winners of the Rotterdam Marathon#Table abbreviations, so I recommend a thorough review. – Editør (talk) 12:00, 10 January 2024 (UTC)

Yup, that among other articles is what I was referring to when I said it had come up recently. It's a bit demoralizing given my many hours of volunteer editing that this brief attempt to make tables easier for readers to understand is being labelled as selfish. 8( I guess if no grounds are found on which to attack an idea on its merits, the only thing left is to attack the author. In any case, I agree: please do review the new text thoroughly; I want it to represent consensus and not just my personal opinion. -- Beland (talk) 19:32, 10 January 2024 (UTC)

I do support the notion; I am reviewing the prose and giving it a copyediting pass. Remsense留 20:15, 10 January 2024 (UTC)

Done—that being said, I am not rigid on the use of a key specifically, as long as all usage is explicated somewhere—this should be the subject of further discussion. Remsense留 21:09, 10 January 2024 (UTC)

The "color coding" portion might need revision since it sounds like it will cause accessibility issues with screen readers. The meaning indicated by color coding ... should be explained in a legend (also called a "key") accompanying the table.

Colors and text formatting (ex. bold, italics) should represent data already in the table, whether this style is applied to all or a single column/row, as opposed to data solely in a legend that might say "____ in bold". The colors could represent an accessible symbol matched to a legend, as indicated by MOS:COLOR.

A questionable use of a row color legend, which I recently came across in South Korea national under-20 football team#2023 (archive), is having a column of game scores (1-1, 3-2, 3-2) separating two team columns, and row colors that the legend indicates as a win, tie, or loss. For screen readers, not only can they not see the colors, but the win/tie/loss has to be inferred from multiple columns for the team mentioned in the page title. Jroberson108 (talk) 02:35, 11 January 2024 (UTC)

I've further edited the passage per this. Remsense留 02:47, 11 January 2024 (UTC)

@Remsense: Thanks for the edits. I agree about color, was just trying to avoid being verbose and repeating other guidelines. But perhaps it bears repeating for clarification and to explain how it interacts with tables. For the passages tagged for more discussion...the idea of repeating keys for multiple tables in the same article I got from List of National Football League annual passing touchdowns leaders, which is a featured list. It seems excessive to require this for say, three tables of two rows each right next to each other, so I tried to give an idea of when it's useful. The other tagged passage is essentially "write it out in full if there's room". Is there an example you're thinking of where there's plenty of space and excessive repetition is avoided, but an abbreviation is preferable over full words?

As for whether an explanation elsewhere is sufficient...I could see that if it's some complicated concept that you really just have to read the prose to understand, maybe? I'm thinking maybe for complicated equations or something like that, but those tend to be displayed as one-liners that are then immediately explained, not in tables with lots of rows. But for cases where simply writing out a few words can fully communicate the meaning of the symbol or abbreviation, it seems like a bad user experience for someone who has just popped into an article to look at a table, to expect them to go searching through the prose to figure out what certain things in the table mean. The featured lists I found with tables all seemed to have legends; I'm curious if there are any tables with unusual symbols or abbreviations in featured pages without legends. I clicked through a bunch more featured lists and could not find any. -- Beland (talk) 21:48, 11 January 2024 (UTC)

re color: Agreed.

re prose: I'm working on List of World Chess Championships right now, and I am definitely seeing the use of prose (that I haven't written yet) to express dimensions that there isn't room for additional columns for, as well as one-off nuances for additional events. Remsense留 22:10, 11 January 2024 (UTC)

@Remsense: What sort of dimensions and nuances do you mean? By "prose" do you mean footnotes or article body text? -- Beland (talk) 23:28, 11 January 2024 (UTC)

Fixing Hell's Kitchen tables

As the title suggests, I'm wanting to fix the tables on the articles for the television show Hell's Kitchen- specifically, the contestant progress table on the respective season articles.

I'm not the best with coding, but most things I'm able to figure out. This however, I'm a bit stumped on. Basically, looking at the current version, you can see some extra space at the top left of the table, right above "No." and "Chef". I'm wanting to just have those two areas ("No." and "Chef") to be multiple row lengths, to get rid of that unnecessary blank space- something similar to the tables on The Masked Singer articles such as at The Masked Singer (American season 5)#Contestants.

Seems simple enough. However... looking at just how these tables are coded, it seems to be a bit trickier than I had originally anticipated. I think(?) the best progress I've gotten towards fixing this can be viewed at User:Magitroopa/sandbox/MasterChef (American TV series)#Hell's Kitchen, but can't seem to get the "Episodes", "Original teams", and episode numbers moved over. Any help solving this would be greatly appreciated, thanks in advance. Magitroopa (talk) 04:08, 22 June 2021 (UTC)

Before you spend any more nanoseconds on this, Magitroopa, take the time to look at this RfC, in which the future (format/desirability/accessibility requirements) of such tables is being discussed. — JohnFromPinckney (talk / edits) 04:31, 22 June 2021 (UTC)

Dashes

I don't see any guidance on the use of dashes in tables. In many instances, the emdash is used, but endashes also have a presence, though I'm uncertain if one style has prevalence over the other. Dawnseeker2000 18:00, 31 July 2021 (UTC)

Presumably you're talking about a dash alone in a cell, indicating something like "not available", "not applicable", "we don't know", etc. I'm unaware of any such guidance myself. Discographies tend to use em dashes, but I have seen a lot of other tables with en dashes (and of course, lots and lots with hyphens). IMO, EMs look better because they stand out enough to signify their presence (unlike hyphens, which are sometimes barely noticeable).

I think it's up to you (i.e. us/the editors at any particular page) to decide what works best. One thing for sure is, the dashes used should be consistent on each page. — JohnFromPinckney (talk / edits) 18:55, 31 July 2021 (UTC)

This is now being discussed here in relation to whether {{n/a}} should render to emdash instead of N/A by dedault. — Guarapiranga ☎ 07:06, 9 June 2022 (UTC)

Prose in tables

I've recently come across an article which has long (>900 character) prose in several cells of a table. (It's NASA Astronaut Group 4.) Everything I can find in the MOS talks about putting information in prose versus in tables. To me, that means table entries aren't supposed to be prose, just things like short things like names, dates, etc. I also think lengthy prose in a table entry makes messes up the formatting and makes it hard to read. Is there any consensus on putting multiple sentences of prose in a single cell of a table? Fcrary (talk) 23:39, 19 September 2021 (UTC)

I don't have any part of the MOS to point you to which you probably haven't seen, but I do agree those are lengthy texts for a table. The really silly thing about it is that every one of those table rows is about an astronaut who already has a Wikipedia article. A table cell for "Career", IMO, is overkill there (especially, a long table cell). But I see that NASA Astronaut Group 3 and Group 2, etc., are just as bad (or worse; Armstrong's blurb is 248 words long). If a "career" cell is necessary, it should be trimmed way down. — JohnFromPinckney (talk / edits) 20:26, 22 September 2021 (UTC)

Since the article-topic is astronaut, how about each entry is a bullet-list of their space missions? DMacks (talk) 13:21, 26 November 2021 (UTC)

That would be an excellent use of merged cells: a row for each astronaut-mission, with most of the cells except the missions vertically merged for each astronaut. Then when the user hits "sort" on the mission column header, the other cells are split and replicated as necessary to display a table with the list of astronauts for each mission.

Astronaut	Mission
Fred Flintstone	Apollo Stones
	Gemini Rocks
	Soyuz Sands
Barney Rubble	Gemini Rocks
	Apollo Stones

Martin Kealey (talk) 10:06, 9 February 2024 (UTC)

Grouping table cells

I am wondering if there is currently any guidance at all in the MOS about when to group cells in a table using rowspan or colspan? I've noticed that there are quite a bunch of wildly varying philosophies among editors about when to do so; I see some people group cells almost anytime they contain the same content, and others actively removing it because it makes the table look ugly. I think that having a dedicated section in the MOS could make these kinds of decisions a lot easier. ―Jochem van Hees (talk) 10:59, 25 October 2021 (UTC)

You're right, Jochem, there isn't. I'd say rowspan ought to be used in a column heading whenever other column headings have more layers to them, e.g.:

Country	Population
	amt	pct

The same can be said for row headings. Now, in relation to data cells, I'd say colspan can be used when the data is shared across fields (e.g. {{oldid2|1034694173|List of countries and dependencies by area), or rowspan when it's shared across records (presuming records are on rows; the other way around otherwise). — Guarapiranga ☎ 06:15, 9 June 2022 (UTC)

Table vs list

​I'm writing a new article about someone who has published 20+ books and articles. Should I do it as a table as shown in this article​: https://en.wikipedia.org/wiki/Bernard_Lewis_bibliography ​ or as a bullet point list, as I see in many places. Thank you. Steal the Kosher Bacon (talk) 13:15, 26 November 2021 (UTC)

As a bullet point list, Sir Bacon. That Bernard Lewis bibliography is atrociously at odds with WP's style (which, as you said, we see in many places), and should merged into the author's article (which already contains mostly all of the content in its Bibliography section anway). — Guarapiranga ☎ 05:26, 9 June 2022 (UTC)

thank you Steal the Kosher Bacon (talk) 04:41, 15 June 2022 (UTC)

Totals and subtotals

I looked for style guidance on totals and subtotals, and couldn't find any. Is there? I've seen totals being formatted in a myriad of forms; it could be good to apply some style consistency across enwiki. Things like:

• Should totals and subtotals be bolded, shaded or formatted as headings?
• What formatting (if any) should distinguish totals from subtotals?
• Should they be above or below the data they total?

— Guarapiranga ☎ 06:33, 9 June 2022 (UTC)

Use of "|style="

This edit got me curious. Is changing |style="text-align:left;" to |align=left best practice, or does it not matter? Mac Dreamstate (talk) 19:51, 2 October 2022 (UTC)

@Mac Dreamstate: I know I'm replying a bit late, but as far as I can tell the two work exactly the same way, so it does not matter. However, W3 has deprecated the align attribute according to this document, so if you have to choose, then style="text-align: left;" is better. ―Jochem van Hees (talk) 11:31, 3 May 2023 (UTC)

Aurochs has an RFC

Aurochs has an RFC for the application of policies and guidelines to cladograms. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. 89.206.112.13 (talk) 08:29, 3 May 2023 (UTC)

Fixed row and column headers when scrolling tables

Is there a way to have the column header row in the table stay fixed at the top when scrolling down through the rows. In a long table you cannot tell what the column headers are when you scroll down. For example, see the table "Supported" in the article https://en.wikipedia.org/wiki/List_of_iPhone_models#Unsupported_(64-bit_CPU). I freeze row and column headers often in spreadsheets and it seems that it would be also useful in Wikipedia. Would you please submit a table feature request if possible.

thanks. 75.72.161.233 (talk) 22:27, 5 August 2023 (UTC)

Colors

Is there any rule or standard for the colors that are used for different options in polls in articles? The colors on polls related to elections are understandable. For others, like yes/no type polls, green and red are often used in polls about a topic, but there does not seem to be any consistency in the usage of green and red for yes and no respectively. Are the colors chosen randomly? Also, considering that green and red have opposite symbolic meanings, using them is such polls would be a violation of WP:NPOV right? JonSnow64 (talk) 14:01, 25 August 2023 (UTC)

Tool(s) for working with wikitables

FYI

 – Pointer to relevant discussion elsewhere.

Please see: Help talk:Table#Tool(s) for working with wikitables.  — SMcCandlish ☏ ¢ 😼  03:37, 26 August 2023 (UTC)

Proposal to discourage vertically oriented ("sideways") column headers

4.4.1 Edit tables with the same attention given to text, and set them as text to be read.

Tables are notoriously time-consuming to typeset, but the problems posed are often editorial as much as typographic. If the table is not planned in a readable form to begin with, the typographer can render it readable only by rewriting or redesigning it from scratch.
Tables, like text, go awry when approached on a purely technical basis. Good typographic answers are not elicited by asking questions such as "How can I cram this number of characters into that amount of space?"
If the table is approached as merely one more form of text, which must be made both good to read and good to look at, [then] several principles will be clear:

1: All text should be horizontal, or in rare cases oblique. Setting column heads vertically as a space-saving measure is quite feasible if the text is in Japanese or Chinese, but not if it is written in the Latin alphabet.

— Robert Bringhust, The elements of typographic style

References

Setting column titles vertically (and diagonally) has long been a facility of Microsoft Office; HTML 5 and CSS 3 introduced the technology for web pages; Help:Tables#Vertical column headers is a whole section of instructions on how to do vertical headers like this, and there is a template, {{Vertical header}} for doing it. MOS:UNITNAMES (at the table "General guidelines on use of units") has an example of existing use. None of that excuses poor practice.

Has no-one considered the accessibility implications of this technique? Visitors with screen-readers at least have the advantage that the markup is ignored. When used in a book (despite being poor typographic practice), at least one can rotate the book: that is not so easy with a desktop screen; do so with a mobile and the OS helpful rotates the display in the opposite direction. Book typographers at least have the excuse of the physical dimensions of the paper size; no such constraint applies to a Wikipedia. We don't even have the excuse of "How can I cram this number of characters into that amount of space?"

This is to invite discussion on whether the MOS should at least discourage (preferably deprecate) the practice. (I will notify WT:MOSACCESS, Help talk:Table, Template talk:Vertical header of this debate.) 𝕁𝕄𝔽 (talk) 17:07, 6 December 2023 (UTC)

I have had this thought. It is difficult, because often columns seem to require a lot of text, and it does not feel at all adequate to throw the spacing of the entire table off due to a wordy header.
Regardless, I fully support the general deprecation of this practice, and at least strong discouragement/strong encouragement of other options in the case of disproportionately long headers. Remsense留 18:45, 6 December 2023 (UTC)

Deprecate or discourage use in tables. I personally don't like reading vertical text that is normally horizontal, especially next to horizontal text. It's a bit disorienting and breaks the flow of reading. As far as the issue with turning a desktop monitor (or your head) to read it horizontally, maybe adding {{Tooltip}} to each would help? Jroberson108 (talk) 19:51, 6 December 2023 (UTC)

Tooltips are already proscribed for uses comparable to that of footnotes. The best solution I can think of is having a footnote in a list placed at the bottom of the table, or using a tooltip when it is directly expanding a previously-used contraction or abbreviation Remsense留 19:52, 6 December 2023 (UTC)

I think you're confusing {{Tooltip}} with {{Abbr}}. The latter is for abbreviations (including contractions); the former is for other kinds of annotations that are done as pop-up tooltips (and it does not misuse the underlying <abbr>...</abbr> markup properly used by {{abbr}}).  — SMcCandlish ☏ ¢ 😼  04:08, 7 December 2023 (UTC)

How feasible is it for us to do diagonal (45°) table-headers, nowadays? E.g. css-tricks.com's demo from a few years back (one of many guides). I wonder if that might be a good replacement? -- As a reader, I've often appreciated tables that are easier to read because they are compact (via vertical-headers), but I also agree that 90° text is never ideal, so I hope we can avoid eliminating the practice entirely, and instead come up with an improvement, at least for some instances. -- E.g. looking at a few of the template's uses (of the 905 current uses), and testing removal in a preview, these 2 examples are clearer for me to compare, or fit in a narrow screen better (and 65% of our readers are on mobile) with the compacted version: (imgur links) screenshot 1, screenshot 2. -- In particular, it's often helpful to be able to see the 1st column (or 2) at the same time as reading all other columns, hence whilst screens don't have the same limitations as paper, they do still have usability limitations on extremely-wide tables (any that go past the edge of our screens). Quiddity (talk) 23:33, 6 December 2023 (UTC)

I think I will try to implement a template for this 45° paradigm, for testing purposes. On first glance, the linked demonstration is unworkable, because it requires a manual offset to position the elements after rotation. I don't think that has any general robustness.

(Side note: not to be cantankerous, but the suggestion on Help:Table to use images of text to create a vertical header is incredible, and I really would like to remove it right now.) Remsense留 23:39, 6 December 2023 (UTC)

It's certainly very "old school" and a waste of time and resources (creating images, uploading them to Commons and categorizing them there despite having only one pointless possible use for them, etc.). While if it's done with proper alt text it's not an accessibility problem for the blind, it can pose other usability problems, such as mobile browsers making the images too small to read, etc. I would support removing that poor and obsolete advice, though that is probably a discussion for Help talk:Table.  — SMcCandlish ☏ ¢ 😼  04:08, 7 December 2023 (UTC)

I agree, don't use images in place of text. As for rotating text diagonally 45°, the only two templates I know of are {{Rotate text}} and {{Transform-rotate}}, which both produce the same span and styles although the implementation is different. As you mentioned, you may need to offset the text or adjust the cell's height/width so the text stays within the borders, something I wouldn't expect the average editor to be able to do. You may have responsive issues too. Jroberson108 (talk) 04:15, 7 December 2023 (UTC)

I think this verticalizing practice should be deprecated as a serious usability problem. Just because CSS and HTML make something technically possible to pull off does not magically make it a good idea on Wikipedia. As for "often columns seem to require a lot of text, and it does not feel at all adequate to throw the spacing of the entire table off due to a wordy header", this is a trivial problem much better address by other solutions than vertical headers or other text. The simple fix is to just insert <br /> as needed to break up a long header or other cell entry, and the more robust solution is to use CSS column-width controls.  — SMcCandlish ☏ ¢ 😼  04:08, 7 December 2023 (UTC)

I agree. Perhaps we could also include some guidance on what to do with existing tables that practice this. With less horizontal space on desktop (due to the new style) and on mobile (for years), tables in general should be simple, have few columns (only the relevant ones), these columns should have the shortest headers possible (preferably just a small word) and the cells should have tabular content (numbers or a few short words, occasionally acronyms or symbols accompanied by a legend, but in this case the table should be short). When headings or data are closer to prose (long sentences), it is generally better to represent the information as a nested list rather than a table. --Fernando Trebien (talk) 17:13, 10 December 2023 (UTC)

I think the recommendation of linebreak-separated labels is not ideal. I think the best method might involve the use of either column-width or a key + an {{abbr}}eviated header. Does anyone have any first hand experience on how this technique plays with screen readers and the like? Remsense留 19:42, 10 December 2023 (UTC)

On mobile, there isn't a way to hover on {{abbr}}eviated text. Jroberson108 (talk) 19:51, 10 December 2023 (UTC)

Jroberson108, yes! Thank you. I knew I'd have some obvious blind spot. So, would you say it's always best practice to include a key when using this technique, or should it be avoided altogether? Remsense留 19:56, 10 December 2023 (UTC)

If you are speaking of having a legend for column headers, which the headers themselves are also defining things, then it sounds too complicated and might be problematic for screen readers and the sighted (abnormal practice). The usual recommendation is to consolidate, use precise wording, and break apart overly complex things for simplicity. If the table has long headers, then some rewording of the caption might help reduce the length of the headers. Too many column headers, then spliting the table into two smaller ones might reduce the header lengths like two date columns that require extra text for differentiation vs one in each table called "Date". Jroberson108 (talk) 20:34, 10 December 2023 (UTC)

Jroberson108, of course. I think I should investigate the difficulty of screen readers—but I am not sure a legend is sufficiently abnormal practice if properly presented that it should be avoided for that reason. Moreover, if readers can handle it well, the practice could be recommended as an alternative in the worst-case where mere concision fails, perhaps with the aid of a helper template. Remsense留 21:04, 10 December 2023 (UTC)

Do you have any examples you can link to of tabular data that has column and/or row headers as well as a legend defining the headers? I can't find anything. I can only find legends for charts generated from tabular data. Jroberson108 (talk) 21:22, 10 December 2023 (UTC)

This is the only thing I could find that comes close: Legends in table data. It looks like they moved some column headers to a legend and associated them through colors, not very accessible for some types of color blindness. Jroberson108 (talk) 21:33, 10 December 2023 (UTC)

Whilst I agree that in most cases rotated text probably harms readability of those cells, there are certainly cases where that penalty is fully repaid and more by making the table as a whole much more readable.

This applies in particular where there are many headings and they are substantially longer than the data in the cells below. In extremis, the data may simply be "yes"/"no" or mark/empty. In this case, rotating the headings can reduce the overall width of the table by an order of magnitude even compared with splitting words using <br>, often removing the need to scroll horizontally, with a concomitant increase in comprehensibility.

Martin Kealey (talk) 10:25, 9 February 2024 (UTC)

In such a case, the problem is poor information architecture, generally resolvable by using multiple tables that focus on specific things instead of trying to cram unrelated concepts into one "shotgun" table that is trying to hit every interest target simultaneously.  — SMcCandlish ☏ ¢ 😼  02:32, 21 November 2024 (UTC)

I think {{Vertical header}} should be avoided if other solutions are better overall. But I agree with Martin Kealey that sometimes the benefits outweigh the deficits. And {{Sticky table start}} was created July 26, 2024 after this thread was started. It allows sticky left columns. This helps a lot with wide tables, especially on mobile. I like this judicious use below of vertical headers combined with {{Sticky table start}}. See the full working table here.

List of countries with annual rates and counts for killings by law enforcement officers. With breakdown by police, etc..

Location	Region	Killings	Police	Military	Intel agencies	Other	Population	Rate per 10 million	Year listed	Notes	Source
Afghanistan	Asia	606	49	267	234	56	35,530,000	170.5	2018
Guyana	Americas	12+	12	0	0	0	787,076	152.5	2018

Vertical headers must be used carefully though. I noticed in the above table that if I used an excerpt without anything in those vertical-header columns, then the vertical text would show up partially moved into adjacent header cells when I narrowed my browser window, or looked at it in mobile. Note the "Source" column. And a two-column vertical header ("Intel agencies" above) has to have at least one cell with at least 3 characters. There is discussion at Template talk:Vertical header. --Timeshifter (talk) 10:51, 23 November 2024 (UTC)

Creating policy to support an argument

On Talk:List of winners of the Rotterdam Marathon, I'm having a discussion with another user about the use of abbreviations, tooltips, and legends in this list article. And I just discovered that earlier today this user has added a section to Wikipedia:Manual of Style/Tables in support of his argument. I've already noted this above in the section #Requirement for key? and on the talk page of the list article, but I would like to ask someone with experience writing in the Wikipedia namespace to weigh in and review the added section, because what is happening here doesn't seem right. – Editør (talk) 13:03, 10 January 2024 (UTC)

Hi, that was me. My purpose in adding the guideline, is not to win an argument, but to document what seems to be a strong editor preference. Many keepers of the Manual of Style reject proposals for new guidelines if there haven't been any actual disputes, to minimize length. So I think it's normal for rules to be written to resolve disagreements that bubble up from talk pages, if the same questions arise for multiple articles. Sorry if I was too hasty drafting this new guideline, but based on the practice in featured lists and the discussions that had already happened, it seemed to me that consensus was pretty strong but just not documented. In general, I find bold, revert discuss saves a lot of time for non-controversial questions. I did ask other editors to review the new language by leaving a note above. I'm not in any hurry; we can give the new guidance time to settle and get discussed and tweaked (as is already happening). The new guideline does not propose legend-at-bottom-of-table, which is what I was arguing for, but legend-at-top-of-table, which is what researching featured lists and previous discussions turned up as the dominant practice, for good reasons I hadn't thought of. List of winners of the Rotterdam Marathon might not need a legend at all; other editors have proposed other solutions on its talk page that make the table accessible to all readers. I'm glad more folks have come along to help think this through. If the new guideline language ends up getting rejected, that would be surprising to me, but useful to know so I can more quickly find a desirable solution to such problems in the future. -- Beland (talk) 23:58, 11 January 2024 (UTC)

That's definitely bad form; regardless of the intent, it looks like "creating policy to support an argument", and that's actually covered by a policy or guideline somewhere (I can't remember where; I thought it was in WP:GAMING but it's not). It's always, invariably, without question best to wait until a dispute you are directly involved in has settled out before making rule changes that would affect it, and it's best even then to open a new discussion proposing what to add and why (whether there's a dispute or not). Anyway, most (exception covered below) of that big addition of new material looks sensible to me, after Remsense's intensive copyedit, but we have a formal WP:CREEP and informal WP:MOSCREEP principle that we don't add new "rules" to MoS without there being an actual need for them, defined as necessary to put an end to recurrent disputation over the same style matter or (I would add) to close a wikilawyerable loophole, and sometimes if there's a compelling technical reason for it (e.g. an accessibility problem for screen readers, etc.). "it's normal for rules to be written to resolve disagreements that bubble up from talk pages" has not been broadly/generally true with regard to MoS in in a very long time, or MoS would be 10 times its present length. If it's not addressing a frequent and contentious problem, with a resolution that comes out in a consistent way (or determined by an RfC or something), then it should not be added, because we already have all the MoS we need, and MoS is so bloated that if we don't for certain need a rule, we actually need to not have it. Does any of this new material actually qualify? On to the error: the material on tooltips is simply wrong. We have a {{tooltip}} template for this purpose which does not abuse the <abbr> element, and have for many years. So, the material on that (if kept in any form) would have to be completely rewritten (and MOS:TOOLTIP might also need revision; I haven't checked). In the interim, I'm removing it as simply counterfactual.  — SMcCandlish ☏ ¢ 😼  05:37, 13 January 2024 (UTC)

Thank you for responding to this matter. What I liked about the list's talk page discussion is the idea of creating different solutions for mobile and desktop users (with {{if mobile}} or otherwise), because one solution often doesn't work for both. For the rest I am not planning to get involved in discussing this policy, I'll leave that up to you and others. – Editør (talk) 19:21, 13 January 2024 (UTC)

@Editør: Interested in the {{if mobile}} use cases. "Tell me more!" I've seen a similar interesting use of {{sronly}} (which provoked some controversy from one editor but which I think will eventually be good community-accepted advice about invisible-izing table captions that are simply repetitive of table headers).  — SMcCandlish ☏ ¢ 😼  13:32, 4 February 2024 (UTC)

I don't have much info about this. I've tried to do some things with it, one thing seemed to work but another didn't. – Editør (talk) 12:10, 5 February 2024 (UTC)

Template:Sort under

First 2 tables below use {{sort under}}. Unlike other methods it allows use of the data-sort-type=VALUE attribute (see Help:Sortable tables). And it is easy to use.

Using class=sort-under-center:

Intentional homicide victims per 100,000 inhabitants. From UNODC.

Location	Rate	Count	Year	Region	Subregion
Afghanistan *	4.0	1,613	2021	Asia	Southern Asia
Anguilla	28.3	4	2014	Americas	Latin America and the Caribbean

Using class=sort-under-right:

Intentional homicide victims per 100,000 inhabitants. From UNODC.

Location	Rate	Count	Year	Region	Subregion
Afghanistan *	4.0	1,613	2021	Asia	Southern Asia
Anguilla	28.3	4	2014	Americas	Latin America and the Caribbean

There is no class=sort-under-left yet. But here is a table with left-aligned sorting icons using a different method. Unfortunately it has borders just above the sorting icons:

Intentional homicide victims per 100,000 inhabitants. From UNODC.

Location	Rate	Count	Year	Region	Subregion
Afghanistan *	4.0	1,613	2021	Asia	Southern Asia
Anguilla	28.3	4	2014	Americas	Latin America and the Caribbean

My questions for this talk page:

• What is your preference for where the sorting icons are placed?
• Should there be only one preference allowed? For example via class=sort-under
• Would there be multiple preferences allowed? For example:

class=sort-under-center

class=sort-under-right

class=sort-under-left

class=sort-under - For the most popular choice, for ease of use. Its duplicate would still work.

• Which ones?

I now think we should only allow center alignment. To avoid unnecessary arguments and slow-going edit wars.

No matter which alignment we choose now for class=sort-under, if we change our minds as a group later, it is easy to change it in the CSS. So all tables using class=sort-under will change to the new choice. --Timeshifter (talk) 11:57, 4 February 2024 (UTC) Additions, changes, and strikeouts: --Timeshifter (talk) 09:47, 5 February 2024 (UTC)

• Prefer the second (right) by default, but would probably use the first (centered) for a table with a bunch of centered data in it. These control widgets are not content/data and should be "out of the way" as much as possible, generally speaking. Centering them by default has an inappropriate emphasizing effect, at least for typical tables with left-jusified material. Left alignment of the controllers is worse than useless (exept in an RTL language). Allow at least right and center to be parameter-specifiable, but default right.

  General commentary from another thread about this: I would suggest that more options are better, but only up to a point (KISS principle; and the observation than a left-aligned version of such a control widget would not be of use in an LTR language is probably correct). Concision in class, parameter, and other names is generally better (may be pertinent to both the template parameter code and the TemplateStyles material), but also just up to a point (they need to still be intelligible). Default behavior of the template should probably be what best matches default appearance of sortable wikitable controls (principle of least astonishment; here that would be right alignment). If some particular variant is expected to be needed over and over again, make a simple template wrapper that does that version with a shorthand name that doesn't require lots of parameter futzing.  — SMcCandlish ☏ ¢ 😼  13:21, 4 February 2024 (UTC)

SMcCandlish. What do you think of having these 3 choices?:

class=sort-under-center

class=sort-under-right

class=sort-under - with it being the popular choice so far: right.

I want to use class=sort-under because it is easiest to remember. If I remember the template name, then I just add a dash and I then have the class name. That is how most of the table templates I use work:

{{static row numbers}}{{sticky header}}{{sort under}}
{| class="wikitable sortable static-row-numbers sticky-header sort-under"

And it is easier for less experienced table editors than me. The pattern is obvious.

--Timeshifter (talk) 13:39, 4 February 2024 (UTC)

Sure. Having a shorter-name syntax to get the result won't break anything.  — SMcCandlish ☏ ¢ 😼 

What do you mean by "Allow at least right and center to be parameter-specifiable, but default right."? A class has to be added to use this template. Does "default" mean sortable without the use of this template? Jroberson108 (talk) 16:39, 4 February 2024 (UTC)

I mean that if someone just uses a bare {{sort under}}, it should default to including what above is being called class=sort-under-right (with a proposed shorthand alias of class=sort-under). People should not have to manually add a class when doing something by default would be sensible. And for editors who are not CSS experts, it would be sensible to support a simple template-parameter syntax like {{sort under|center}} or {{sort under|align=center}} or {{sort under|center=yes}} or someting to that effect. And with a right version that can be explicitly specified without breaking anything.  — SMcCandlish ☏ ¢ 😼  23:45, 4 February 2024 (UTC)

I see, adding a template parameter in this way won't be possible since the transclusion has to be above the table element to include the styles, then applied to a table through a class. If the transclusion includes the table start wiki text, then it might, but this introduces all kinds of complications. Jroberson108 (talk) 00:00, 5 February 2024 (UTC)

Oh well. It was an idea.  — SMcCandlish ☏ ¢ 😼  00:48, 5 February 2024 (UTC)

SMcCandlish. Just to be clear, creating a class=sort-under that right-aligns the controllers is not a problem. I think even I (with my limited understanding of template CSS) could add the code to the CSS page of the template to make it happen. class=sort-under-center and class=sort-under-right would still work too. --Timeshifter (talk) 06:34, 5 February 2024 (UTC)

@Timeshifter: If your question about adding a sort-under class that duplicates another class's styles is relevant to this RfC, then it should be added to the top with the other questions for equal consideration instead of having what appears to be a side conversation with a select individual. You already requested it on the template's talk page, so I'm not sure why you didn't add something you wanted to the questions? I may be opposed to it mainly because it adds an extra 16 CSS selectors (thus far) to Template:Sort under/styles.css and adds ambiguity for what appears to be a very minor and debatable improvement, but I follow consensus.

Also, I wouldn't decide on your own that there is no problem, especially since you have, as you said, a "limited understanding of template CSS". There are other factors you may not be aware of. When adding styles to MediaWiki:Common.css, there is a restriction of only adding essential styles for good reasons, which can also be applied to template styles that have some leniency. Duplicate styles can be counted as non-essential, which is generally a bad practice in Web development/design. If this is considered an improvement and should be apart of this RfC, then I can check to see if the practice is acceptable on template styles.

Are there any other templates that duplicate styles like this for something like a "popular choice" or is this a first? Jroberson108 (talk) 09:06, 5 February 2024 (UTC)

Inquired at Wikipedia talk:TemplateStyles#Duplicate styles to first see if this practice is acceptable without causing any unforeseen problems. Jroberson108 (talk) 09:33, 5 February 2024 (UTC)

I added the question to my original post. I replied at Wikipedia talk:TemplateStyles. To summarize, it is not a problem to add it to this template. I know enough template CSS to know that. And this template is not the huge Common.css file. --Timeshifter (talk) 10:15, 5 February 2024 (UTC)

You're welcome to your opinion. I didn't ask if it could be done, which is obvious. I asked if it's an acceptable practice on Wikipedia's template styles. Jroberson108 (talk) 10:49, 5 February 2024 (UTC)

You and I know it is obvious that it can be added to the template. But your previous post was not clear about that in my opinion. For other readers. So I am glad that you have clarified that. --Timeshifter (talk) 11:00, 5 February 2024 (UTC)

Ah, so this post was prior to the other. Jroberson108 (talk) 11:02, 5 February 2024 (UTC)

@Timeshifter: What about this? Are there any other templates that duplicate styles like this for something like a "popular choice" or is this a first? If some exist, then at least there is a live example that might be referenced in that other discussion. Jroberson108 (talk) 11:20, 5 February 2024 (UTC)

We don't need permission to add class=sort-under using the most popular alignment choice. There is no rule against it. In my experience with many years of table editing, and writing large parts of Help:Table and its subpages, people editing tables want the simplest coding, and don't want to read template document pages. Most people just copy what they see working on other tables. Only if there is a problem do most people go to the doc page, and look at the parameters some templates offer. --Timeshifter (talk) 11:46, 5 February 2024 (UTC)

Seriously, it's a simple yes or no question. If yes, which ones. Jroberson108 (talk) 11:53, 5 February 2024 (UTC)

I don't know. And if there aren't any tables now doing it, it doesn't matter. There is no rule against it. --Timeshifter (talk) 12:04, 5 February 2024 (UTC)

So not sure. I haven't seen any either. Jroberson108 (talk) 12:12, 5 February 2024 (UTC)

Dunno either. From my personal perspective, I don't see any issue we need to care about in having both a class=sort-under-right and a class=sort-under that do the same thing, the latter being a shorthand form. The only issue I could see arising is if we settled on right as the default (and that's clearly going to happen), then if class=sort-under were later changed to be equivalent to class=sort-under-center, then a whole bunch of tables would suddenly change (because people are apt to prefer the shorter syntax) and this would piss people off. But that's ultimately not any different from making any other sudden display change to template output. I.e., there's nothing unique about the matter.  — SMcCandlish ☏ ¢ 😼  00:14, 6 February 2024 (UTC)

@SMcCandlish: Good point that if the new class is added, the alignment is expected to remain unchanged. I get the sense from your responses that you don't care if it is added? So a more pointed question is, are the current descriptive class names and the documentation sufficient for using this template or does this new short class need to be added to improve the template's usage according to Timeshifter's or other reasons and why? Jroberson108 (talk) 02:04, 6 February 2024 (UTC)

SMcCandlish and Jroberson108. I doubt that the default alignment will ever change. But if it does happen, from my experience with table editing I believe very few people will care at all if the sort icons go from right-aligned to center-aligned. They will not even notice it for the most part. Editors come and go on many pages with tables. On a few pages with dedicated table editors they might notice it. I doubt they will be pissed. More likely just curious. If interested enough they will go to the template page and talk page. They will probably have the same reaction I had.

I mean look at me. My initial support was for center-aligned controllers. Now I don't care. I was surprised that people wanted them right aligned. But since it has more support, then I want to make the reader happy. I think most table editors want to make the reader happy. So if they see that more people prefer center alignment they will support it. But for now it looks like right alignment is the more popular. --Timeshifter (talk) 09:12, 6 February 2024 (UTC)

@Timeshifter: Since we now know, as of now, that "right" is preferred, and you believe few people will care or even notice if an alignment changes on an ambiguous class name, are you OK with changing {{sorting row}} from "center" to "right" aligned? Obviously, time is needed to gauge responses, given that most of its transclusions weren't done by a few editors. I would never recommend changing something that is or should be documented and used expectantly (sometimes only described in the template's talk or a separate help page), regardless of how people might respond to the change. Bug fixes and deprecations are a different matter. Obviously {{sorting row}}'s documentation is sub-par, but in its entirety (examples and known issues) it at least revolves around center alignment. Templates have been described and with examples on help pages and other templates. Fixes are sometimes added to templates so that it works with other things, which I would be extremely pissed if I had to refix something that took me days to thoroughly test on multiple skins and devices for some minor reason as a preference change. As an example, this template fixes its usage with {{static row numbers}} (see bottom of Template:Sort under/styles.css). Note that the styles have fixes for many skins, which I expect those related global skin styles not to change without good reason. I spent days fixing the borders on Template:Static row numbers/styles.css so it worked correctly and on different skins on multiple browsers/devices and the Android mobile app. Template:Sticky header/styles.css has a fix for smaller screens (technically Minerva skin and in need of more fixes per its talk) and border fixes for various browsers. Template:COVID-19 pandemic data/styles2.css has fixes for the same things as well as the sticky gadget and some print styles. It's just bad practice to change something that is expected for a minor reason. Jroberson108 (talk) 17:32, 6 February 2024 (UTC)

For my part, it seems reasonable to have sort-under and sort-under-center as a centered variant of that, and maybe also a sort-under-right as a more specific name of the former, and they can just be specified inline at the same time: .sort-under, .sort-under-right { ... } having the shorter name available would be nice, though the world would not end without it.  — SMcCandlish ☏ ¢ 😼  20:20, 6 February 2024 (UTC)

It still sounds like you have a neutral opinion, which is perfectly fine if that's what you want. Jroberson108 (talk) 23:08, 6 February 2024 (UTC)

SMcCandlish. Another possibility that I am OK with is having only 2 classes (so no duplication): class=sort-under and class=sort-under-center. --Timeshifter (talk) 23:15, 6 February 2024 (UTC)

Works for me, too. I'm not sure I'm "neutral" on this, so much as not wanting to have to specify sort-under-right if sort-under will do. However, I'm aware that various people are OCD in ways different from me, and may grit their teeth about the lack of a short-under-right that is specific. It is completely harmless to give them that longer and more detailed class name to get at the same result as the short version. It's certainly not worth all this argument. People get rankled when they lack options. "Somone gave me a choice?! To hell with that!" is not a common reaction, in any sphere.  — SMcCandlish ☏ ¢ 😼  02:29, 7 February 2024 (UTC)

Sure, {{sorting row}} can be changed to right-aligned. It is very easy to do. That template has only had one real editor. I adjusted the line height later on. Guarapiranga created it. There have been only 2 posts on the talk page (both from me). Now archived. So we could leave a message on the talk page about us agreeing to change it to right-aligned. Maybe wait a week to see if Guarapiranga wants to give some feedback. He hasn't been editing much the last year or 2. I have pinged him about his subtemplates we put up for deletion. He never commented. We should mark that template as deprecated since it can't work with data-sort-type=VALUE. We should list {{sort under}} as a suggested replacement. --Timeshifter (talk) 21:12, 6 February 2024 (UTC)

• Right aligned, as previously mentioned at Template talk:Sort under, because that is the normal location where sortable and other spreadsheet applications put it. Left aligned seems usable only on sites that have right-to-left text like Arabic. Center aligned is too prominent for something that isn't content, and distracts my reading experience when going from the header to its data. On wider columns, right aligned arrows are far less distracting than on narrower columns. Jroberson108 (talk) 13:35, 4 February 2024 (UTC)

  I'm fine if both right and center remain for individual preferences, but mine is for right. They were added because both currently exist on separate sorting rows, which this template is meant to replace to fix issues. Alignments are given equal weighting with no assumed preference or popularity, and the class names clearly describe their alignments with no added ambiguity or duplication that class sort-under might have if multiple alignments exist. If only one alignment exists, then the shorter class name is preferred. Jroberson108 (talk) 23:48, 4 February 2024 (UTC)

  No on adding an extra sort-under class. It introduces ambiguity, especially if seen used in an article where, if you are unfamiliar with the template, you cannot tell right away that other alignments are possible without needing to reference the documentation. The sort-under-right and sort-under-center classes clearly and sufficiently describe their alignments and, when only one is seen in code, hints at other alignment options at first glance without needing documentation, just like sortable's sorttop and sortbottom classes, and {{Table alignment}}'s classes. It is unlikely that someone is going to have any trouble using the more descriptive class names if all they are doing is copying and pasting code. The documentation has two easy to understand options, so it's already clear without the added complication. I feel duplication is a bad practice, which would add 16 additional CSS selectors (thus far) to the styles at Template:Sort under/styles.css. If adding it offers any improved usage of the template, it's very minor and debatable since someone is either copying code, already familiar with the template, or looking at the easy-to-understand documentation. Not worth the overhead, added ambiguity, and, as SMcCandlish pointed out, "pissing people off" if the expected alignment of sort-under changes later on. Jroberson108 (talk) 05:10, 6 February 2024 (UTC)

  Please see my response to SMcCandlish above. Here is the diff. Another point: I believe class=sort-under will cause improved usage of the template because it is easy to remember that the class name is the same as the template name except for the addition of the dash. So people don't just copy. They remember. Same pattern as several of the other popular table templates. Like the template I created: {{sticky header}} which uses class=sticky-header. In the 4 months it has been around it already has more transclusions than the previous sticky header template that was more difficult to use and remember. --Timeshifter (talk) 09:37, 6 February 2024 (UTC)

  Ugh, you brought up {{sticky header}}. It's increased transclusions don't mean anything in regard to how the classes are named. It deals with the lack of documentation, lack of supporting examples on other help pages, and/or its complex use requiring a template property. Also, most of those transclusions could have been done by one or two editors, possibly replacing its predecessors usage in articles decreasing the other's transclusions, so not easy to gauge based on one metric without actually asking the editors that used it, which one or two isn't much to go off of.

  Those other templates you refer to only have a single "main" class and may have some optional "add-on" classes (like {{static row numbers}}). They don't have any classes that duplicate another's styles, which adds more to remember, even if someone is selective in what they want to remember and not remember. In these cases, I believe naming the class as the template (dashed) is perfectly acceptable. Note, not all templates have classes named similarly to the template name such as the two mentioned next.

  Like {{table alignment}} and {{row hover highlight}}, this template has multiple "main" classes, and similarly shouldn't have identically styled classes, which adds more to remember and unnecessary complexities. Imagine if {{table alignment}} had a default class set to "left" alignment and you weren't familiar with the other classes. You wouldn't intuitively know that other alignment options exist or what to change it to if you want defaultright without the documentation. You could if it was originally defaultleft, just change "left" to "right", which is so much easier. The same applies to this template, as I previously mentioned: "hints at other alignment options at first glance without needing documentation".

  {{Sticky header}} is not a good example, but does exemplify why its documentation is far more important than someone's memory of a single use case. Not to rehash its doc and talk. The sticky-header class only works with sortable, shouldn't be used with sortable's sorttop class, and requires adjustments if there are subsections. When you can't use the template in this way, you alternatively have to add a different sticky class to make exactly one row top-sticky, added to the row instead of the table (different implementation). It's new and there could be other unknown issues. Those are some very strict, complex, and hard-to-remember usage cases compared to all the other templates I've seen, even if you are only using the class that is named similar to the template. Not to personalize or offend, but you already demonstrated this in Template_talk:Sticky header#Why does this not work on this table?, and, as I recall, made the "It only works on sortable tables." warning more prominent in the doc lead so you wouldn't forget. Per its talk, that template is still in need of fixes that can change both the class name and implementation such as deprecating the old row sticky class and applying new table classes to target the first or second row so that styles similar to sticky-header can be applied to the table as a whole to fix other things like borders. If fixed, it would have multiple "main" classes that don't have identical styling, for example new sticky-header-row1, etc., which in this case are temporary depending on WikiMedia fixes (ex. move non-sortable headers to the thead element). Since they don't duplicate, its acceptable to name the non-temporary "main" class the same as the template (dashed).

  The documentation is meant to describe up-to-date usage and issues, and should be relied upon if you temporarily forget or have issues. Referencing documentation is a perfectly normal and acceptable practice, and should be relied upon more so than any explanations and examples about it that might be partially added to other help pages that can become outdated. Jroberson108 (talk) 21:21, 6 February 2024 (UTC)

  SMcCandlish and Jroberson108. I am OK with just having class=sort-under and class=sort-under-center. Then there is no duplication.

  I created {{sticky header}} specifically for ease of use. I picked the class names specifically for ease of use. And even before you did your wonderful tweaks of it, it was becoming popular fast. Its main flaw was that it didn't have header borders in Firefox. But even with that flaw people loved it. There were other minor flaws, but they didn't prevent people from using it either. It is now up to almost 500 transclusions in 4 months. It works well on almost any sortable table. When people have problems, then they come to the template doc. The other sticky header template has been around much longer, but has less transclusions. And its rate of additional transclusions has nearly stopped. I linked to {{sticky header}} from its doc page. --Timeshifter (talk) 22:52, 6 February 2024 (UTC)

  You don't need to type in all bold for all your "I" statements. I am not attacking that template, you, or your efforts. I too have put in a lot of effort to fix that template, which is better than the older template and was a great idea that you had and implemented. Moving on from an I/You conversation. Thanks for acknowledging my efforts too, which you've done elsewhere. [Unrelated] I haven't fully decided if I'm going to take another crack at it. Jroberson108 (talk) 23:25, 6 February 2024 (UTC)

  @SMcCandlish, Timeshifter, and Isaidnoway: Thanks for the suggestion on getting rid of the duplication issue. I think I can agree with having sort-under and sort-under-center classes, now that we know right is preferred, although my "ideal" preference still remains the current classes for the intuitive reasons mentioned above. Not sure if this RfC should remain open for more comments or closed and moved to the relevant template talk page?

  Let me know and I can change the styles, tests, and doc. Jroberson108 (talk) 23:42, 6 February 2024 (UTC)

  Thanks. It's all fine by me. --Timeshifter (talk) 23:50, 6 February 2024 (UTC)

  I mistakenly thought one opinion was from another user. So basically Timeshifter and myself are only in favor of this. I guess I need to wait for at least one of the others to respond for majority, assuming the fourth editor isn't strongly opposed (not likely). Jroberson108 (talk) 00:15, 7 February 2024 (UTC)

  Those two options are fine by me, though I do not oppose .sort-under, .sort-under-right { ... } so the more specific version is available. I tend to prefer that, since it'll make a certain kind of OCD happier, and people unfamiliar with the template's guts can also just guess that sort-under-center can be changed to sort-under-right and be correct. But it's not something I would push strongly for, especially if just having .sort-under { ... } and .sort-under-center { ... } makes the dispute end.  — SMcCandlish ☏ ¢ 😼  02:34, 7 February 2024 (UTC)

  @SMcCandlish: Great point that having both descriptive classes with the short class allows for intuition when the short class isn't used, and placates some OCDs. If only something like that were said earlier, granted this isn't your standard RfC. So, like SMcCandlish, I am more in favor of just adding sort-under (right aligned) to the current descriptive classes (duplication for more intuition) and OK with the current proposal. Timeshifter, since you proposed both, which do you prefer more? Jroberson108 (talk) 04:30, 8 February 2024 (UTC)

  I like having the duplication if it makes more people happy. But not if it causes real problems. I copied the template text and the CSS text to one Notepad file. It is 3.6 KB total. So adding the CSS for the duplicate class probably will not add more than a kilobyte. --Timeshifter (talk) 11:37, 8 February 2024 (UTC)

  Shouldn't add anywhere near that much. There is no reason to duplicate the entire block of code, just change the opening .sort-under { ... to .sort-under, .sort-under-right { ... so the same block of CSS is triggered by either class name.  — SMcCandlish ☏ ¢ 😼  15:13, 8 February 2024 (UTC)

  The un-minified file size has never been a concern for me, so please don't misunderstand. I mentioned it once in a none WP:TALKFORK discussion at Wikipedia talk:TemplateStyles#Duplicate styles, and indirectly referenced it in this as a possible unknown factor. That's for them to decide for the template styles in general, which might help establish acceptable practices. Jroberson108 (talk) 19:16, 8 February 2024 (UTC)

  @Timeshifter and SMcCandlish: The new class has been added and tested. FYI: Although we minimized one intuitive issue, the other of not knowing there are other alignments with sort-under still exists, which is only fixable if we only allow one alignment or remove sort-under. Jroberson108 (talk) 05:04, 9 February 2024 (UTC)

  Also, I'm more than "OK" with the new class now that more and more editors are preferring it's right alignment, less likely to change. So I see that issue as minimal. Jroberson108 (talk) 06:52, 9 February 2024 (UTC)

• My preference is the default position not using this template. And No, there should not be only one preference allowed, and if an article already has an existing sort-under, it shouldn't be changed because of an editor's personal preference. Isaidnoway (talk) 14:41, 4 February 2024 (UTC)

Isaidnoway. For why this template was created by Jroberson108, see some of the reasons at Phab:T35249, started in 2011 by TheDJ.

It helps with narrowing some tables so that they fit better in cell phones. And in contrast to {{sorting row}} it does not create a separate row of sorting icons. So {{sort under}} does not annoy people using screen readers. --Timeshifter (talk) 15:20, 4 February 2024 (UTC)

My screenreader had no problem reading any of those example tables above, regardless of where the sorting icons were placed, so they were all accessibility compliant, in regards to the sorting icons. However, not that you asked about it in the RfC enquiry, screenreaders can't read abbreviations like UNODC, so I was left clueless (using my screenreader), to know that it stood for United Nations Office on Drugs and Crime. Isaidnoway (talk) 21:58, 4 February 2024 (UTC)

@Isaidnoway:, thanks for verifying the accessibility. Just wondering if your screen reader had to also "go past blank cells" in the third table example (left aligned), which is mentioned in the first note at Help:Sortable_tables#Sorting buttons in a separate row, or that "empty table headers complicate keyboard navigation and do not give meaningful screen reader output", mentioned below that note. Jroberson108 (talk) 01:33, 5 February 2024 (UTC)

@Isaidnoway:

As Jroberson108 said please look at the 3rd table (left-aligned) above. It has a separate sorting row. That means there are borders above the controllers.

{{sorting row}} (used in the table below) uses a different method. It is a template that creates a separate sorting row. It only allows center-aligned controllers.

An editor who uses a screen reader said that it was a problem here. He said: "It's still very readable with the empty/clickable row, it's just more annoying to have to go past blank cells; I know they can occur in other circumstances, too. Perhaps this is one of these cases where a minor accessibility improvement loses out for now to better display on screens."

Intentional homicide victims per 100,000 inhabitants. From UNODC.

Location	Rate	Count	Year	Region	Subregion
Afghanistan *	4.0	1,613	2021	Asia	Southern Asia
Anguilla	28.3	4	2014	Americas	Latin America and the Caribbean

--Timeshifter (talk) 07:06, 5 February 2024 (UTC)

• @Jroberson108 and Timeshifter: – Here is the audio from my screenreader, so you can hear it for yourself. The first audio file is from the three tables on this page, and the second audio file is from the Help page which Jroberson108 linked to above. Honestly, I have no idea what that editor meant by: It's still very readable with the empty/clickable row, it's just more annoying to have to go past blank cells. The only thing I can think of, would be maybe in an article like this: List of Mayhem Festival lineups by year, where there are some "blank cells" in each row, but it's unclear to me what that editor is talking about in regards to accessibility and table sorting. ¯\_(ツ)_/¯

As you can hear, there is no pause, glitch, lag or interference when the screenreader gets to that "separate sorting row", because there is no content/data in that "row" for the screenreader to process, it is only icons, which technically require human interaction by "clicking on them" to sort the table accordingly. Screenreaders can not read, or manipulate/interact, with sort up/down icons, so the screenreader automatically goes to the next row. Hope this helps. Isaidnoway (talk) 11:55, 5 February 2024 (UTC)

Screenreader audio

@Isaidnoway: Yeah, no pause. I wonder if it's a different screenreader or older one, kind of like how browsers render slightly differently. Anyways, thanks. Jroberson108 (talk) 12:09, 5 February 2024 (UTC)

@Isaidnoway: Thanks for the audio files. That quote is from April 2020. So maybe screen readers no longer pause at sorting rows. Or maybe Graham87 had his screen reader set to announce rows and/or columns. What screen reader are you using?

Screen readers shouldn't have a problem with this new template since there is no row added. The controller is in the same column header cell as the header text. --Timeshifter (talk) 12:25, 5 February 2024 (UTC)

From previous interactions with Graham87, I think he uses JAWS (screen reader) which is $95/year (must be renewed every year) or a one-time purchase price of $1100. Chrome and Firefox both have free screenreader extensions, which work fine for my purposes. I prefer the Firefox extension out of the two. But generally speaking, screenreaders of any type can have issues reading tables when they are not properly formatted, see my user page for some audio examples of tables where the <br /> tags were used to emulate rows (I've since fixed them). Off topic: another issue for screenreaders is when only flag icons are used, like seen here: recent signings or tables that use colors to convey information like seen here: results. Screenreaders can't read flag icons or colors, so those tables are not accessibility compliant.

Getting back to these tables though, I'm not seeing or hearing any accessibility issues with the formatting of these tables, in regards to the different layouts for the position of the icons. Honestly, I don't think most editors care where the icons are located when they are creating a sortable table and just use the default; class="wikitable sortable". Isaidnoway (talk) 13:19, 5 February 2024 (UTC)

Isaidnoway and all. Please see: Help talk:Table#Help:Table/Accessibility or Help:Accessibility of tables. --Timeshifter (talk) 14:04, 5 February 2024 (UTC)

@Isaidnoway: A new option was recently added and I was wondering if you want to comment on it so it has a fair consideration. Far from a proper RfC, so sorry. To summarize, the current consensus is leaning towards keeping the current two classes: sort-under-center and sort-under-right, with a preference for "right", which both SMcCandlish and I clearly see. The new option that Timeshifter wants is to add a third shorter class name called sort-under that would have identical styling with the preferred style (right). Basically two classes align right and one aligns center. He added his reasons above, which is mainly to make the template easier to use. So, the same pointed question I asked SMcCandlish. Are the current descriptive class names and the documentation sufficient for using this template or does this new short class need to be added to improve the template's usage according to Timeshifter's or other reasons and why? Jroberson108 (talk) 02:43, 6 February 2024 (UTC)

Isaidnoway. An update. I now am also OK with just having class=sort-under and class=sort-under-center. Then there is no duplication. See talk higher up. --Timeshifter (talk) 23:05, 6 February 2024 (UTC)

@Isaidnoway: Thanks for your definitive answer. Jroberson108 (talk) 23:14, 6 February 2024 (UTC)

@Timeshifter:, I just realized I misread this as Isaidnoway's opinion. Hopefully Isaidnoway is in agreement. See my comments above. Jroberson108 (talk) 00:05, 7 February 2024 (UTC)

Dope template. As long as both center and right are options, I am fine with either default. "class=sort-under and class=sort-under-center" sound good. On Wikipedia's mobile app for android, the {{sorting row}} template creates a weird blank row. (Much of the complex stuff in articles is not rendered in the Android app.) This new template just looks like a regular table on the Android app. Right as a default is probably what most users will expect, since it's the standard position for a sortable table. I think it's important to have center as an option, so that sorting row usage can be gracefully migrated to this template. Rjjⁱⁱⁱ (talk) 03:59, 8 February 2024 (UTC)

@Rjjiii: Thanks for the compliment. Glad to have someone else check the Android app. Thanks for indicating (right allow center, sort-under class OK), which matches consensus. Yeah, center was added because of {{sorting row}}, but should be available otherwise. Jroberson108 (talk) 04:41, 8 February 2024 (UTC)

@Rjjiii: To clarify, the above proposal you responded to was the latest of a few. This discussion was to decide (summarized based on discussion):

1. Which alignments? (consensus and on template: right, center, no left)
2. Preferred alignment? (consensus: right)
3. Should a new sort-under class be added with preferred alignment (right)? (consensus: OK)
4. How the new class should be added (extra or replace sort-under-right class)? (almost finalized)

Jroberson108 (talk) 05:51, 8 February 2024 (UTC)

Gotcha, point 4 doesn't seem like a huge deal. My slight preference would be to have only "sort-under" because otherwise you could have identical tables on a page with varying classes. Having a duplicate "sort-under-right" wouldn't bother me at all though. There's no technical barrier to add an extra class, and if any editor is asking for it I wouldn't begrudge them. Good luck, Rjjⁱⁱⁱ (talk) 03:48, 9 February 2024 (UTC)

@Rjjiii: Gotcha, only allow right and "sort-under" class for uniformity. #4 was resolved to add "sort-under" instead of replacing "sort-under-right" to minimize the intuitive issue of changing "center" to "right" in the class name. The other intuitive issue of not knowing there are other alignments with "sort-under" still exists, which is only fixable if we only allow one alignment or remove "sort-under" and only use the descriptive classes.

BTW, the new class has been added to the template, so feel free to check it out again. Thanks for your input. Jroberson108 (talk) 04:45, 9 February 2024 (UTC)

Thanks. Woohoo! I added the first use of the template in article space. See the main table here:

• List of countries by intentional homicide rate#By country, region, or dependent territory

Note also that the total vertical height of the sticky header is now a little less than before. That is good for cell phones. Especially when there is more than one line of text in the header. Every little bit less is helpful. This country table header has only line of text by having the rate info in the caption. Moving stuff to the caption is a good way to lower the number of lines in table headers. --Timeshifter (talk) 14:13, 9 February 2024 (UTC)

@Timeshifter: Thanks for the compliment. Yes, you're the first. :) Also note, when {{sticky header}} uses {{sorting row}} with a "sorttop" row, you have to make a single row top-sticky to exclude sorttop (after sorting), which the sort arrows aren't top-sticky. With this template, the arrows are top-sticky (same cell). Jroberson108 (talk) 16:32, 9 February 2024 (UTC)

• No strong preference. I would probably use every option depending on whether the table is short or long, whether moving the arrows would let the table squish, or how far the arrows might appear from the column name. Also the table content itself being center or right-aligned makes a difference.

I might put the arrows in the

center-right on this table: [4];

bottom-right on this table: [5] and

bottom-center on this table: [6]

Cheers

Wizmut (talk) 02:52, 12 February 2024 (UTC)