Wikipedia talk:Manual of Style/Tables

message: I am a little bit confused about this:
A: List of highest-grossing films
Rank	Film                        	Year	Director(s)       	Studio(s)                         	Worldwide gross	
1   	K.G.F: Chapter 1            	2018	Prashanth Neel    	Hombale Films                     	               	[1]
2   	Hebbuli                     	2017	S. Krishna        	SRV Productions                   	               	[2]
3   	Raajakumara                 	2017	Santhosh Ananddram	Hombale Productions               	               	[3]
4   	Kirik Party                 	2016	Rishab Shetty     	Paramvah Studios                  	               	[4]
4   	Mr. and Mrs. Ramachari      	2014	Santhosh Ananddram	Jayanna Combines                  	               	[5]
4   	Mungaru Male                	2006	Yogaraj Bhat      	E. K. Entertainers                	               	[6]
5   	Doddmane Hudga              	2016	Duniya Soori      	Ajay Pictures                     	               	[7]
5   	Krantiveera Sangolli Rayanna	2012	Naganna           	Sri Sangolli Rayanna Cine Combines	               	[8]
5   	Uppi 2                      	2015	Upendra           	Upendra Productions               	               	[9]
6   	Kotigobba 2                 	2016	K. S. Ravikumar   	Rambabu Productions               	–              	[10]
B: List of highest-grossing films
Rank	Film                        	Year	Director(s)       	Studio(s)                         	Worldwide gross	
1   	K.G.F: Chapter 1            	2018	Prashanth Neel    	Hombale Films                     	               	[1]
2   	Hebbuli                     	2017	S. Krishna        	SRV Productions                   	               	[2]
3   	Raajakumara                 	2017	Santhosh Ananddram	Hombale Productions               	               	[3]
4   	Kirik Party                 	2016	Rishab Shetty     	Paramvah Studios                  	               	[4]
4   	Mr. and Mrs. Ramachari      	2014	Santhosh Ananddram	Jayanna Combines                  	               	[5]
4   	Mungaru Male                	2006	Yogaraj Bhat      	E. K. Entertainers                	               	[6]
7   	Doddmane Hudga              	2016	Duniya Soori      	Ajay Pictures                     	               	[7]
7   	Krantiveera Sangolli Rayanna	2012	Naganna           	Sri Sangolli Rayanna Cine Combines	               	[8]
7   	Uppi 2                      	2015	Upendra           	Upendra Productions               	               	[9]
10  	Kotigobba 2                 	2016	K. S. Ravikumar   	Rambabu Productions               	–              	[10]
Which is correct? A and B? - Siddiqsazzad001 <Talk/> 05:48, 26 January 2019 (UTC)
replies: text: What is the difference? --Izno (talk) 14:55, 26 January 2019 (UTC)
replies: text:  B is correct. Kotigobba was the 10th highest, not the 6th highest, as there are nine films ahead of it. CUA 27 (talk) 21:13, 3 February 2019 (UTC)
replies: text: Yes, B is correct; the 7th through 9th items to appear in the list are all tied for 7th.  That said, it seems highly unlikely to me that more specific figures cannot be found, since obviously none of these film grosses would have been exactly tied and someone is rounding excessively.  So, the entire problem goes away if more precision is used.  — SMcCandlish ☏ ¢ 😼  08:48, 3 December 2019 (UTC)
thread_title:  Numbering 

message: Does anyone know what the MoS says about duplication of information in an article and table? An article I've been working on for a while had someone a few days ago remove several paragraphs because it the information could be found in the table below. Is it acceptable to duplicate that information or was the other user right to remove that? Kylesenior (talk) 08:53, 3 February 2019 (UTC)
replies: text: Per WP:RAWDATA "articles with statistics should include explanatory text providing context". CUA 27 (talk) 21:12, 3 February 2019 (UTC)
replies: text:  i definitely think accessibility is optimised by having info in multiple formats (paragraphs, tables, and diagrams), as long as it's not repeated in the same format. Can we say that explicitly somewhere so people have something to cite if their consecutive contributions get deleted? Irtapil (talk) 05:54, 7 May 2020 (UTC)
thread_title:  Duplication of information in article and table. 

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

message: I reverted 's addition last year saying:  Why should that be standard? What other publication left justifies tables instead of centring it horizontally across the page? Personally, I always felt the left-justified tables in Wikipedia look crude and amateurish. Guarapiranga (talk) 22:24, 26 November 2019 (UTC)
replies: text: And I've put it back, since it describes actual practice.  See also the WP:PROPOSAL-related banner at the top of this page.  If you want to change how 99.9% of WP's tables are done, then feel free to open an RfC about that.  The main reason we do not center tables and other such content here is WP:NOTPAPER. Centering works well in, say, a book or a magazine. Centered tables look like total crap on a wide monitor, and it's a usability/accessibility problem.  With small tables, the result can be downright confusing, and readers may actually miss the table completely.  — SMcCandlish ☏ ¢ 😼  18:09, 27 November 2019 (UTC)
thread_title:  <code>margin:auto</code> vs <code>margin-left:0</code> 

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

message: Here or somewhere else?--Prisencolin (talk) 06:32, 25 May 2020 (UTC)
replies: text: here is fine. I can take a look. --Izno (talk) 14:50, 25 May 2020 (UTC)
replies: text:  List_of_common_Chinese_surnames#Surname_list. Other than looking like an absolute mess, are there any specific MOS guidelines it violates? Can't imagine having text go past the actual width of the article whitespace isn't one of them...--Prisencolin (talk) 19:12, 25 May 2020 (UTC)
replies: text:  Well, that's a bit of a mess. Yes, I see some minor improvements to be made and I might take a try at them.Otherwise, on most skins, the width is not an issue, though it can be an annoyance (I browse on Timeless and I can say I am annoyed :). I doubt the utility of presenting 15-some-odd Romanizations (including the non-Chinese), as well as the 'ranking' of the names. --Izno (talk) 03:22, 27 May 2020 (UTC)

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

message: As far as I understand the guidelines, the primary info in a row should come first. In the case of filmography, this would be the film. Recently, I've noticed that several filmography FLCs have reverted to the year being the first-row header. I'm a bit confused as to which one is right, especially as we have an example of a filmography table on this page which has the film first. Filmographies do things one way, as seen here and discographies another, example here. My understanding is that the discography version is better for readers with accessibility issues, especially those using screen readers but I'm not 100% sure on this. Filmographies used to follow the example shown on the page but have recently reverted. My question is should the convention be for the primary source of information to come first to come, in this instance the film, or not? NapHit (talk) 20:44, 27 May 2020 (UTC)
replies: text:  The filmography example on Wikipedia:Manual of Style/Tables and the Aniston filmography both have rows beginning with the year and then the title.  Perhaps you instead meant to say discographies differ from the example? At any rate, this MOS seems to be presenting examples of how to use tables, as opposed to recommending a preferred version for a given domain. As far as accessibility, I think "scope" can be specified if the "primary info" is not in the first column.  That said, I would generally place the key that is used to sort the default table in the first column; however, I don't believe that is formalized in a written guideline.—Bagumba (talk) 04:12, 28 May 2020 (UTC)
replies: text:  Thanks for your response . The page I was referring was this page. They have a different style for filmographies than the one on this page. I was curious if there had been a discussion regarding this as the film used to come first in these tables. I think I was under the impression there was a formal guideline when it appears there wasn't and isn't one. I suppose if the film was specified as the scope that would be better than the year? NapHit (talk) 11:30, 28 May 2020 (UTC)
replies: text:  You might also consider leaving a notification about this at WP:FILMOGRAPHY. Regards.—Bagumba (talk) 11:35, 28 May 2020 (UTC)
replies: text:  I brought up the same question a couple of years ago (you can look above), and the conclusion is that in terms of accessibility it makes no difference. It's just a matter of style. Honestly though, the current version looks awkward. It gives emphasis to the year rather than the title itself. And with no rowspan in the years, it looks and reads even worse. The previous version's rationale could be easily interpreted as the titles being the main content with the years next to them as a kind of timeline of sorts to inform the reader. I would've preferred them stylized this way. ~ Arkhandar (message me) 00:00, 7 July 2020 (UTC)
thread_title:  Filmography v discography 

message: I came here since I'm reviewing a featured list candidate, List of Broadway Theaters, and I'm wondering which columns ought to have text be left-aligned and which ought to have it centered. There appears to be no guidance on that, though. What is the general/best practice? (please use  on reply)  talk 20:05, 5 September 2020 (UTC)
replies: text: 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. −Woodstone (talk) 06:16, 25 September 2020 (UTC)
thread_title:  Lacking guidance on left vs. center justification 

message: There is a discussion on Help_talk:Table#Use_of_em_and_%_values_in_preference_to_px_values about changing the examples to comply with the recommendations on the page that say to avoid using pixel sizes, if anyone is interested in weighing in. Schazjmd (talk) 15:20, 20 December 2020 (UTC)
replies: text: In the absence of comment, a draft of the proposed changes has been prepared. Please comment or edit here. SCHolar44 🇦🇺 💬 at 03:28, 18 January 2021 (UTC)
thread_title:  Discussion on [[Help_talk:Table#Use_of_em_and_%_values_in_preference_to_px_values]] 

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

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

message: As the title suggests, I'm wanting to fix the tables on the articles for the television show Hell's Kitchen- specifically, the contestant progress table on the respective season articles.
I'm not the best with coding, but most things I'm able to figure out. This however, I'm a bit stumped on. Basically, looking at the current version, you can see some extra space at the top left of the table, right above "No." and "Chef". I'm wanting to just have those two areas ("No." and "Chef") to be multiple row lengths, to get rid of that unnecessary blank space- something similar to the tables on The Masked Singer articles such as at The Masked Singer (American season 5)#Contestants.
Seems simple enough. However... looking at just how these tables are coded, it seems to be a bit trickier than I had originally anticipated. I think(?) the best progress I've gotten towards fixing this can be viewed at User:Magitroopa/sandbox/MasterChef (American TV series)#Hell's Kitchen, but can't seem to get the "Episodes", "Original teams", and episode numbers moved over. Any help solving this would be greatly appreciated, thanks in advance. Magitroopa (talk) 04:08, 22 June 2021 (UTC)
replies: text: Before you spend any more nanoseconds on this, Magitroopa, take the time to look at this RfC, in which the future (format/desirability/accessibility requirements) of such tables is being discussed. — JohnFromPinckney (talk / edits) 04:31, 22 June 2021 (UTC)
thread_title:  Fixing ''Hell's Kitchen'' tables 

message: ​I'm writing a new article about someone who has published 20+ books and articles. Should I do it as a table as shown in this article​: https://en.wikipedia.org/wiki/Bernard_Lewis_bibliography ​ or as a bullet point list, as I see in many places. Thank you. Steal the Kosher Bacon (talk) 13:15, 26 November 2021 (UTC)
replies: text: As a bullet point list, Sir Bacon. That Bernard Lewis bibliography is atrociously at odds with WP's style (which, as you said, we see in many places), and should merged into the author's article (which already contains mostly all of the content in its Bibliography section anway). — Guarapiranga ☎ 05:26, 9 June 2022 (UTC)
replies: text: thank you Steal the Kosher Bacon (talk) 04:41, 15 June 2022 (UTC)
thread_title:  Table vs list 

message: I looked for style guidance on totals and subtotals, and couldn't find any. Is there? I've seen totals being formatted in a myriad of forms; it could be good to apply some style consistency across enwiki. Things like:
* Should totals and subtotals be bolded, shaded or formatted as headings?
* What formatting (if any) should distinguish totals from subtotals?
* Should they be above or below the data they total?
— Guarapiranga ☎ 06:33, 9 June 2022 (UTC)
thread_title:  Totals and subtotals 

message: This edit got me curious. Is changing |style="text-align:left;" to |align=left best practice, or does it not matter? Mac Dreamstate (talk) 19:51, 2 October 2022 (UTC)
replies: text: I know I'm replying a bit late, but as far as I can tell the two work exactly the same way, so it does not matter. However, W3 has deprecated the  attribute according to this document, so if you have to choose, then  is better. ―Jochem van Hees (talk) 11:31, 3 May 2023 (UTC)
thread_title:  Use of "|style=" 

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

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

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

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

message: On Talk:List of winners of the Rotterdam Marathon, I'm having a discussion with another user about the use of abbreviations, tooltips, and legends in this list article. And I just discovered that earlier today this user has added a section to Wikipedia:Manual of Style/Tables in support of his argument. I've already noted this above in the section #Requirement for key? and on the talk page of the list article, but I would like to ask someone with experience writing in the Wikipedia namespace to weigh in and review the added section, because what is happening here doesn't seem right. – Editør (talk) 13:03, 10 January 2024 (UTC)
replies: text: Hi, that was me. My purpose in adding the guideline, is not to win an argument, but to document what seems to be a strong editor preference. Many keepers of the Manual of Style reject proposals for new guidelines if there haven't been any actual disputes, to minimize length. So I think it's normal for rules to be written to resolve disagreements that bubble up from talk pages, if the same questions arise for multiple articles. Sorry if I was too hasty drafting this new guideline, but based on the practice in featured lists and the discussions that had already happened, it seemed to me that consensus was pretty strong but just not documented. In general, I find bold, revert discuss saves a lot of time for non-controversial questions. I did ask other editors to review the new language by leaving a note above. I'm not in any hurry; we can give the new guidance time to settle and get discussed and tweaked (as is already happening). The new guideline does not propose legend-at-bottom-of-table, which is what I was arguing for, but legend-at-top-of-table, which is what researching featured lists and previous discussions turned up as the dominant practice, for good reasons I hadn't thought of. List of winners of the Rotterdam Marathon might not need a legend at all; other editors have proposed other solutions on its talk page that make the table accessible to all readers. I'm glad more folks have come along to help think this through. If the new guideline language ends up getting rejected, that would be surprising to me, but useful to know so I can more quickly find a desirable solution to such problems in the future. -- Beland (talk) 23:58, 11 January 2024 (UTC)
replies: text: That's definitely bad form; regardless of the intent, it  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  template for this purpose which does not abuse the  element, and have for many years. So, the material on that (if kept in any form) would have to be completely rewritten (and MOS:TOOLTIP might also need revision; I haven't checked). In the interim, I'm removing it as simply counterfactual.  — SMcCandlish ☏ ¢ 😼  05:37, 13 January 2024 (UTC)
replies: text: 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  or otherwise), because one solution often doesn't work for both. For the rest I am not planning to get involved in discussing this policy, I'll leave that up to you and others. – Editør (talk) 19:21, 13 January 2024 (UTC)
replies: text:  Interested in the  use cases. "Tell me more!" I've seen a similar interesting use of  (which provoked some controversy from one editor but which I think will eventually be good community-accepted advice about invisible-izing table captions that are simply repetitive of table headers).  — SMcCandlish ☏ ¢ 😼  13:32, 4 February 2024 (UTC)
replies: text: I don't have much info about this. I've tried to do some things with it, one thing seemed to work but another didn't. – Editør (talk) 12:10, 5 February 2024 (UTC)
thread_title:  Creating policy to support an argument