View source for Wiki143 talk:Manual of Style/Tables

{{Talk header}}
{{WikiProject banner shell|
{{WikiProject Manual of Style}}
}}
== 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. [[User:Erik|Erik]]&nbsp;([[User talk:Erik|talk]]&nbsp;&#124;&nbsp;[[Special:Contributions/Erik|contrib]]) <sup>([[Template:Reply to|ping me]])</sup> 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? [[User:CUA 27|CUA 27]] ([[User talk:CUA 27|talk]]) 23:18, 5 January 2019 (UTC)

::{{ul|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 [https://imgur.com/a/I7L2BG8 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. [[User:Erik|Erik]]&nbsp;([[User talk:Erik|talk]]&nbsp;&#124;&nbsp;[[Special:Contributions/Erik|contrib]]) <sup>([[Template:Reply to|ping me]])</sup> 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 <s>actor/actress</s> 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, –[[User:Davey2010|<span style="color: blue;">'''Davey'''</span><span style="color: orange;">'''2010'''</span>]]<sup>[[User talk:Davey2010|<span style="color: navy;">'''Talk'''</span>]]</sup> 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? --[[User:Gonnym|Gonnym]] ([[User talk:Gonnym|talk]]) 20:39, 7 January 2019 (UTC)
::{{ec}} 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. [[User:Erik|Erik]]&nbsp;([[User talk:Erik|talk]]&nbsp;&#124;&nbsp;[[Special:Contributions/Erik|contrib]]) <sup>([[Template:Reply to|ping me]])</sup> 20:47, 7 January 2019 (UTC)
:::Hi [[User:Gonnym|Gonnym]], As far as I know no ?, The only best solution or compromise I have is simply to remove the rowspans, Thanks, –[[User:Davey2010|<span style="color: blue;">'''Davey'''</span><span style="color: orange;">'''2010'''</span>]]<sup>[[User talk:Davey2010|<span style="color: navy;">'''Talk'''</span>]]</sup> 21:07, 7 January 2019 (UTC)
:If the use of vertical alignment would help with mobile (and specifically with the <code>wikitable</code> class), then it should probably be submitted to [[Help:Bug reports|Phabricator]] instead of piecemeally added. --[[User:Izno|Izno]] ([[User talk: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. [[User:Erik|Erik]]&nbsp;([[User talk:Erik|talk]]&nbsp;&#124;&nbsp;[[Special:Contributions/Erik|contrib]]) <sup>([[Template:Reply to|ping me]])</sup> 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 {{em|everywhere}}. --[[User:Izno|Izno]] ([[User talk: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. [[User:Erik|Erik]]&nbsp;([[User talk:Erik|talk]]&nbsp;&#124;&nbsp;[[Special:Contributions/Erik|contrib]]) <sup>([[Template:Reply to|ping me]])</sup> 14:56, 9 January 2019 (UTC)
:::::If it's a website style question, yes, actually, 'banning' or at least strongly discouraging any use of [https://stackoverflow.com/questions/2612483/whats-so-bad-about-in-line-css 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 {{em|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 [[:phab:|Phabricator]]). But, I don't think you do have consensus that this is unequivocally a good change for all users of the mobile platform. --[[User:Izno|Izno]] ([[User talk: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 [https://github.com/quiddity-wp/wikimedia-style-tweaks/blob/master/tables_vertical-align_top_test.user.css 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. [[User:Quiddity|Quiddity]] ([[User talk: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? ~ [[User:Arkhandar|<b style="color: #8cc5ff;">''Arkhandar''</b>]] <sup>([[User talk:Arkhandar|<b style="color: #b3b3b3;">''message me''</b>]])</sup> 11:01, 21 January 2019 (UTC)
:{{ping|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. --[[User:Izno|Izno]] ([[User talk:Izno|talk]]) 20:41, 21 January 2019 (UTC)
::{{ping|Arkhandar}} You must both add new text pinging someone and re-sign. Not one or the other. --[[User:Izno|Izno]] ([[User talk:Izno|talk]]) 00:56, 22 January 2019 (UTC)
:::{{Reply to|Izno}} Done! Wouldn't expect any less strictness from the MOS community :D ~ [[User:Arkhandar|<b style="color: #8cc5ff;">''Arkhandar''</b>]] <sup>([[User talk:Arkhandar|<b style="color: #b3b3b3;">''message me''</b>]])</sup> 10:39, 22 January 2019 (UTC)

:{{Ping|Erik|CUA 27|Davey2010|Izno|Quiddity}} ~ [[User:Arkhandar|<b style="color: #8cc5ff;">''Arkhandar''</b>]] <sup>([[User talk:Arkhandar|<b style="color: #b3b3b3;">''message me''</b>]])</sup> 10:38, 22 January 2019 (UTC)

::I've tried skimming the discussion [[WT:VG#Table formatting questions in game studio lists|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? [[User:Erik|Erik]]&nbsp;([[User talk:Erik|talk]]&nbsp;&#124;&nbsp;[[Special:Contributions/Erik|contrib]]) <sup>([[Template:Reply to|ping me]])</sup> 15:00, 22 January 2019 (UTC)

:::{{Reply to|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.
:::{| class="wikitable plainrowheaders"
|+ Alleged "incorrect" example
|-
! scope="col" | Year
! scope="col" | Title
! scope="col" | Role
! scope="col" class="unsortable" | Notes
|-
| align="center" | 1961
! scope="row" | ''[[Barabbas (1961 film)|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.
:::{| class="wikitable"
|+ Alleged "correct" example
|-
! scope="col" | Year
! scope="col" | Title
! scope="col" | Role
! scope="col" class="unsortable" | Notes
|-
! scope="row"| 1961
| ''[[Barabbas (1961 film)|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. ~ [[User:Arkhandar|<b style="color: #8cc5ff;">''Arkhandar''</b>]] <sup>([[User talk:Arkhandar|<b style="color: #b3b3b3;">''message me''</b>]])</sup> 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.) [[User:Erik|Erik]]&nbsp;([[User talk:Erik|talk]]&nbsp;&#124;&nbsp;[[Special:Contributions/Erik|contrib]]) <sup>([[Template:Reply to|ping me]])</sup> 16:07, 22 January 2019 (UTC)
:{{ping|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. [[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 00:47, 23 January 2019 (UTC)
::{{Reply to|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! ~ [[User:Arkhandar|<b style="color: #8cc5ff;">''Arkhandar''</b>]] <sup>([[User talk:Arkhandar|<b style="color: #b3b3b3;">''message me''</b>]])</sup> 01:01, 23 January 2019 (UTC)
:::{{ping|Quiddity}} I think the more interesting notes are in the "notes" block of H63: {{talk quote block|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.<br/><br/>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.<br/><br/>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. --[[User:Izno|Izno]] ([[User talk:Izno|talk]]) 04:06, 23 January 2019 (UTC)

== Numbering ==

I am a little bit confused about this:

'''A:''' List of highest-grossing films
{| style="margin:auto; margin:auto;" class="wikitable sortable"
|-
! Rank
! Film
! Year
! Director(s)
! Studio(s)
! Worldwide gross
! {{Tooltip|Ref.|Reference(s)}}
|- style="background:#b6fcb6;" span
| 1
| ''[[K.G.F: Chapter 1]]''
| 2018
| [[Prashanth Neel]]
| Hombale Films
| {{INRConvert|220|c}}
| [1]
|-
| 2
| ''[[Hebbuli]]''
| 2017
| [[S. Krishna]]
| SRV Productions
| {{INRConvert|100|c}}
| [2]
|-
| 3
|''[[Raajakumara]]''
| 2017
| [[Santhosh Ananddram]]
| Hombale Productions
| {{INRConvert|75|c}}
| [3]
|-
|rowspan="3"|4
| ''[[Kirik Party]]''
| 2016
| [[Rishab Shetty]]
| Paramvah Studios
| {{INRConvert|50|c}}
| [4]
|-
| ''[[Mr. and Mrs. Ramachari]]''
| 2014
|[[Santhosh Ananddram]]
| Jayanna Combines
| {{INRConvert|50|c}}
| [5]
|-
| ''[[Mungaru Male]]''
| 2006
|[[Yogaraj Bhat]]
| E. K. Entertainers
| {{INRConvert|50|c}}
| [6]
|-
|- style="width:50px; border:1px solid #aaa;" span
| rowspan="3"|5
|''[[Doddmane Hudga]]''
| 2016
| [[Duniya Soori]]
| Ajay Pictures
| {{INRConvert|40|c}}
| [7]
|-
| ''[[Sangolli Rayanna (film)|Krantiveera Sangolli Rayanna]]''
| 2012
| Naganna
| Sri Sangolli Rayanna Cine Combines
| {{INRConvert|40|c}}
| [8]
|-
|''[[Uppi 2]]''
| 2015
| [[Upendra (actor)|Upendra]]
| Upendra Productions
| {{INRConvert|40|c}}
| [9]
|-
| 6
|''[[Kotigobba 2]]''
| 2016
| [[K. S. Ravikumar]]
| Rambabu Productions
| {{INRConvert|35|c}}–{{INRConvert|38|c}}
| [10] 
|}

'''B:''' List of highest-grossing films
{| style="margin:auto; margin:auto;" class="wikitable sortable"
|-
! Rank
! Film
! Year
! Director(s)
! Studio(s)
! Worldwide gross
! {{Tooltip|Ref.|Reference(s)}}
|- style="background:#b6fcb6;" span
| 1
| ''[[K.G.F: Chapter 1]]''
| 2018
| [[Prashanth Neel]]
| Hombale Films
| {{INRConvert|220|c}}
| [1]
|-
| 2
| ''[[Hebbuli]]''
| 2017
| [[S. Krishna]]
| SRV Productions
| {{INRConvert|100|c}}
| [2]
|-
| 3
|''[[Raajakumara]]''
| 2017
| [[Santhosh Ananddram]]
| Hombale Productions
| {{INRConvert|75|c}}
| [3]
|-
|rowspan="3"|4
| ''[[Kirik Party]]''
| 2016
| [[Rishab Shetty]]
| Paramvah Studios
| {{INRConvert|50|c}}
| [4]
|-
| ''[[Mr. and Mrs. Ramachari]]''
| 2014
|[[Santhosh Ananddram]]
| Jayanna Combines
| {{INRConvert|50|c}}
| [5]
|-
| ''[[Mungaru Male]]''
| 2006
|[[Yogaraj Bhat]]
| E. K. Entertainers
| {{INRConvert|50|c}}
| [6]
|-
|- style="width:50px; border:1px solid #aaa;" span
| rowspan="3"|7
|''[[Doddmane Hudga]]''
| 2016
| [[Duniya Soori]]
| Ajay Pictures
| {{INRConvert|40|c}}
| [7]
|-
| ''[[Sangolli Rayanna (film)|Krantiveera Sangolli Rayanna]]''
| 2012
| Naganna
| Sri Sangolli Rayanna Cine Combines
| {{INRConvert|40|c}}
| [8]
|-
|''[[Uppi 2]]''
| 2015
| [[Upendra (actor)|Upendra]]
| Upendra Productions
| {{INRConvert|40|c}}
| [9]
|-
|10
|''[[Kotigobba 2]]''
| 2016
| [[K. S. Ravikumar]]
| Rambabu Productions
| {{INRConvert|35|c}}–{{INRConvert|38|c}}
| [10] 
|}

Which is correct? A and B? - <small>[[User:Siddiqsazzad001|<span style="color:Black;">'''S'''iddiqsazzad'''001'''</span>]] [[User talk:Siddiqsazzad001|<span style="color:Black;">'''<'''Talk'''/'''>'''</span>]]</small> 05:48, 26 January 2019 (UTC)
:What is the difference? --[[User:Izno|Izno]] ([[User talk: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. [[User:CUA 27|CUA 27]] ([[User talk: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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 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? [[User:Kylesenior|Kylesenior]] ([[User talk:Kylesenior|talk]]) 08:53, 3 February 2019 (UTC)

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

::{{ping|Kylesenior|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? [[User:Irtapil|Irtapil]] ([[User talk: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. [[User:Opencooper|Opencooper]] ([[User talk: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.- [[user:MrX|Mr]][[user talk:MrX|X]] 🖋 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. --[[User:Izno|Izno]] ([[User talk: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.- [[user:MrX|Mr]][[user talk:MrX|X]] 🖋 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. [[User:CUA 27|CUA 27]] ([[User talk:CUA 27|talk]]) 18:54, 30 March 2019 (UTC)
:{{re|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.- [[user:MrX|Mr]][[user talk:MrX|X]] 🖋 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. [[User:Cthomas3|'''''<span style="font-family: Courier New; font-size: larger; color: black;"><span style="color: brown;">C</span>Thomas<sup style="font-size: x-small; color: brown;">3</sup></span>''''']] ([[User talk:Cthomas3|talk]]) 01:07, 28 November 2019 (UTC)
:::Columns of integers *with {{underline|the same number of digits}} {{tq|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. {{tl|decimal cell}}, {{tl|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. [[User:Guarapiranga|Guarapiranga]] ([[User talk: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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 08:50, 28 November 2019 (UTC)
::I find it interesting you feel there is a need for the MOS to say that {{tq|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, {{u|SMcCandlish}}. How come the arguments you laid out above apply here and not there? [[User:Guarapiranga|Guarapiranga]] ([[User talk:Guarapiranga|talk]]) 10:41, 28 November 2019 (UTC)
::Also, if it's the software that {{tq|left-aligns by default}}, that's not an {{tq|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). [[User:Guarapiranga|Guarapiranga]] ([[User talk: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 {{em|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 {{em|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 {{em|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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 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? {{ping|SMcCandlish}} {{ping|Guarapiranga}} {{ping|Cthomas3}} {{ping|CUA 27}} {{ping|Izno}}. - [[user:MrX|Mr]][[user talk:MrX|X]] 🖋 23:20, 2 December 2019 (UTC)
:::::Why not? [[User:Guarapiranga|Guarapiranga]] ([[User talk:Guarapiranga|talk]]) 00:13, 3 December 2019 (UTC)
::::{{replyto|SMcCandlish}}: ''{{tq|we should not add new rules to an already over-long set of guidelines…}}''
::::Except of course if it's {{diff2|847943469|you adding}} the rule that {{tq|Wikipedia tables are are set flush-left, and allowed to grow rightward, not centered on the page}}. ''Good for thee, not for me''? [[User:Guarapiranga|Guarapiranga]] ([[User talk: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 [[Wikipedia:Fallacy of the revelation of policy|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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 08:44, 3 December 2019 (UTC)

== When should headings be plural (if at all)? ==

E.g. ''Country'' or ''Countries''? [[User:Guarapiranga|Guarapiranga]] ([[User talk: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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 18:14, 27 November 2019 (UTC)
::{{replyto|SMcCandlish}}: ''{{tq|[[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.) [[User:Guarapiranga|Guarapiranga]] ([[User talk: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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 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 {{underline|countries}} by ____'', {{u|SMcCandlish}}, not to the index page itself. Ok, so the header should be ''Countries'', not ''Country'' then. Got it. [[User:Guarapiranga|Guarapiranga]] ([[User talk:Guarapiranga|talk]]) 10:35, 28 November 2019 (UTC)
:::::Yeah, it's contextual. "List of country by {{var|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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 19:29, 28 November 2019 (UTC)
:I just reread this, and I am no longer in doubt: the <i>Country</i> 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 <i>Members</i> column heading in [[List of regional organizations by population]] is plural, as each organisation has more than one member, and the <i>Organisation</i> column heading is singular bc each record, i.e. each row, refers to a single organisation). <span id="Guarapiranga:1654751574877:Wikipedia_talkFTTCLNManual_of_Style/Tables" class="FTTCmt">— [[User:Guarapiranga|Guarapiranga]]&nbsp;[[User talk:Guarapiranga|☎]] 05:12, 9 June 2022 (UTC)</span>

== <code>margin:auto</code> vs <code>margin-left:0</code> ==

[https://en.wikipedia.org/w/index.php?title=Wikipedia:Manual_of_Style/Tables&diff=928113516&oldid=927419954 I reverted] {{u|SMcCandlish}}'s addition last year saying: ''{{tq|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. [[User:Guarapiranga|Guarapiranga]] ([[User talk: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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 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. [[User:Lazer-kitty|Lazer-kitty]] ([[User talk: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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 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 [[Arsenal_F.C.#Kit_suppliers_and_shirt_sponsors|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 [[2020_Formula_One_World_Championship#Entries|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. [[User:Lazer-kitty|Lazer-kitty]] ([[User talk:Lazer-kitty|talk]]) 13:02, 5 December 2019 (UTC)
:'''Support''' and changed. Please feel free to wordsmith it (NTS). [[User:Guarapiranga|Guarapiranga]] ([[User talk:Guarapiranga|talk]]) 19:56, 5 December 2019 (UTC)
::I see you didn't like my proposed changes, {{u|Izno}}. Care to join the discussion? [[User:Guarapiranga|Guarapiranga]] ([[User talk: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. --[[User:Izno|Izno]] ([[User talk:Izno|talk]]) 01:41, 6 December 2019 (UTC)
::::Now we have a concrete change proposal to discuss recorded in {{diff|Wikipedia:Manual of Style/Tables|929429828|928231449|that revision}}. All in the spirit of [[WP:BRD]]. [[User:Guarapiranga|Guarapiranga]] ([[User talk:Guarapiranga|talk]]) 02:13, 6 December 2019 (UTC)
:::::: Thanks for generating a useful proposal for discussion. I support the proposed revision. [[User:CUA 27|CUA 27]] ([[User talk:CUA 27|talk]]) 05:24, 6 December 2019 (UTC)
:::::::I really like your proposed change, {{u|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 {{u|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." [[User:Lazer-kitty|Lazer-kitty]] ([[User talk: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. [[User:CUA 27|CUA 27]] ([[User talk:CUA 27|talk]]) 16:38, 7 December 2019 (UTC) 
:::::Of course. :) --[[User:Izno|Izno]] ([[User talk: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? {{ping|Izno|Lazer-kitty|CUA 27|Guarapiranga|}} [[User:Irtapil|Irtapil]] ([[User talk: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. [[User:CUA 27|CUA 27]] ([[User talk: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 [https://meta.m.wikimedia.org/wiki/Research:Which_parts_of_an_article_do_readers_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.--<span style="font-weight:bold;color:darkblue">[[User_talk:Moxy|Moxy]]</span> <span style="color:red">🍁</span> 16:56, 7 December 2019 (UTC)
::::{{ping|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. [[User:Irtapil|Irtapil]] ([[User talk: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. [[User:Lazer-kitty|Lazer-kitty]] ([[User talk:Lazer-kitty|talk]]) 18:11, 7 December 2019 (UTC)
:::::: {{ping|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?
:::::: [[User:Irtapil|Irtapil]] ([[User talk: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  [https://www.colorado.edu/accessible-technology/2016/09/17/when-use-tables-and-how-make-them-accessible-screen-reader-users When to Use Tables and How to Make Them Accessible to Screen Reader Users] - University of Colorado.--<span style="font-weight:bold;color:darkblue">[[User_talk:Moxy|Moxy]]</span> <span style="color:red">🍁</span> 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. [[User:Guarapiranga|Guarapiranga]] ([[User talk:Guarapiranga|talk]]) 22:26, 7 December 2019 (UTC)
:::::From {{u|Moxy}}'s [https://www.colorado.edu/accessible-technology/2016/09/17/when-use-tables-and-how-make-them-accessible-screen-reader-users ref above]: {{tq2|'''When to Use a Table'''<br>… 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.<br><br>'''When Not to Use a Table'''<br>The biggest problem is when a developer uses a table in order to format a page. …}} That's clearly {{underline|not}} the cases we're discussing. We're talking about tables with {{underline|actual}} content. hi[[User:Guarapiranga|Guarapiranga]] ([[User talk:Guarapiranga|talk]]) 22:31, 7 December 2019 (UTC)
:::::::{{ping|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. [[User:Irtapil|Irtapil]] ([[User talk:Irtapil|talk]]) 05:29, 7 May 2020 (UTC)

:I definitely '''agree with the original post''' in this by {{ping|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.
:[[User:Irtapil|Irtapil]] ([[User talk: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.  -- [[User:RoySmith|RoySmith]] [[User Talk: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:
{|class=wikitable
|-
|Usual || Table || Stuff || Here
|-
|colspan=4|
===Random section header===
|-
|Usual || Table || Stuff || Here
|-
|colspan=4|
===Random section header===
|-
|Usual || Table || Stuff || Here
|} [[User:Howard the Duck|Howard the Duck]] ([[User talk:Howard the Duck|talk]]) 16:26, 2 May 2020 (UTC)
:Generally, just don't do this. --[[User:Izno|Izno]] ([[User talk:Izno|talk]]) 16:51, 2 May 2020 (UTC)
:::: {{ping|Izno|Howard the Duck}} why not? and what would be preferable? [[User:Irtapil|Irtapil]] ([[User talk:Irtapil|talk]]) 06:18, 7 May 2020 (UTC)
::::: {{ping|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. [[User:Howard the Duck|Howard the Duck]] ([[User talk: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. [[User:Howard the Duck|Howard the Duck]] ([[User talk: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. --[[User:Izno|Izno]] ([[User talk: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. [[User:Howard the Duck|Howard the Duck]] ([[User talk:Howard the Duck|talk]]) 19:19, 2 May 2020 (UTC)

== Where to ask for help for a specific table ==

Here or somewhere else?--[[User:Prisencolin|Prisencolin]] ([[User talk:Prisencolin|talk]]) 06:32, 25 May 2020 (UTC)
:{{u|Prisencolin}} here is fine. I can take a look. --[[User:Izno|Izno]] ([[User talk:Izno|talk]]) 14:50, 25 May 2020 (UTC)
::{{u|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...--[[User:Prisencolin|Prisencolin]] ([[User talk:Prisencolin|talk]]) 19:12, 25 May 2020 (UTC)
:::{{ping|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.<p>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. --[[User:Izno|Izno]] ([[User talk:Izno|talk]]) 03:22, 27 May 2020 (UTC)
:::{{ping|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? --[[User:Izno|Izno]] ([[User talk: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 [[Jennifer Aniston filmography|here]] and discographies another, example [[Coldplay discography|here]]. My understanding is that the discography version is better for readers with [[WP:ACCESS|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? [[User:NapHit|NapHit]] ([[User talk:NapHit|talk]]) 20:44, 27 May 2020 (UTC)
:{{re|NapHit}} {{tq|Filmographies used to follow the example shown on the page ...|q=yes}}: 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.—[[User:Bagumba|Bagumba]] ([[User talk:Bagumba|talk]]) 04:12, 28 May 2020 (UTC)
:: Thanks for your response {{u|Bagumba}}. The page I was referring was [[Wikipedia:Manual of Style/Accessibility/Data tables tutorial|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? [[User:NapHit|NapHit]] ([[User talk:NapHit|talk]]) 11:30, 28 May 2020 (UTC)
:::{{re|NapHit}} You might also consider leaving a notification about this at [[WP:FILMOGRAPHY]]. Regards.—[[User:Bagumba|Bagumba]] ([[User talk:Bagumba|talk]]) 11:35, 28 May 2020 (UTC)
::::{{Reply to|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. ~ [[User:Arkhandar|<b style="color: #8cc5ff;">''Arkhandar''</b>]] <sup>([[User talk:Arkhandar|<b style="color: #b3b3b3;">''message me''</b>]])</sup> 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. [[User:DMacks|DMacks]] ([[User talk: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 {{tl|reflist}} notes but the {{tl|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 {{tag|abbr}} or {{tl|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 <code>summary</code> 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.) --[[User:Izno|Izno]] ([[User talk: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? <small>(please use&#32;{{tlx|ping|Sdkb}} on reply)</small><!--Template:Please ping--> <span style="color:#AAA"><small>&#123;{u&#124;</small><span style="border-radius:9em;padding:0 5px;background:#088">[[User:Sdkb|<span style="color:#FFF">'''Sdkb'''</span>]]</span><small>}&#125;</small></span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 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.{{tlx|ping|Sdkb}} &minus;[[User:Woodstone|Woodstone]] ([[User talk: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. [[User:Schazjmd|<span style="color:#9966FF;">Schazjmd</span>]]&nbsp;[[User talk:Schazjmd|<span style="color:#5500FF;">''(talk)''</span>]] 15:20, 20 December 2020 (UTC)

:In the absence of comment, a draft of the proposed changes has been prepared. Please comment or edit [[Help_talk:Table#Use_of_em_and_%_values_in_preference_to_px_values|here]]. [[User:SCHolar44|<b style="color:#7F007F; font-size:medium">SCHolar44 🇦🇺</b>]] [[User talk: SCHolar44|<b>💬</b>]] at 03:28, 18 January 2021 (UTC)

== [[:Wikipedia:WikiProject Discographies]] has an [[WP:RFC|RFC]]==

<div class="floatleft" style="margin-bottom:0">[[File:Ambox warning orange.svg|48px|alt=|link=]]</div>'''[[: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 '''[[Wikipedia talk:WikiProject Discographies#RfC: Possible alternative to current singles discography tables|discussion page]]'''.<!-- Template:rfc-notify--> Thank you. [[User:Heartfox|Heartfox]] ([[User talk: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 "{{tq|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:

{| class="wikitable sortable plainrowheaders"
|+Current
|-
! scope="row" align="center" | 1968
| ''[[Rosemary's Baby (film)|Rosemary's Baby]]''
| Girl at Party
| Film; uncredited
|-
! scope="row" align="center" | 1968
| ''{{sortname|The|Wrecking Crew|The Wrecking Crew (1969 film)}}''
| Freya Carlson
| Film
|-
|}

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

{| class="wikitable sortable plainrowheaders"
|+ Exhibit A
|-
|  1968
! scope="row" align="center" | ''[[Rosemary's Baby (film)|Rosemary's Baby]]''
| Girl at Party
| Film; uncredited
|-
| 1968
! scope="row" align="center" |  ''{{sortname|The|Wrecking Crew|The Wrecking Crew (1969 film)}}''
| Freya Carlson
| Film
|-
|}

{| class="wikitable sortable plainrowheaders"
|+ Exhibit B
|-
! scope="row" align="center" |  ''[[Rosemary's Baby (film)|Rosemary's Baby]]''
| 1968
| Girl at Party
| Film; uncredited
|-
! scope="row" align="center" |  ''{{sortname|The|Wrecking Crew|The Wrecking Crew (1969 film)}}''
| 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: ([https://en.wikipedia.org/w/index.php?title=Wikipedia:Manual_of_Style/Tables&oldid=535553160]) Discography table had no headers. Filmography table added, with title headers.
*May 2019: ([https://en.wikipedia.org/w/index.php?title=Wikipedia:Manual_of_Style/Tables&oldid=899511285]) Discography table gained year headers.
*May 2019: ([https://en.wikipedia.org/w/index.php?title=Wikipedia:Manual_of_Style/Tables&oldid=899578910]) 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]]. — [[User:Goszei|Goszei]] ([[User_talk: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 <code>scope="row"</code> 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 <code>scope="row"</code> 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 <code>scope="row"</code> 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 <code>scope="row"</code> added. Then (says I), the "Multi-column mixed sortable unsortable" section should be changed, swapping Year and Title content, but leaving <code>scope="row"</code> 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, [[User:Goszei|Goszei]]. <i>&mdash;&nbsp;[[User:JohnFromPinckney|JohnFromPinckney]] ([[User talk:JohnFromPinckney|talk]])</i> 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. <i>&mdash;&nbsp;[[User:JohnFromPinckney|JohnFromPinckney]] ([[User talk:JohnFromPinckney|talk]])</i> 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. --[[User:IJBall|IJBall]] <small>([[Special:Contributions/IJBall|contribs]] • [[User talk:IJBall|talk]])</small> 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. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 16:27, 24 March 2021 (UTC)
::(From the purely aesthetic, I am not a fan of mid-row table headers.) [[User:Izno|Izno]] ([[User talk: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... --[[User:IJBall|IJBall]] <small>([[Special:Contributions/IJBall|contribs]] • [[User talk:IJBall|talk]])</small> 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. — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 03:34, 25 March 2021 (UTC)</p>
* '''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 {{samp|summary}} and {{samp|caption}} attributes of {{tag|table|o}}.  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.<!--
--><p>{{em|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).</p><!--
--><p>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]].<br /><span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 03:34, 25 March 2021 (UTC)</p>
:: Obviously, I'm fine with this, as this is how [[WP:FILMOGRAPHY]]s 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. --[[User:IJBall|IJBall]] <small>([[Special:Contributions/IJBall|contribs]] • [[User talk:IJBall|talk]])</small> 12:25, 25 March 2021 (UTC)
:::Hi, IJBall. You {{tqq|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. <i>&mdash;&nbsp;[[User:JohnFromPinckney|JohnFromPinckney]] ([[User talk:JohnFromPinckney|talk]])</i> 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. --[[User:IJBall|IJBall]] <small>([[Special:Contributions/IJBall|contribs]] • [[User talk:IJBall|talk]])</small> 19:41, 25 March 2021 (UTC)
:::::Yeah, this rowspan stuff causes accessibility problems. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 10:11, 3 April 2021 (UTC)

== Football box collapsible ==

{{Football box collapsible|format=1
|round = [[2022 FIFA World Cup qualification (CONMEBOL)|2022 World Cup qualification]]
|date = 13 October 2020
|time = {{UTZ|16:00|−4}}
|team1 = {{fb-rt|BOL}}
|score = 1–2
|report = https://www.fifa.com/worldcup/preliminaries/southamerica/matches/match/400104549/
|team2 = {{fb|ARG}}
|goals1 =
*[[Marcelo Martins Moreno|Moreno]] {{goal|24}}
|goals2 =
*[[Lautaro Martínez|L. Martínez]] {{goal|45}}
*[[Joaquín Correa|Correa]] {{goal|79}}
|stadium = [[Estadio Hernando Siles]]
|location = [[La Paz]], Bolivia
|attendance = 0
|referee = [[Diego Haro]] ([[Peruvian Football Federation|Peru]])
|result = W
}}
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--[[User:Sakiv|Sakiv]] ([[User talk: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.—[[User:Bagumba|Bagumba]] ([[User talk:Bagumba|talk]]) 13:32, 19 June 2021 (UTC)
:<s>{{u|Bagumba}}, Why isn't this answered by [[MOS:NOHOVER]] which includes an explicit exception for use of the {{tl|abbr}} template?</s> <u>I now realize you were asking whether both should be included. If the implication is that use of both is overkill, I agree.</u> [[User:Sphilbrick|<span style="color:#000E2F;padding:0 4px;font-family: Copperplate Gothic Light">S Philbrick</span>]][[User talk:Sphilbrick|<span style=";padding:0 4px;color:# 000;font-family: Copperplate Gothic Light">(Talk)</span>]] 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.—[[User:Bagumba|Bagumba]] ([[User talk: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 {{xt|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). <i>&mdash;&nbsp;[[User:JohnFromPinckney|JohnFromPinckney]] ([[User talk:JohnFromPinckney|talk]] / [[Special:Contributions/JohnFromPinckney|edits]])</i> 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.—[[User:Bagumba|Bagumba]] ([[User talk:Bagumba|talk]]) 10:17, 21 June 2021 (UTC)
::{{u|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 [https://en.wikipedia.org/w/index.php?title=Sytia_Messer&oldid=1026571276 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? [[User:Sphilbrick|<span style="color:#000E2F;padding:0 4px;font-family: Copperplate Gothic Light">S Philbrick</span>]][[User talk:Sphilbrick|<span style=";padding:0 4px;color:# 000;font-family: Copperplate Gothic Light">(Talk)</span>]] 18:02, 22 June 2021 (UTC)
:::Well, there are the arguments of clarity and [[WP:ACCESS|accessibility]]. Usually, discussions of "accessibility" revolve around color-blindness and screen reader users, which don't apply in this case; the use of {{tl|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. <i>&mdash;&nbsp;[[User:JohnFromPinckney|JohnFromPinckney]] ([[User talk:JohnFromPinckney|talk]] / [[Special:Contributions/JohnFromPinckney|edits]])</i> 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. -- [[User:Beland|Beland]] ([[User talk: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. –&nbsp;Editør ([[User talk: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. -- [[User:Beland|Beland]] ([[User talk:Beland|talk]]) 19:32, 10 January 2024 (UTC)
::::::I do support the notion; I am reviewing the prose and giving it a copyediting pass. [[User:Remsense|<span style="border-radius:2px 0 0 2px;padding:3px;background:#1E816F;color:#fff">'''Remsense'''</span>]][[User talk:Remsense|<span lang="zh" style="border:1px solid #1E816F;border-radius:0 2px 2px 0;padding:1px 3px;color:#000">留</span>]] 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. [[User:Remsense|<span style="border-radius:2px 0 0 2px;padding:3px;background:#1E816F;color:#fff">'''Remsense'''</span>]][[User talk:Remsense|<span lang="zh" style="border:1px solid #1E816F;border-radius:0 2px 2px 0;padding:1px 3px;color:#000">留</span>]] 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. {{tq|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 {{tq|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]] ([https://en.wikipedia.org/w/index.php?title=South_Korea_national_under-20_football_team&oldid=1194748555 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. [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 02:35, 11 January 2024 (UTC)
:::::::::I've further edited the passage per this. [[User:Remsense|<span style="border-radius:2px 0 0 2px;padding:3px;background:#1E816F;color:#fff">'''Remsense'''</span>]][[User talk:Remsense|<span lang="zh" style="border:1px solid #1E816F;border-radius:0 2px 2px 0;padding:1px 3px;color:#000">留</span>]] 02:47, 11 January 2024 (UTC)
::::::::::{{reply|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. -- [[User:Beland|Beland]] ([[User talk: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. [[User:Remsense|<span style="border-radius:2px 0 0 2px;padding:3px;background:#1E816F;color:#fff">'''Remsense'''</span>]][[User talk:Remsense|<span lang="zh" style="border:1px solid #1E816F;border-radius:0 2px 2px 0;padding:1px 3px;color:#000">留</span>]] 22:10, 11 January 2024 (UTC)
::::::::::::{{reply|Remsense}} What sort of dimensions and nuances do you mean? By "prose" do you mean footnotes or article body text? -- [[User:Beland|Beland]] ([[User talk: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 (American TV series)|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 [https://en.wikipedia.org/w/index.php?title=Hell%27s_Kitchen_(American_season_20)&oldid=1029804620#Contestant_progress 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. [[User:Magitroopa|Magitroopa]] ([[User talk:Magitroopa|talk]]) 04:08, 22 June 2021 (UTC)
:Before you spend any more nanoseconds on this, Magitroopa, take the time to look at [[Wikipedia talk:Manual of Style/Television#rfc 5E401C7|this RfC]], in which the future (format/desirability/accessibility requirements) of such tables is being discussed. <i>&mdash;&nbsp;[[User:JohnFromPinckney|JohnFromPinckney]] ([[User talk:JohnFromPinckney|talk]] / [[Special:Contributions/JohnFromPinckney|edits]])</i> 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. [[User:Dawnseeker2000|<span style="font-variant: small-caps">''Dawnseeker2000''</span>]] 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. [[WP:DISCOGSTYLE|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. <i>&mdash;&nbsp;[[User:JohnFromPinckney|JohnFromPinckney]] ([[User talk:JohnFromPinckney|talk]] / [[Special:Contributions/JohnFromPinckney|edits]])</i> 18:55, 31 July 2021 (UTC)
:This is now being discussed [[Template talk:Table cell templates#RfC: Template:n/a → —|here]] in relation to whether {{tl|n/a}} should render to emdash instead of {{mono|N/A}} by dedault. <span id="Guarapiranga:1654758407244:Wikipedia_talkFTTCLNManual_of_Style/Tables" class="FTTCmt">— [[User:Guarapiranga|Guarapiranga]]&nbsp;[[User talk:Guarapiranga|☎]] 07:06, 9 June 2022 (UTC)</span>

== 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? [[User:Fcrary|Fcrary]] ([[User talk: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 {{em|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 [[NASA Astronaut Group 2|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. <i>&mdash;&nbsp;[[User:JohnFromPinckney|JohnFromPinckney]] ([[User talk:JohnFromPinckney|talk]] / [[Special:Contributions/JohnFromPinckney|edits]])</i> 20:26, 22 September 2021 (UTC)
::Since the article-topic is ''astronaut'', how about each entry is a bullet-list of their space missions? [[User:DMacks|DMacks]] ([[User talk: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.
::::{| class=wikitable class=sortable
! Astronaut
! Mission
|-
|rowspan=3|Fred Flintstone
|Apollo Stones
|-
|Gemini Rocks
|-
|Soyuz Sands
|-
|rowspan=2|Barney Rubble
|Gemini Rocks
|-
|Apollo Stones
|}
::: [[User:Martin Kealey|Martin Kealey]] ([[User talk: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 <code>rowspan</code> or <code>colspan</code>? 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. &horbar;[[User:Jochem van Hees|Jochem van Hees]] ([[User talk:Jochem van Hees|talk]]) 10:59, 25 October 2021 (UTC)
:You're right, [[User:Jochem van Hees|Jochem]], there isn't. I'd say {{mono|rowspan}} ought to be used in a column heading whenever other column headings have more layers to them, e.g.:
:{| class=wikitable
! rowspan=2 style=vertical-align:bottom | Country
! colspan=2 | Population
|-
! amt
! pct
|-
|&nbsp;||&nbsp;
|}
The same can be said for row headings. Now, in relation to data cells, I'd say {{mono|colspan}} can be used when the data is shared across fields (e.g. {{oldid2|1034694173|List of countries and dependencies by area), or {{mono|rowspan}} when it's shared across records (presuming records are on rows; the other way around otherwise). <span id="Guarapiranga:1654755354271:Wikipedia_talkFTTCLNManual_of_Style/Tables" class="FTTCmt">— [[User:Guarapiranga|Guarapiranga]]&nbsp;[[User talk:Guarapiranga|☎]] 06:15, 9 June 2022 (UTC)</span>

== 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. [[User:Steal the Kosher Bacon|Steal the Kosher Bacon]] ([[User talk:Steal the Kosher Bacon|talk]]) 13:15, 26 November 2021 (UTC)
:As a bullet point list, [[User:Steal the Kosher Bacon|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 [[Bernard Lewis|author's article]] (which already contains mostly all of the content in its [[Bernard Lewis#Bibliography|Bibliography]] section anway). <span id="Guarapiranga:1654752417171:Wikipedia_talkFTTCLNManual_of_Style/Tables" class="FTTCmt">— [[User:Guarapiranga|Guarapiranga]]&nbsp;[[User talk:Guarapiranga|☎]] 05:26, 9 June 2022 (UTC)</span>
::thank you [[User:Steal the Kosher Bacon|Steal the Kosher Bacon]] ([[User talk: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?
— [[User:Guarapiranga|Guarapiranga]]&nbsp;[[User talk:Guarapiranga|☎]] 06:33, 9 June 2022 (UTC)

== Use of "|style=" ==

[https://en.wikipedia.org/w/index.php?title=James_DeGale&type=revision&diff=1113665478&oldid=1104137151 This edit] got me curious. Is changing <code><nowiki>|style="text-align:left;"</nowiki></code> to <code><nowiki>|align=left</nowiki></code> best practice, or does it not matter? [[User:Mac Dreamstate|Mac Dreamstate]] ([[User talk:Mac Dreamstate|talk]]) 19:51, 2 October 2022 (UTC)

:{{Reply to|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, [[World Wide Web Consortium|W3]] has deprecated the {{code|align}} attribute according to [https://www.w3.org/TR/html4/present/graphics.html#h-15.1.2 this document], so if you have to choose, then {{code|1=style="text-align: left;"}} is better. &horbar;[[User:Jochem van Hees|Jochem van Hees]] ([[User talk:Jochem van Hees|talk]]) 11:31, 3 May 2023 (UTC)

== [[:Aurochs]] has an [[WP:RFC|RFC]]==

<div class="floatleft" style="margin-bottom:0">[[File:Ambox warning orange.svg|48px|alt=|link=]]</div>'''[[: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 '''[[Talk:Aurochs#Cladogram|discussion page]]'''.<!-- Template:Rfc notice--> Thank you. [[Special:Contributions/89.206.112.13|89.206.112.13]] ([[User talk: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. [[Special:Contributions/75.72.161.233|75.72.161.233]] ([[User talk: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? [[User:JonSnow64|JonSnow64]] ([[User talk:JonSnow64|talk]]) 14:01, 25 August 2023 (UTC)

== Tool(s) for working with wikitables ==

{{FYI|pointer=y}}
Please see: [[Help talk:Table#Tool(s) for working with wikitables]]. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 03:37, 26 August 2023 (UTC)

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

{{blockquote|4.4.1 ''Edit tables with the same attention given to text, and set them as text to be read.''<br />
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.<br />
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?"<br />
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:<br />
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.<ref>{{cite book |title = The elements of typographic style |edition = third |first = Robert |last = Bringhurst |publisher = Hartley & Marks |location=Seattle |year = 2004 |isbn = 978-0-88179-206-5 |url=https://archive.org/details/isbn_9780881791327/mode/2up |page=[https://archive.org/details/isbn_9780881791327/page/70/mode/1up 70] }}</ref>|source=Robert Bringhust, ''The elements of typographic style''}}
{{reflist talk}}

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, {{tlx|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.) [[User:JMF|𝕁𝕄𝔽]] ([[User talk:JMF|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.<br style="margin-bottom:0.5em"/>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.<span id="Remsense:1701888350870:Wikipedia_talkFTTCLNManual_of_Style/Tables" class="FTTCmt"> [[User:Remsense|<span style="border-radius:2px 0 0 2px;padding:3px;background:#1E816F;color:#fff">'''Remsense'''</span>]][[User talk:Remsense|<span lang="zh" style="border:1px solid #1E816F;border-radius:0 2px 2px 0;padding:1px 3px;color:#000">留</span>]] 18:45, 6 December 2023 (UTC)</span>
:'''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 {{tl|Tooltip}} to each would help? [[User:Jroberson108|Jroberson108]] ([[User talk: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 [[User:Remsense|<span style="border-radius:2px 0 0 2px;padding:3px;background:#1E816F;color:#fff">'''Remsense'''</span>]][[User talk:Remsense|<span lang="zh" style="border:1px solid #1E816F;border-radius:0 2px 2px 0;padding:1px 3px;color:#000">留</span>]] 19:52, 6 December 2023 (UTC)
:::I think you're confusing {{tlx|Tooltip}} with {{tlx|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 {{tag|abbr}} markup properly used by {{tlx|abbr}}). <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 04:08, 7 December 2023 (UTC)
:How feasible is it for us to do ''diagonal'' (45°) table-headers, nowadays? E.g. [https://css-tricks.com/rotated-table-column-headers/ 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 [[Special:WhatLinksHere/Template:Vertical_header|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) [https://i.imgur.com/fchq65I.png screenshot 1], [https://i.imgur.com/Murr5fD.png 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). [[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 23:33, 6 December 2023 (UTC)
::<del>I think I will try to implement a template for this 45° paradigm, for testing purposes.</del> 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 {{em|images of text}} to create a vertical header is incredible, and I really would like to remove it right now.) [[User:Remsense|<span style="border-radius:2px 0 0 2px;padding:3px;background:#1E816F;color:#fff">'''Remsense'''</span>]][[User talk:Remsense|<span lang="zh" style="border:1px solid #1E816F;border-radius:0 2px 2px 0;padding:1px 3px;color:#000">留</span>]] 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]]. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 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 {{tl|Rotate text}} and {{tl|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. [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 04:15, 7 December 2023 (UTC)
:{{strong|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 {{tag|br|s}} as needed to break up a long header or other cell entry, and the more robust solution is to use CSS column-width controls. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 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. --[[User:Ftrebien|Fernando Trebien]] ([[User talk:Ftrebien|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 {{code|column-width}} or a key + an {{tlx|abbr}}eviated header. Does anyone have any first hand experience on how this technique plays with screen readers and the like? [[User:Remsense|<span style="border-radius:2px 0 0 2px;padding:3px;background:#1E816F;color:#fff">'''Remsense'''</span>]][[User talk:Remsense|<span lang="zh" style="border:1px solid #1E816F;border-radius:0 2px 2px 0;padding:1px 3px;color:#000">留</span>]] 19:42, 10 December 2023 (UTC)
:::On mobile, there isn't a way to hover on <code>{{tlc|abbr}}</code>eviated text. [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 19:51, 10 December 2023 (UTC)
::::[[User:Jroberson108|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?<span id="Remsense:1702238197436:Wikipedia_talkFTTCLNManual_of_Style/Tables" class="FTTCmt"> [[User:Remsense|<span style="border-radius:2px 0 0 2px;padding:3px;background:#1E816F;color:#fff">'''Remsense'''</span>]][[User talk:Remsense|<span lang="zh" style="border:1px solid #1E816F;border-radius:0 2px 2px 0;padding:1px 3px;color:#000">留</span>]] 19:56, 10 December 2023 (UTC)</span>
:::::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". [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 20:34, 10 December 2023 (UTC)
::::::[[User:Jroberson108|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.<span id="Remsense:1702242290153:Wikipedia_talkFTTCLNManual_of_Style/Tables" class="FTTCmt"> [[User:Remsense|<span style="border-radius:2px 0 0 2px;padding:3px;background:#1E816F;color:#fff">'''Remsense'''</span>]][[User talk:Remsense|<span lang="zh" style="border:1px solid #1E816F;border-radius:0 2px 2px 0;padding:1px 3px;color:#000">留</span>]] 21:04, 10 December 2023 (UTC)</span>
:::::::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. [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 21:22, 10 December 2023 (UTC)
:::::::This is the only thing I could find that comes close: [https://ux.stackexchange.com/questions/90842/legends-in-table-data 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. [[User:Jroberson108|Jroberson108]] ([[User talk: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 <code>&lt;br></code>'', often removing the need to scroll horizontally, with a concomitant increase in comprehensibility.
:[[User:Martin Kealey|Martin Kealey]] ([[User talk: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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 02:32, 21 November 2024 (UTC)
:::@[[User:SMcCandlish|SMcCandlish]] 
:::"Poor information architecture" is ''not'' always the cause. It's quite possible to have two perfectly logical semantic axes that result in a yes/no answer at each intersection.
:::For example, the pages documenting legal radio spectrum for WiFi devices have tables by frequency (channel) vs jurisdiction (country). At the moment they're arbitrarily split into ranges of frequencies, purely based on historical labelling as "2.4G", "5G", "4.9G", "6G", etc. This has led to significant maintenance headaches, with overlapping portions having conflicting table entries, and the cells pertaining to one country being smeared over several hundred lines.
:::I would like to transpose that table, so it has countries as rows and frequencies as columns; this would allow all the allocation rules for each country to be expressed as a single table row, for the table to be sorted by country name or by channel availability. However the resulting table would have about 300 columns, and would be absolutely ruined by horizontal labels. (Indeed, it would be preferable to stagger heading labels over multiple rows. Thankfully that only has to be done once.)
:::[[User:Martin Kealey|Martin Kealey]] ([[User talk:Martin Kealey|talk]]) [[User:Martin Kealey|Martin Kealey]] ([[User talk:Martin Kealey|talk]]) 05:37, 30 March 2025 (UTC)
::::Fair enough, I suppose, but "hard cases make bad law" as the saying goes, translated for our context into "edge cases make poor guidelines". Even with 300 columns done with vertical headers, it would basically be unusable as a web table, especially on mobile, and more appropriate for a spreadsheet application. On a website, such material would be better broken up into chunks forming separate smaller tables, by one criterion or another. [[WP:NOT#DATABASE]] is also potentially a concern. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 07:37, 30 March 2025 (UTC)
:::::Rather than a database, think of it as more akin to a statistical scatter plot, but implemented as a textual table rather than as a bitmap image. (I grant you that we're really pushing the boundaries of what tables ''should'' be used for, but unlike an image generated from a database, anyone can maintain text, and that's quite important to ensure that the pages remain current.)
:::::A table a good way to visualise and highlight regulatory similarities and differences. As for usability, the key is that each row comprises relatively few contiguous runs of single values so it would still be quite functional with only a single pixel per cell, meaning it could easily fit on a cellphone screen. (The trick would be in staggering the headings so that ''they'' don't overlap. This isn't as crazy as it sounds, as there is actually a hierarchy to the frequencies, so they naturally fit into different rows anyway: pairs of 5 MHz channels to form 10 MHz channels, then 20, 40, 80, 160, etc) That said, it would still be useful if it scrolled horizontally, as long as the country (label) column was pinned.
:::::I agree that it's exceptional enough not to form the basis of a primary rule, but it's worth noting as a reasonable exception to any general prohibition or deprecation.
:::::The ''real'' underlying database is the list of boundary frequencies, not a list of yes/no for each channel. (In some cases the boundary frequencies are in the middle of a channel, making that channel either subject to multiple constraints, or outright unusable.)
:::::[[User:Martin Kealey|Martin Kealey]] ([[User talk:Martin Kealey|talk]]) 08:35, 30 March 2025 (UTC)
{{outdent|:::}}
I think '''{{t|Vertical header}}''' should be avoided if other solutions are better overall. But I agree with {{u|Martin Kealey}} that sometimes the benefits outweigh the deficits. And '''{{t|Sticky table start}}''' was created '''[https://en.wikipedia.org/w/index.php?title=Template:Sticky_table_start&action=history 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 {{t|Sticky table start}}. See the full working table '''[https://en.wikipedia.org/w/index.php?title=Template:Vertical_header/doc&oldid=1258017836#Vertical_headers_combined_with_sticky_table_header here].'''

{{static row numbers}}{{Sticky table start}}{{mw-datatable}}
{| class="wikitable sortable static-row-numbers sticky-table-row1 sticky-table-col1 mw-datatable"
|+ List of countries with annual rates and counts for killings by law enforcement officers. With breakdown by police, etc..
|- style=vertical-align:bottom;
! Location
! Region
! data-sort-type=number |Killings
! {{verth|stp=1|Police}}
! {{verth|stp=1|Military}}
! {{verth|stp=1|{{abbr|Intel|Intelligence}}<br>agencies}}
! {{verth|stp=1|Other}}
! Population
! Rate per 10 million
! Year listed
! [[List of countries by intentional homicide rate#Notes|Notes]]
! {{verth|Source}}
|-
|{{Flag|Afghanistan}}
|Asia
|606
|49
|267
|234
|56
|align=right|35,530,000
|style="background:#00005c; color:#fff;"|170.5
|2018
|
|
|-
|{{Flag|Guyana}}
|Americas
|12+
|12
|0
|0
|0
|align=right|787,076
|style="background:#00005c; color:#fff;"|152.5
|2018
|
|
|}
{{sticky table end}}

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]].''' --[[User:Timeshifter|'''Timeshifter''']] ([[User talk: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 [https://en.wikipedia.org/w/index.php?title=Wikipedia%3AManual_of_Style%2FTables&diff=1194627380&oldid=1192553658 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. –&nbsp;Editør ([[User talk: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 [[Wikipedia:BOLD, revert, discuss cycle|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. -- [[User:Beland|Beland]] ([[User talk:Beland|talk]]) 23:58, 11 January 2024 (UTC)
::That's definitely bad form; regardless of the intent, it {{em|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 {{tlx|tooltip}} template for this purpose which does not abuse the {{tag|abbr|o}} 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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 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 {{tl|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. –&nbsp;Editør ([[User talk:Editør|talk]]) 19:21, 13 January 2024 (UTC)
::::{{ping|Editør}} Interested in the {{tlx|if mobile}} use cases. "Tell me more!" I've seen a similar interesting use of {{tlx|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). <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 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. –&nbsp;Editør ([[User talk:Editør|talk]]) 12:10, 5 February 2024 (UTC)
::::::Never mind; I see that the template is now deprecated, for additional problems. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 07:40, 30 March 2025 (UTC)

== [[Template:Sort under]] ==

First 2 tables below use '''{{t|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''':
{{static row numbers}}{{sticky header}}{{mw-datatable}}{{table alignment}}{{sort under}}
{| class="wikitable sortable static-row-numbers sticky-header mw-datatable col5left col6left sort-under-center" style=text-align:right;
|+Intentional homicide victims per 100,000 inhabitants. From [[United Nations Office on Drugs and Crime|UNODC]].
|-
! Location
! Rate
! Count
! Year
! [[UN region|Region]]
! [[UN subregion|Subregion]]
|-
| {{flagg|us*eft|pref=Crime in|Afghanistan}} || 4.0 || 1,613 || 2021 || [[Asia]] || [[United Nations geoscheme for Asia#Southern Asia|Southern Asia]] 
|-
| {{flagg|us*eft|pref=Crime in|Anguilla}} || 28.3 || 4 || 2014 || [[Americas]] || [[Latin America and the Caribbean]] 
|}

Using '''class=sort-under-right''':

{{static row numbers}}{{sticky header}}{{mw-datatable}}{{table alignment}}{{sort under}}
{| class="wikitable sortable static-row-numbers sticky-header mw-datatable col5left col6left sort-under-right" style=text-align:right;
|+Intentional homicide victims per 100,000 inhabitants. From [[United Nations Office on Drugs and Crime|UNODC]].
|-
! Location
! Rate
! Count
! Year
! [[UN region|Region]]
! [[UN subregion|Subregion]]
|-
| {{flagg|us*eft|pref=Crime in|Afghanistan}} || 4.0 || 1,613 || 2021 || [[Asia]] || [[United Nations geoscheme for Asia#Southern Asia|Southern Asia]] 
|-
| {{flagg|us*eft|pref=Crime in|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:

{{static row numbers}}{{sticky header}}{{mw-datatable}}{{table alignment}}
{| class="wikitable sortable static-row-numbers sticky-header mw-datatable col5left col6left" style=text-align:right;
|+Intentional homicide victims per 100,000 inhabitants. From [[United Nations Office on Drugs and Crime|UNODC]].
|-
! Location
! Rate
! Count
! Year
! [[UN region|Region]]
! [[UN subregion|Subregion]]
|- 
! style=background-position:left|<br>|| style=background-position:left| || style=background-position:left| || style=background-position:left| || style=background-position:left| || style=background-position:left|
|-
| {{flagg|us*eft|pref=Crime in|Afghanistan}} || 4.0 || 1,613 || 2021 || [[Asia]] || [[United Nations geoscheme for Asia#Southern Asia|Southern Asia]] 
|-
| {{flagg|us*eft|pref=Crime in|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?'''
 
<s>I now think we should only allow center alignment. To avoid unnecessary arguments and slow-going edit wars.</s>

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. --[[User:Timeshifter|'''Timeshifter''']] ([[User talk:Timeshifter|talk]]) 11:57, 4 February 2024 (UTC) '''Additions, changes, and strikeouts:''' --[[User:Timeshifter|'''Timeshifter''']] ([[User talk: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.<!--
--><p>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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 13:21, 4 February 2024 (UTC)</p>
::{{u|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:
::<syntaxhighlight lang=wikitext>
{{static row numbers}}{{sticky header}}{{sort under}}
{| class="wikitable sortable static-row-numbers sticky-header sort-under" 
</syntaxhighlight>
::And it is easier for less experienced table editors than me. The pattern is obvious. 
::--[[User:Timeshifter|'''Timeshifter''']] ([[User talk:Timeshifter|talk]]) 13:39, 4 February 2024 (UTC)
:::Sure. Having a shorter-name syntax to get the result won't break anything. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span>
::What do you mean by {{tq|"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? [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 16:39, 4 February 2024 (UTC)
:::I mean that if someone just uses a bare {{tlx|sort under}}, it should default to including what above is being called <code>class=sort-under-right</code> (with a proposed shorthand alias of <code>class=sort-under</code>). 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 {{tlx|sort under|center}} or {{tlx|sort under|align{{=}}center}} or {{tlx|sort under|center{{=}}yes}} or someting to that effect. And with a <code>right</code> version that can be explicitly specified without breaking anything. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 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. [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 00:00, 5 February 2024 (UTC)
:::::Oh well. It was an idea. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 00:48, 5 February 2024 (UTC)
::::::{{u|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. --[[User:Timeshifter|'''Timeshifter''']] ([[User talk:Timeshifter|talk]]) 06:34, 5 February 2024 (UTC)
:::::::{{re|Timeshifter}} If your question about adding a <code>sort-under</code> 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? [[User:Jroberson108|Jroberson108]] ([[User talk: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. [[User:Jroberson108|Jroberson108]] ([[User talk: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. --[[User:Timeshifter|'''Timeshifter''']] ([[User talk: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. [[User:Jroberson108|Jroberson108]] ([[User talk: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. --[[User:Timeshifter|'''Timeshifter''']] ([[User talk:Timeshifter|talk]]) 11:00, 5 February 2024 (UTC)
:::::::::::Ah, so this post was prior to the other. [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 11:02, 5 February 2024 (UTC)
:::::::::::{{re|Timeshifter}} What about this? {{tq|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. [[User:Jroberson108|Jroberson108]] ([[User talk: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. --[[User:Timeshifter|'''Timeshifter''']] ([[User talk:Timeshifter|talk]]) 11:46, 5 February 2024 (UTC)
:::::::::::::Seriously, it's a simple yes or no question. If yes, which ones. [[User:Jroberson108|Jroberson108]] ([[User talk: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. --[[User:Timeshifter|'''Timeshifter''']] ([[User talk:Timeshifter|talk]]) 12:04, 5 February 2024 (UTC)
:::::::::::::::So not sure. I haven't seen any either. [[User:Jroberson108|Jroberson108]] ([[User talk: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 <code>class=sort-under-right</code> and a <code>class=sort-under</code> 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 <code>class=sort-under</code> were later changed to be equivalent to <code>class=sort-under-center</code>, 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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 00:14, 6 February 2024 (UTC)
:::::::::::::::::{{re|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? [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 02:04, 6 February 2024 (UTC)
::::::::::::::::::{{u|SMcCandlish}} and {{u|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.  --[[User:Timeshifter|'''Timeshifter''']] ([[User talk:Timeshifter|talk]]) 09:12, 6 February 2024 (UTC)
:::::::::::::::::::{{re|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 {{tl|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 {{tl|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 {{tl|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. [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 17:32, 6 February 2024 (UTC)
::::::::::::::::::::For my part, it seems reasonable to have <code>sort-under</code> and <code>sort-under-center</code> as a centered variant of that, and maybe also a <code>sort-under-right</code> as a more specific name of the former, and they can just be specified inline at the same time: <code>.sort-under, .sort-under-right { ... }</code> having the shorter name available would be nice, though the world would not end without it. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 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. [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 23:08, 6 February 2024 (UTC)
:::::::::::::::::::::{{u|SMcCandlish}}. Another possibility that I am OK with is having only 2 classes (so no duplication): '''class=sort-under''' and '''class=sort-under-center.''' --[[User:Timeshifter|'''Timeshifter''']] ([[User talk: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 <code>sort-under-right</code> if <code>sort-under</code> 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 <code>short-under-right</code> 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. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 02:29, 7 February 2024 (UTC)
::::::::::::::::::::Sure, {{t|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 {{t|sort under}} as a suggested replacement. --[[User:Timeshifter|'''Timeshifter''']] ([[User talk: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. [[User:Jroberson108|Jroberson108]] ([[User talk: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 <code>sort-under</code> might have if multiple alignments exist. If only one alignment exists, then the shorter class name is preferred. [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 23:48, 4 February 2024 (UTC)
*::'''No on adding an extra <code>sort-under</code> 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 <code>sort-under-right</code> and <code>sort-under-center</code> 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 <code>sorttop</code> and <code>sortbottom</code> classes, and {{tl|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 <code>sort-under</code> changes later on. [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 05:10, 6 February 2024 (UTC)
*:::Please see my response to SMcCandlish above. '''[https://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3AManual_of_Style%2FTables&diff=1204049910&oldid=1203998427 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: '''{{t|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. --[[User:Timeshifter|'''Timeshifter''']] ([[User talk:Timeshifter|talk]]) 09:37, 6 February 2024 (UTC)
*::::Ugh, you brought up {{tl|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 {{tl|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 {{tl|table alignment}} and {{tl|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 {{tlc|table alignment}} had a <code>default</code> 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 <code>defaultright</code> without the documentation. You could if it was originally <code>defaultleft</code>, just change "left" to "right", which is so much easier. The same applies to this template, as I previously mentioned: {{tq|"hints at other alignment options at first glance without needing documentation"}}.
*::::{{tl|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 <code>sticky-header</code> class only works with sortable, shouldn't be used with sortable's <code>sorttop</code> 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 <code>sticky</code> 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 <code>sticky</code> class and applying new table classes to target the first or second row so that styles similar to <code>sticky-header</code> 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 <code>sticky-header-row1</code>, etc., which in this case are temporary depending on WikiMedia fixes (ex. move non-sortable headers to the <code>thead</code> 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. [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 21:21, 6 February 2024 (UTC)
*:::::{{u|SMcCandlish}} and {{u|Jroberson108}}. '''I am OK with just''' having '''class=sort-under''' and '''class=sort-under-center.''' Then there is '''no duplication.''' 
*:::::'''I created {{t|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 {{t|sticky header}} from its doc page. --[[User:Timeshifter|'''Timeshifter''']] ([[User talk: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. [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 23:25, 6 February 2024 (UTC)
*:::::::{{ping|SMcCandlish|Timeshifter|Isaidnoway}} Thanks for the suggestion on getting rid of the duplication issue. I think I can agree with having <code>sort-under</code> and <code>sort-under-center</code> 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. [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 23:42, 6 February 2024 (UTC)
*::::::::Thanks. It's all fine by me. --[[User:Timeshifter|'''Timeshifter''']] ([[User talk: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). [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 00:15, 7 February 2024 (UTC)
*::::::::::Those two options are fine by me, though I do not oppose <code>.sort-under, .sort-under-right { ... }</code> 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 <code>sort-under-center</code> can be changed to <code>sort-under-right</code> and be correct. But it's not something I would push strongly for, especially if just having <code>.sort-under { ... }</code> and <code>.sort-under-center { ... }</code> makes the dispute end. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 02:34, 7 February 2024 (UTC)
*:::::::::::{{re|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 <code>sort-under</code> (right aligned) to the current descriptive classes (duplication for more intuition) and OK with the current proposal. {{u|Timeshifter}}, since you proposed both, which do you prefer more? [[User:Jroberson108|Jroberson108]] ([[User talk: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. --[[User:Timeshifter|'''Timeshifter''']] ([[User talk: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 <code>.sort-under { ...</code> to <code>.sort-under, .sort-under-right { ...</code> so the same block of CSS is triggered by either class name. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 15:13, 8 February 2024 (UTC)
*::::::::::::::The un-[[Minification (programming)|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. [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 19:16, 8 February 2024 (UTC)
*:::::::::::::::{{re|Timeshifter|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 <code>sort-under</code> still exists, which is only fixable if we only allow one alignment or remove <code>sort-under</code>. [[User:Jroberson108|Jroberson108]] ([[User talk: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. [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 06:52, 9 February 2024 (UTC)
*My preference is the '''[[Template:Sort under#Default position not using this template|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.[[User:Isaidnoway|<b style="font-family:Times New Roman; color:black"> ''Isaidnoway'' </b>]][[User talk:Isaidnoway|<b style="font-family:Times New Roman; color:#FF5F1F">''(talk)''</b>]] 14:41, 4 February 2024 (UTC)
::{{u|Isaidnoway}}. For why this template was created by Jroberson108, see some of the reasons at '''[[Phab:T35249]],''' started in 2011 by {{u|TheDJ}}. 
::It helps with narrowing some tables so that they fit better in cell phones. And in contrast to {{t|sorting row}} it does not create a separate row of sorting icons. So {{t|sort under}} does not annoy people using screen readers. --[[User:Timeshifter|'''Timeshifter''']] ([[User talk: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]].[[User:Isaidnoway|<b style="font-family:Times New Roman; color:black"> ''Isaidnoway'' </b>]][[User talk:Isaidnoway|<b style="font-family:Times New Roman; color:#FF5F1F">''(talk)''</b>]] 21:58, 4 February 2024 (UTC)
::::{{re|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. [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 01:33, 5 February 2024 (UTC)
:::::{{re|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. 
:::::'''{{t|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 [[Wikipedia talk:Manual of Style/Accessibility/Data tables tutorial/Archive 2#Help:Sortable tables. Section about sorting buttons in a separate row. Accessibility questions|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."
:::::{{static row numbers}}{{sticky header}}{{mw-datatable}}{{table alignment}}{{sort under}}
:::::{| class="wikitable sortable sort-under static-row-numbers sticky-header mw-datatable col5left col6left" style=text-align:right;
|+Intentional homicide victims per 100,000 inhabitants. From [[United Nations Office on Drugs and Crime|UNODC]].
|-
! Location
! Rate
! Count
! Year
! [[UN region|Region]]
! [[UN subregion|Subregion]]
|- 
| {{flagg|us*eft|pref=Crime in|Afghanistan}} || 4.0 || 1,613 || 2021 || [[Asia]] || [[United Nations geoscheme for Asia#Southern Asia|Southern Asia]] 
|-
| {{flagg|us*eft|pref=Crime in|Anguilla}} || 28.3 || 4 || 2014 || [[Americas]] || [[Latin America and the Caribbean]] 
|}
:::::--[[User:Timeshifter|'''Timeshifter''']] ([[User talk:Timeshifter|talk]]) 07:06, 5 February 2024 (UTC)
*{{reply to|Jroberson108|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 [https://en.wikipedia.org/wiki/Help:Sortable_tables#Sorting_buttons_in_a_separate_row Help page] which Jroberson108 linked to above. Honestly, I have no idea what that editor meant by: {{tq|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. {{shrug}} 
: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 [[File:Sort both.svg|22px|Sort both]] sort up/down icons, so the screenreader automatically goes to the next row. Hope this helps.[[User:Isaidnoway|<b style="font-family:Times New Roman; color:black"> ''Isaidnoway'' </b>]][[User talk:Isaidnoway|<b style="font-family:Times New Roman; color:#FF5F1F">''(talk)''</b>]] 11:55, 5 February 2024 (UTC)
{{collapse top|title=Screenreader audio}}
{{Listen
| type         = spoken word
| help        = yes
| pos         = center
| image       = 
| filename     = Wikipedia talk Manual of Style Tables Template sort under.ogg
| title        = Manual of Style/Tables: Template:Sort under screen reader audio
| description  = 
| filename2    = Help Sortable tables Sorting buttons in a separate row.ogg
| title2       = Help:Sortable tables: Sorting buttons in a separate row screenreader audio
| description2 = 
}}
{{collapse bottom}}
::{{re|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. [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 12:09, 5 February 2024 (UTC)
::{{re|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. --[[User:Timeshifter|'''Timeshifter''']] ([[User talk: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 {{tag|br|s}} 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: [[List of current UFC fighters#Recent signings|recent signings]] or tables that use colors to convey information like seen here: [[2017–18 FC Red Bull Salzburg season#Results|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".[[User:Isaidnoway|<b style="font-family:Times New Roman; color:black"> ''Isaidnoway'' </b>]][[User talk:Isaidnoway|<b style="font-family:Times New Roman; color:#FF5F1F">''(talk)''</b>]] 13:19, 5 February 2024 (UTC)
::::{{u|Isaidnoway}} and all. Please see: [[Help talk:Table#Help:Table/Accessibility or Help:Accessibility of tables]]. --[[User:Timeshifter|'''Timeshifter''']] ([[User talk:Timeshifter|talk]]) 14:04, 5 February 2024 (UTC)
:::::{{re|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: <code>sort-under-center</code> and <code>sort-under-right</code>, 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 <code>sort-under</code> 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? [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 02:43, 6 February 2024 (UTC)
:::::{{u|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. --[[User:Timeshifter|'''Timeshifter''']] ([[User talk:Timeshifter|talk]]) 23:05, 6 February 2024 (UTC)
::::::{{re|Isaidnoway}} Thanks for your definitive answer. [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 23:14, 6 February 2024 (UTC)
:::::::{{re|Timeshifter}}, I just realized I misread this as {{u|Isaidnoway}}'s opinion. Hopefully Isaidnoway is in agreement. See my comments above. [[User:Jroberson108|Jroberson108]] ([[User talk: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 {{tl|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. [[User:Rjjiii|<span style="font-variant:small-caps;">Rjj<sup>iii</sup></span>]] ([[User talk:Rjjiii#top|talk]]) 03:59, 8 February 2024 (UTC)
:::::::::{{re|Rjjiii}} Thanks for the compliment. Glad to have someone else check the Android app. Thanks for indicating (right allow center, <code>sort-under</code> class OK), which matches consensus. Yeah, center was added because of {{tl|sorting row}}, but should be available otherwise. [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 04:41, 8 February 2024 (UTC)
::::::::::{{re|Rjjiii}} To clarify, the above proposal you responded to was the latest of a few. This discussion was to decide (summarized based on discussion):
::::::::::# Which alignments? (consensus and on template: right, center, no left)
::::::::::# Preferred alignment? (consensus: right)
::::::::::# Should a new <code>sort-under</code> class be added with preferred alignment (right)? (consensus: OK)
::::::::::# How the new class should be added (extra or replace <code>sort-under-right</code> class)? (almost finalized)
::::::::::[[User:Jroberson108|Jroberson108]] ([[User talk: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, [[User:Rjjiii|<span style="font-variant:small-caps;">Rjj<sup>iii</sup></span>]] ([[User talk:Rjjiii#top|talk]]) 03:48, 9 February 2024 (UTC)
::::::::::::{{re|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. [[User:Jroberson108|Jroberson108]] ([[User talk:Jroberson108|talk]]) 04:45, 9 February 2024 (UTC)
{{outdent}}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. --[[User:Timeshifter|'''Timeshifter''']] ([[User talk:Timeshifter|talk]]) 14:13, 9 February 2024 (UTC)

:{{re|Timeshifter}} Thanks for the compliment. Yes, you're the first. :) Also note, when {{tl|sticky header}} uses {{tl|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). [[User:Jroberson108|Jroberson108]] ([[User talk: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: [https://en.wikipedia.org/wiki/Snares_Islands#Islands];
:bottom-right on this table: [https://en.wikipedia.org/wiki/List_of_presidents_of_the_United_States_by_age#Presidential_age-related_data] and
:bottom-center on this table: [https://en.wikipedia.org/wiki/List_of_most-subscribed_YouTube_channels]
:Cheers
:[[User:Wizmut|Wizmut]] ([[User talk:Wizmut|talk]]) 02:52, 12 February 2024 (UTC)

== corp acquisitions ==

When a company has made many acquisitions, is it good style to put the info in a table, rather than rattle on about Abc was acquired for 1 pound in 1492, etc, etc - long list of 'em?  (I have [[Greystar]] in mind, but asking in general.) [[User:RememberOrwell|RememberOrwell]] ([[User talk:RememberOrwell|talk]]) 00:11, 24 April 2025 (UTC)
:{{re|RememberOrwell}} I think the current prose format works well for [[Greystar]] since there are a lot of details. 
:You might also add a simple right-floating table with a list of acquisitions and dates. See: [[Help:Table#Float table left or right]]. Or put that table at the end of the article without floating it left or right. --[[User:Timeshifter|'''Timeshifter''']] ([[User talk:Timeshifter|talk]]) 03:39, 24 April 2025 (UTC)

== Would a few of you mind taking a look at my paired tables on [[Invention Secrecy Act]]? ==

Down in this section:

* [[Invention Secrecy Act#Declassified Category Review Lists]]

Long story short, I'm reasonably sure I mentally twisted myself into knots trying to understand the best/correct way to format these for MOS--for future GA/FA work. I ''think'' it's supposed to look like that, but it feels wrong with the gray/white background split. 

If anyone wants, please, be all means, fix it if I boned it up, but also explain how I did? For some reason I keep getting stuck on this corner of MOS.  -- [[User:Very Polite Person|Very Polite Person]] ([[User talk:Very Polite Person|talk]]) 16:02, 30 May 2025 (UTC)