This is the
talk page for discussing improvements to the
Manual of Style/Tables page. |
|
Archives: 1, 2 |
Manual of Style | ||||||||||
|
Regarding vertical alignment in tables, I am wondering if there is any consensus on using them or not. I ask because when it comes to awards tables for films or actors, tables often default to middle alignment. However, I've noticed that this can be a problem in mobile view because a reader can see the award details in the right column before they can see what the film title is. So if there are numerous awards for a given film, a reader would have to scroll to the "center" of the group of rows to identify the film, then scroll back up to start actually understanding the awards. And as we know, mobile views make up the majority of views now, and I suspect it is even more for entertainment and arts-based articles. Does that make sense or not? I would like to encourage more use of vertical alignment but wanted to find out if there has been any kind of discussion like this before. Erik ( talk | contrib) ( ping me) 13:34, 5 January 2019 (UTC)
wikitable
class), then it should probably be submitted to
Phabricator instead of piecemeally added. --
Izno (
talk)
22:23, 7 January 2019 (UTC)
Hi! We're having a discussion on WP:VG regarding for gameography table formatting, in order to comply with the MOS and its design and accessibility rules. Upon showing this example to the group (as it is the closest to what we're after), some editors pointed out that it's non-standard in the way that rows start in the table's second cell (the title) rather than the first (year). What's you're input on this? Is the MOS wrong regarding this example? ~ Arkhandar ( message me) 11:01, 21 January 2019 (UTC)
Year | Title | Role | Notes |
---|---|---|---|
1961 | Barabbas | Patrician in Arena | uncredited |
Year | Title | Role | Notes |
---|---|---|---|
1961 | Barabbas | Patrician in Arena | uncredited |
When headers are not as in a simple table, they must use IDs and the headers attributes, and broadly, that's not the case. -- Izno ( talk) 04:06, 23 January 2019 (UTC)Note 1: For simple tables that have the headers in the first row or column then it is sufficient to simply use the TH elements without scope.
Note 2: For complex tables use ids and headers as in H43: Using id and headers attributes to associate data cells with header cells in data tables.
Note 3: Some users may find it easier to work with several simple tables than one more complex table. Authors may wish to consider whether they can convert complex tables to one or more simple tables.
I am a little bit confused about this:
A: List of highest-grossing films
Rank | Film | Year | Director(s) | Studio(s) | Worldwide gross | Ref. |
---|---|---|---|---|---|---|
1 | K.G.F: Chapter 1 | 2018 | Prashanth Neel | Hombale Films | ₹220 crore (US$26 million) | [1] |
2 | Hebbuli | 2017 | S. Krishna | SRV Productions | ₹100 crore (US$12 million) | [2] |
3 | Raajakumara | 2017 | Santhosh Ananddram | Hombale Productions | ₹75 crore (US$9.0 million) | [3] |
4 | Kirik Party | 2016 | Rishab Shetty | Paramvah Studios | ₹50 crore (US$6.0 million) | [4] |
Mr. and Mrs. Ramachari | 2014 | Santhosh Ananddram | Jayanna Combines | ₹50 crore (US$6.0 million) | [5] | |
Mungaru Male | 2006 | Yogaraj Bhat | E. K. Entertainers | ₹50 crore (US$6.0 million) | [6] | |
5 | Doddmane Hudga | 2016 | Duniya Soori | Ajay Pictures | ₹40 crore (US$4.8 million) | [7] |
Krantiveera Sangolli Rayanna | 2012 | Naganna | Sri Sangolli Rayanna Cine Combines | ₹40 crore (US$4.8 million) | [8] | |
Uppi 2 | 2015 | Upendra | Upendra Productions | ₹40 crore (US$4.8 million) | [9] | |
6 | Kotigobba 2 | 2016 | K. S. Ravikumar | Rambabu Productions | ₹35 crore (US$4.2 million)–₹38 crore (US$4.6 million) | [10] |
B: List of highest-grossing films
Rank | Film | Year | Director(s) | Studio(s) | Worldwide gross | Ref. |
---|---|---|---|---|---|---|
1 | K.G.F: Chapter 1 | 2018 | Prashanth Neel | Hombale Films | ₹220 crore (US$26 million) | [1] |
2 | Hebbuli | 2017 | S. Krishna | SRV Productions | ₹100 crore (US$12 million) | [2] |
3 | Raajakumara | 2017 | Santhosh Ananddram | Hombale Productions | ₹75 crore (US$9.0 million) | [3] |
4 | Kirik Party | 2016 | Rishab Shetty | Paramvah Studios | ₹50 crore (US$6.0 million) | [4] |
Mr. and Mrs. Ramachari | 2014 | Santhosh Ananddram | Jayanna Combines | ₹50 crore (US$6.0 million) | [5] | |
Mungaru Male | 2006 | Yogaraj Bhat | E. K. Entertainers | ₹50 crore (US$6.0 million) | [6] | |
7 | Doddmane Hudga | 2016 | Duniya Soori | Ajay Pictures | ₹40 crore (US$4.8 million) | [7] |
Krantiveera Sangolli Rayanna | 2012 | Naganna | Sri Sangolli Rayanna Cine Combines | ₹40 crore (US$4.8 million) | [8] | |
Uppi 2 | 2015 | Upendra | Upendra Productions | ₹40 crore (US$4.8 million) | [9] | |
10 | Kotigobba 2 | 2016 | K. S. Ravikumar | Rambabu Productions | ₹35 crore (US$4.2 million)–₹38 crore (US$4.6 million) | [10] |
Which is correct? A and B? - Siddiqsazzad001 <Talk/> 05:48, 26 January 2019 (UTC)
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)
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)
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.- Mr X 🖋 12:57, 27 March 2019 (UTC)
In my experience, left align works well for text and center align works well for numbers. The table formats in the examples in the article all look fine to me and should be a useful reference for readers. CUA 27 ( talk) 18:54, 30 March 2019 (UTC)
can look very good center-aligned(otherwise it not only looks horrible, but also hinders visual comparison). In fact, columns of decimals with the same number of digits before and after the decimal point can also look very good center-aligned, so it's the decimal point, actually, that needs to be aligned (whether explicit or implicit, as it is with integers). And there are templates to do this—e.g. {{ decimal cell}}, {{ decimal-align}}—when the figures don't come from the sources with the same number of decimal places, without making them appear to be more precise than they are there.
Wikipedia tables are are set flush-left, and allowed to grow rightward, not centered on the page, but not to say that numbers ought to be aligned at the decimal point, SMcCandlish. How come the arguments you laid out above apply here and not there? Guarapiranga ( talk) 10:41, 28 November 2019 (UTC)
left-aligns by default, that's not an
operational consensus, but simply the preference of whomever designed it (or perhaps even a behaviour that was created without any particular consideration, simply bc English is read from left to right). Guarapiranga ( talk) 10:46, 28 November 2019 (UTC)
we should not add new rules to an already over-long set of guidelines…
Wikipedia tables are are set flush-left, and allowed to grow rightward, not centered on the page. Good for thee, not for me? Guarapiranga ( talk) 00:24, 3 December 2019 (UTC)
E.g. Country or Countries? Guarapiranga ( talk) 23:52, 20 November 2019 (UTC)Í
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.
I reverted
SMcCandlish's addition last year saying: Wikipedia tables are are set flush-left, and allowed to grow rightward, not centered on the page.
Why should that be standard? What other publication left justifies tables instead of centring it horizontally across the page? Personally, I always felt the left-justified tables in Wikipedia look crude and amateurish.
Guarapiranga (
talk)
22:24, 26 November 2019 (UTC)
There is a section of this article that has bothered me for an extremely long time and I'd finally like to bring it up: the idea that prose is inherently preferable to tables. I find this to be nonsense of the highest order. Tables are fantastic for centralizing key pieces of information in a format that is quick and easy to parse. Prose is the exact opposite of that. Am I alone in this? I've felt insane for years because I've seen so many articles have useful tables removed and converted to prose that is nowhere near as useful. I have only ever seen this specific part of the guideline used to justify making articles worse, not better. Lazer-kitty ( talk) 19:26, 2 December 2019 (UTC)
Arriving slightly late to the conversation, but wanted to state that neither prose nor tables are inherently better as a blanket rule of thumb. I don’t think it’s productive to convert a useful table to prose just for the sake of it; a better approach may be to add text that explains the table. Certain subjects and information (e.g., sports) naturally lend themselves to table format. Many high-quality newspapers and magazines present sports information in tables. In conclusion, I would be fine with editing the prose section to state they are complements and one is not better than the other, and I’d also be fine with just deleting the entire section if the group cannot agree on the right language. CUA 27 ( talk) 05:17, 6 December 2019 (UTC)
That's clearly not the cases we're discussing. We're talking about tables with actual content. hi Guarapiranga ( talk) 22:31, 7 December 2019 (UTC)When to Use a Table
… Tables are just as valuable to someone who is blind as to someone who is sighted. They provide information about relationships, simply explaining how one piece of information relates to another, and how sets of information relate to one another. Tables also make it easier to sort through a lot of information more quickly.
When Not to Use a Table
The biggest problem is when a developer uses a table in order to format a page. …
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)
I thought this page has guidance on that, but it doesn't. Anyone has ideas? For example:
Usual | Table | Stuff | Here |
Random section header | |||
Usual | Table | Stuff | Here |
Random section header | |||
Usual | Table | Stuff | Here |
Howard the Duck ( talk) 16:26, 2 May 2020 (UTC)
Here or somewhere else?-- Prisencolin ( talk) 06:32, 25 May 2020 (UTC)
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)
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)
Filmographies used to follow the example shown on the page ...: The filmography example on Wikipedia:Manual of Style/Tables and the Aniston filmography both have rows beginning with the year and then the title. Perhaps you instead meant to say discographies differ from the example? At any rate, this MOS seems to be presenting examples of how to use tables, as opposed to recommending a preferred version for a given domain. As far as accessibility, I think "scope" can be specified if the "primary info" is not in the first column. That said, I would generally place the key that is used to sort the default table in the first column; however, I don't believe that is formalized in a written guideline.— Bagumba ( talk) 04:12, 28 May 2020 (UTC)
What is current best-practice for adding notes to tables, such as for defining/explaining headers, abbreviations, symbols, or formatting? Lots of filmography tables use a row background color and dagger symbol, with a separate "table" used to define its meaning, so it is not semantically connected. Some tables have fairly long column-titles for narrow contents, which makes the column wide and hard to track across visually. Sometimes a regular <tag|ref> is used (or a separate "notes" group), which makes the marker clickable but entails being scrolled all the way to the page end (and having to jump back again) for simple understanding of concise info. Rarely I see the ref-group immediately below the table, which seems the most useful place. But sometimes it's regular text (not clear that it's notes for the table) rather than small and width-matched to the table. And other times it's in a final row of the table itself (rowspan=X for full width), which makes the best formatting result but is semantically wrong and breaks with sortable tables. Rarely I've seen a container table or frame used to bind the ref-group to the table size and position, which also works, but is a bit of formatting abuse for something that seems so simple. DMacks ( talk) 03:05, 13 July 2020 (UTC)
<abbr>...</abbr>
or {{
abbr}}. Off the cuff, I think you could use this with symbols and the HTML semantics would be acceptable, but I am pretty sure I would not favor that use.summary
for tables that you can use, but it hides that explanation of table use away from sighted readers, which I believe is why it is deprecated. You really shouldn't use it.) --
Izno (
talk)
15:48, 13 July 2020 (UTC)I came here since I'm reviewing a featured list candidate,
List of Broadway Theaters, and I'm wondering which columns ought to have text be left-aligned and which ought to have it centered. There appears to be no guidance on that, though. What is the general/best practice? (please use {{
ping|Sdkb}}
on reply) {{u|
Sdkb}}
talk
20:05, 5 September 2020 (UTC)
{{
ping|Sdkb}}
−
Woodstone (
talk)
06:16, 25 September 2020 (UTC)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)
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)
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):
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:
1968 | Rosemary's Baby | Girl at Party | Film; uncredited |
---|---|---|---|
1968 | The Wrecking Crew | Freya Carlson | Film |
1968 | Rosemary's Baby | Girl at Party | Film; uncredited |
---|---|---|---|
1968 | The Wrecking Crew | Freya Carlson | Film |
Rosemary's Baby | 1968 | Girl at Party | Film; uncredited |
---|---|---|---|
The Wrecking Crew | 1968 | Freya Carlson | Film |
Here is a history of the two tables in question in MOS:TABLE, which may be useful:
I have placed notices of this discussion at WT:ACTOR (since this discussion concerns the guidance in WP:FILMOGRAPHY), at WT:DISCOG (for the same reason), and at WT:ACCESS and WT:WPACCESS. — Goszei ( talk) 06:38, 24 March 2021 (UTC)
scope="row"
to that column's entries (film names). That's (not coincidentally) the form we use in
WP:DISCOGSTYLE for the singles table.scope="row"
treatment, as in Exhibit A. It's kind of a compromise solution for (may I resprectfully say: stubborn/uneducated?) Wikipedia editors.scope="row"
into the 1st-column cells, so it "looks" "right".scope="row"
added. Then (says I), the "Multi-column mixed sortable unsortable" section should be changed, swapping Year and Title content, but leaving scope="row"
in the first row.<table>
. Meanwhile, putting rowheaders in mid-row (Exhibit A) is actually a screen-reader as well as a sighted-reader impediment to understanding. Exhibit B isn't a problem in alphabetical-by-subject tables, but is not helpful when our intent for a table is to be chronological, which is almost always the case for lists of works as well as for many other table types. That is, a "title title of the work must be rowheader and before the date and other data" is not a fixed rule we can sensibly impose.In short: The first column should contain the rowheaders, and should be whatever the table is sorted by (or default sorted by, in the case of re-sortable tables).
PS: Yes, I agree that the two (three?) guidelines, and any non-guideline style essays, all need to agree on whatever the final outcome of this discussion is, per
WP:POLICYFORK and
WP:ESSAYFORK.
—
SMcCandlish
☏
¢ 😼
03:34, 25 March 2021 (UTC)
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?
13 October 2020 2022 World Cup qualification | Bolivia | 1–2 | Argentina | La Paz, Bolivia |
16:00 UTC−4 |
|
Report |
|
Stadium:
Estadio Hernando Siles Attendance: 0 Referee: Diego Haro ( Peru) |
Hello, is the format above considered a kind of table that is recommended and not mandatory in sports articles, especially if the articles contain details and an extensive context? It seems to me that it can be considered a table. It also makes browsing such articles on mobile devices much easier. Thank you-- Sakiv ( talk) 22:17, 5 June 2021 (UTC)
Is there any guidance for using a key if a table uses abbreviations in its headers? For example, consider Template:NBA player statistics start, which uses basketball domain specific abbreviations. While it provides a tooltip, those are not accessible on mobile without a mouse (though apparently it's not an issue for screen readers per MOS:NOHOVER). The question has come up whether Template:NBA player statistics legend is overkill.— Bagumba ( talk) 13:32, 19 June 2021 (UTC)
The meaning indicated by color coding ... should be explained in a legend (also called a "key") accompanying the table.
accessible symbol matched to a legend, as indicated by MOS:COLOR.
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)
I don't see any guidance on the use of dashes in tables. In many instances, the emdash is used, but endashes also have a presence, though I'm uncertain if one style has prevalence over the other. Dawnseeker2000 18:00, 31 July 2021 (UTC)
I've recently come across an article which has long (>900 character) prose in several cells of a table. (It's NASA Astronaut Group 4.) Everything I can find in the MOS talks about putting information in prose versus in tables. To me, that means table entries aren't supposed to be prose, just things like short things like names, dates, etc. I also think lengthy prose in a table entry makes messes up the formatting and makes it hard to read. Is there any consensus on putting multiple sentences of prose in a single cell of a table? Fcrary ( talk) 23:39, 19 September 2021 (UTC)
Astronaut | Mission |
---|---|
Fred Flintstone | Apollo Stones |
Gemini Rocks | |
Soyuz Sands | |
Barney Rubble | Gemini Rocks |
Apollo Stones |
I am wondering if there is currently any guidance at all in the MOS about when to group cells in a table using rowspan
or colspan
? I've noticed that there are quite a bunch of wildly varying philosophies among editors about when to do so; I see some people group cells almost anytime they contain the same content, and others actively removing it because it makes the table look ugly. I think that having a dedicated section in the MOS could make these kinds of decisions a lot easier. ―
Jochem van Hees (
talk)
10:59, 25 October 2021 (UTC)
Country | Population | |
---|---|---|
amt | pct | |
The same can be said for row headings. Now, in relation to data cells, I'd say colspan can be used when the data is shared across fields (e.g. {{oldid2|1034694173|List of countries and dependencies by area), or rowspan when it's shared across records (presuming records are on rows; the other way around otherwise). — Guarapiranga ☎ 06:15, 9 June 2022 (UTC)
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: /info/en/?search=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)
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:
— Guarapiranga ☎ 06:33, 9 June 2022 (UTC)
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)
align
attribute according to
this document, so if you have to choose, then style="text-align: left;"
is better. ―
Jochem van Hees (
talk)
11:31, 3 May 2023 (UTC)Aurochs has an RFC 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)
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 /info/en/?search=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)
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)
Please see: Help talk:Table#Tool(s) for working with wikitables. — SMcCandlish ☏ ¢ 😼 03:37, 26 August 2023 (UTC)
4.4.1 Edit tables with the same attention given to text, and set them as text to be read.
Tables are notoriously time-consuming to typeset, but the problems posed are often editorial as much as typographic. If the table is not planned in a readable form to begin with, the typographer can render it readable only by rewriting or redesigning it from scratch.
Tables, like text, go awry when approached on a purely technical basis. Good typographic answers are not elicited by asking questions such as "How can I cram this number of characters into that amount of space?"
If the table is approached as merely one more form of text, which must be made both good to read and good to look at, [then] several principles will be clear:
1: All text should be horizontal, or in rare cases oblique. Setting column heads vertically as a space-saving measure is quite feasible if the text is in Japanese or Chinese, but not if it is written in the Latin alphabet. [1]
— Robert Bringhust, The elements of typographic style
References
Setting column titles vertically (and diagonally) has long been a facility of Microsoft Office; HTML 5 and CSS 3 introduced the technology for web pages;
Help:Tables#Vertically oriented column headers is a whole section of instructions on how to do vertical headers like this, and there is a template, {{
Vertical header}}
for doing it.
MOS:UNITNAMES (at the table "General guidelines on use of units") has an example of existing use. None of that excuses poor practice.
Has no-one considered the accessibility implications of this technique? Visitors with screen-readers at least have the advantage that the markup is ignored. When used in a book (despite being poor typographic practice), at least one can rotate the book: that is not so easy with a desktop screen; do so with a mobile and the OS helpful rotates the display in the opposite direction. Book typographers at least have the excuse of the physical dimensions of the paper size; no such constraint applies to a Wikipedia. We don't even have the excuse of "How can I cram this number of characters into that amount of space?"
This is to invite discussion on whether the MOS should at least discourage (preferably deprecate) the practice. (I will notify WT:MOSACCESS, Help talk:Table, Template talk:Vertical header of this debate.) 𝕁𝕄𝔽 ( talk) 17:07, 6 December 2023 (UTC)
{{
Tooltip}}
with {{
Abbr}}
. The latter is for abbreviations (including contractions); the former is for other kinds of annotations that are done as pop-up tooltips (and it does not misuse the underlying <abbr>...</abbr>
markup properly used by {{
abbr}}
). —
SMcCandlish
☏
¢ 😼
04:08, 7 December 2023 (UTC)<br />
as needed to break up a long header or other cell entry, and the more robust solution is to use CSS column-width controls. —
SMcCandlish
☏
¢ 😼
04:08, 7 December 2023 (UTC)column-width
or a key + an {{
abbr}}
eviated header. Does anyone have any first hand experience on how this technique plays with screen readers and the like?
Remsense
留
19:42, 10 December 2023 (UTC)
{{abbr}}
eviated text.
Jroberson108 (
talk)
19:51, 10 December 2023 (UTC)
<br>
, often removing the need to scroll horizontally, with a concomitant increase in comprehensibility.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)
{{
tooltip}}
template for this purpose which does not abuse the <abbr>
element, and have for many years. So, the material on that (if kept in any form) would have to be completely rewritten (and
MOS:TOOLTIP might also need revision; I haven't checked). In the interim, I'm removing it as simply counterfactual. —
SMcCandlish
☏
¢ 😼
05:37, 13 January 2024 (UTC)
{{
if mobile}}
use cases. "Tell me more!" I've seen a similar interesting use of {{
sronly}}
(which provoked some controversy from one editor but which I think will eventually be good community-accepted advice about invisible-izing table captions that are simply repetitive of table headers). —
SMcCandlish
☏
¢ 😼
13:32, 4 February 2024 (UTC)
First 2 tables below use {{ sort under}}. Unlike other methods it allows use of the data-sort-type=VALUE attribute (see Help:Sortable tables). And it is easy to use.
Using class=sort-under-center:
Location | Rate | Count | Year | Region | Subregion |
---|---|---|---|---|---|
Afghanistan * | 4.0 | 1,613 | 2021 | Asia | Southern Asia |
Anguilla | 28.3 | 4 | 2014 | Americas | Latin America and the Caribbean |
Using class=sort-under-right:
Location | Rate | Count | Year | Region | Subregion |
---|---|---|---|---|---|
Afghanistan * | 4.0 | 1,613 | 2021 | Asia | Southern Asia |
Anguilla | 28.3 | 4 | 2014 | Americas | Latin America and the Caribbean |
There is no class=sort-under-left yet. But here is a table with left-aligned sorting icons using a different method. Unfortunately it has borders just above the sorting icons:
Location | Rate | Count | Year | Region | Subregion |
---|---|---|---|---|---|
Afghanistan * | 4.0 | 1,613 | 2021 | Asia | Southern Asia |
Anguilla | 28.3 | 4 | 2014 | Americas | Latin America and the Caribbean |
My questions for this talk page:
I now think we should only allow center alignment. To avoid unnecessary arguments and slow-going edit wars.
No matter which alignment we choose now for class=sort-under, if we change our minds as a group later, it is easy to change it in the CSS. So all tables using class=sort-under will change to the new choice. -- Timeshifter ( talk) 11:57, 4 February 2024 (UTC) Additions, changes, and strikeouts: -- Timeshifter ( talk) 09:47, 5 February 2024 (UTC)
General commentary from another thread about this: I would suggest that more options are better, but only up to a point (
KISS principle; and the observation than a left-aligned version of such a control widget would not be of use in an LTR language is probably correct). Concision in class, parameter, and other names is generally better (may be pertinent to both the template parameter code and the TemplateStyles material), but also just up to a point (they need to still be intelligible). Default behavior of the template should probably be what best matches default appearance of sortable wikitable controls (principle of least astonishment; here that would be right alignment). If some particular variant is expected to be needed over and over again, make a simple template wrapper that does that version with a shorthand name that doesn't require lots of parameter futzing. —
SMcCandlish
☏
¢ 😼
13:21, 4 February 2024 (UTC)
{{static row numbers}}{{sticky header}}{{sort under}}
{| class="wikitable sortable static-row-numbers sticky-header sort-under"
"Allow at least right and center to be parameter-specifiable, but default right."? A class has to be added to use this template. Does "default" mean sortable without the use of this template? Jroberson108 ( talk) 16:39, 4 February 2024 (UTC)
{{
sort under}}
, it should default to including what above is being called class=sort-under-right
(with a proposed shorthand alias of class=sort-under
). People should not have to manually add a class when doing something by default would be sensible. And for editors who are not CSS experts, it would be sensible to support a simple template-parameter syntax like {{
sort under|center}}
or {{
sort under|align=center}}
or {{
sort under|center=yes}}
or someting to that effect. And with a right
version that can be explicitly specified without breaking anything. —
SMcCandlish
☏
¢ 😼
23:45, 4 February 2024 (UTC)
sort-under
class that duplicates another class's styles is relevant to this RfC, then it should be added to the top with the other questions for equal consideration instead of having what appears to be a side conversation with a select individual. You already requested it on the template's talk page, so I'm not sure why you didn't add something you wanted to the questions? I may be opposed to it mainly because it adds an extra 16 CSS selectors (thus far) to
Template:Sort under/styles.css and adds ambiguity for what appears to be a very minor and debatable improvement, but I follow consensus.Are there any other templates that duplicate styles like this for something like a "popular choice" or is this a first?If some exist, then at least there is a live example that might be referenced in that other discussion. Jroberson108 ( talk) 11:20, 5 February 2024 (UTC)
class=sort-under-right
and a class=sort-under
that do the same thing, the latter being a shorthand form. The only issue I could see arising is if we settled on right as the default (and that's clearly going to happen), then if class=sort-under
were later changed to be equivalent to class=sort-under-center
, then a whole bunch of tables would suddenly change (because people are apt to prefer the shorter syntax) and this would piss people off. But that's ultimately not any different from making any other sudden display change to template output. I.e., there's nothing unique about the matter. —
SMcCandlish
☏
¢ 😼
00:14, 6 February 2024 (UTC)
sort-under
and sort-under-center
as a centered variant of that, and maybe also a sort-under-right
as a more specific name of the former, and they can just be specified inline at the same time: .sort-under, .sort-under-right { ... }
having the shorter name available would be nice, though the world would not end without it. —
SMcCandlish
☏
¢ 😼
20:20, 6 February 2024 (UTC)
sort-under-right
if sort-under
will do. However, I'm aware that various people are OCD in ways different from me, and may grit their teeth about the lack of a short-under-right
that is specific. It is completely harmless to give them that longer and more detailed class name to get at the same result as the short version. It's certainly not worth all this argument. People get rankled when they lack options. "Somone gave me a choice?! To hell with that!" is not a common reaction, in any sphere. —
SMcCandlish
☏
¢ 😼
02:29, 7 February 2024 (UTC)sort-under
might have if multiple alignments exist. If only one alignment exists, then the shorter class name is preferred.
Jroberson108 (
talk)
23:48, 4 February 2024 (UTC)
sort-under
class. It introduces ambiguity, especially if seen used in an article where, if you are unfamiliar with the template, you cannot tell right away that other alignments are possible without needing to reference the documentation. The sort-under-right
and sort-under-center
classes clearly and sufficiently describe their alignments and, when only one is seen in code, hints at other alignment options at first glance without needing documentation, just like sortable's sorttop
and sortbottom
classes, and {{
Table alignment}}'s classes. It is unlikely that someone is going to have any trouble using the more descriptive class names if all they are doing is copying and pasting code. The documentation has two easy to understand options, so it's already clear without the added complication. I feel duplication is a bad practice, which would add 16 additional CSS selectors (thus far) to the styles at
Template:Sort under/styles.css. If adding it offers any improved usage of the template, it's very minor and debatable since someone is either copying code, already familiar with the template, or looking at the easy-to-understand documentation. Not worth the overhead, added ambiguity, and, as SMcCandlish pointed out, "pissing people off" if the expected alignment of sort-under
changes later on.
Jroberson108 (
talk)
05:10, 6 February 2024 (UTC)
{{table alignment}}
had a default
class set to "left" alignment and you weren't familiar with the other classes. You wouldn't intuitively know that other alignment options exist or what to change it to if you want defaultright
without the documentation. You could if it was originally defaultleft
, just change "left" to "right", which is so much easier. The same applies to this template, as I previously mentioned: "hints at other alignment options at first glance without needing documentation".
sticky-header
class only works with sortable, shouldn't be used with sortable's sorttop
class, and requires adjustments if there are subsections. When you can't use the template in this way, you alternatively have to add a different sticky
class to make exactly one row top-sticky, added to the row instead of the table (different implementation). It's new and there could be other unknown issues. Those are some very strict, complex, and hard-to-remember usage cases compared to all the other templates I've seen, even if you are only using the class that is named similar to the template. Not to personalize or offend, but you already demonstrated this in
Template_talk:Sticky header#Why does this not work on this table?, and, as I recall, made the "It only works on sortable tables." warning more prominent in the doc lead so you wouldn't forget. Per its talk, that template is still in need of fixes that can change both the class name and implementation such as deprecating the old row sticky
class and applying new table classes to target the first or second row so that styles similar to sticky-header
can be applied to the table as a whole to fix other things like borders. If fixed, it would have multiple "main" classes that don't have identical styling, for example new sticky-header-row1
, etc., which in this case are temporary depending on WikiMedia fixes (ex. move non-sortable headers to the thead
element). Since they don't duplicate, its acceptable to name the non-temporary "main" class the same as the template (dashed).sort-under
and sort-under-center
classes, now that we know right is preferred, although my "ideal" preference still remains the current classes for the intuitive reasons mentioned above. Not sure if this RfC should remain open for more comments or closed and moved to the relevant template talk page?.sort-under, .sort-under-right { ... }
so the more specific version is available. I tend to prefer that, since it'll make a certain kind of OCD happier, and people unfamiliar with the template's guts can also just guess that sort-under-center
can be changed to sort-under-right
and be correct. But it's not something I would push strongly for, especially if just having .sort-under { ... }
and .sort-under-center { ... }
makes the dispute end. —
SMcCandlish
☏
¢ 😼
02:34, 7 February 2024 (UTC)
sort-under
(right aligned) to the current descriptive classes (duplication for more intuition) and OK with the current proposal.
Timeshifter, since you proposed both, which do you prefer more?
Jroberson108 (
talk)
04:30, 8 February 2024 (UTC)
.sort-under { ...
to .sort-under, .sort-under-right { ...
so the same block of CSS is triggered by either class name. —
SMcCandlish
☏
¢ 😼
15:13, 8 February 2024 (UTC)
sort-under
still exists, which is only fixable if we only allow one alignment or remove sort-under
.
Jroberson108 (
talk)
05:04, 9 February 2024 (UTC)Location | Rate | Count | Year | Region | Subregion |
---|---|---|---|---|---|
Afghanistan * | 4.0 | 1,613 | 2021 | Asia | Southern Asia |
Anguilla | 28.3 | 4 | 2014 | Americas | Latin America and the Caribbean |
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. ¯\_(ツ)_/¯
Screenreader audio
|
---|
<br />
tags were used to emulate rows (I've since fixed them). Off topic: another issue for screenreaders is when only flag icons are used, like seen here:
recent signings or tables that use colors to convey information like seen here:
results. Screenreaders can't read flag icons or colors, so those tables are not accessibility compliant.sort-under-center
and sort-under-right
, with a preference for "right", which both SMcCandlish and I clearly see. The new option that Timeshifter wants is to add a third shorter class name called sort-under
that would have identical styling with the preferred style (right). Basically two classes align right and one aligns center. He added his reasons above, which is mainly to make the template easier to use. So, the same pointed question I asked SMcCandlish. Are the current descriptive class names and the documentation sufficient for using this template or does this new short class need to be added to improve the template's usage according to Timeshifter's or other reasons and why?
Jroberson108 (
talk)
02:43, 6 February 2024 (UTC)sort-under
class OK), which matches consensus. Yeah, center was added because of {{
sorting row}}, but should be available otherwise.
Jroberson108 (
talk)
04:41, 8 February 2024 (UTC)
sort-under
class be added with preferred alignment (right)? (consensus: OK)sort-under-right
class)? (almost finalized)Thanks. Woohoo! I added the first use of the template in article space. See the main table here:
Note also that the total vertical height of the sticky header is now a little less than before. That is good for cell phones. Especially when there is more than one line of text in the header. Every little bit less is helpful. This country table header has only line of text by having the rate info in the caption. Moving stuff to the caption is a good way to lower the number of lines in table headers. -- Timeshifter ( talk) 14:13, 9 February 2024 (UTC)
This is the
talk page for discussing improvements to the
Manual of Style/Tables page. |
|
Archives: 1, 2 |
Manual of Style | ||||||||||
|
Regarding vertical alignment in tables, I am wondering if there is any consensus on using them or not. I ask because when it comes to awards tables for films or actors, tables often default to middle alignment. However, I've noticed that this can be a problem in mobile view because a reader can see the award details in the right column before they can see what the film title is. So if there are numerous awards for a given film, a reader would have to scroll to the "center" of the group of rows to identify the film, then scroll back up to start actually understanding the awards. And as we know, mobile views make up the majority of views now, and I suspect it is even more for entertainment and arts-based articles. Does that make sense or not? I would like to encourage more use of vertical alignment but wanted to find out if there has been any kind of discussion like this before. Erik ( talk | contrib) ( ping me) 13:34, 5 January 2019 (UTC)
wikitable
class), then it should probably be submitted to
Phabricator instead of piecemeally added. --
Izno (
talk)
22:23, 7 January 2019 (UTC)
Hi! We're having a discussion on WP:VG regarding for gameography table formatting, in order to comply with the MOS and its design and accessibility rules. Upon showing this example to the group (as it is the closest to what we're after), some editors pointed out that it's non-standard in the way that rows start in the table's second cell (the title) rather than the first (year). What's you're input on this? Is the MOS wrong regarding this example? ~ Arkhandar ( message me) 11:01, 21 January 2019 (UTC)
Year | Title | Role | Notes |
---|---|---|---|
1961 | Barabbas | Patrician in Arena | uncredited |
Year | Title | Role | Notes |
---|---|---|---|
1961 | Barabbas | Patrician in Arena | uncredited |
When headers are not as in a simple table, they must use IDs and the headers attributes, and broadly, that's not the case. -- Izno ( talk) 04:06, 23 January 2019 (UTC)Note 1: For simple tables that have the headers in the first row or column then it is sufficient to simply use the TH elements without scope.
Note 2: For complex tables use ids and headers as in H43: Using id and headers attributes to associate data cells with header cells in data tables.
Note 3: Some users may find it easier to work with several simple tables than one more complex table. Authors may wish to consider whether they can convert complex tables to one or more simple tables.
I am a little bit confused about this:
A: List of highest-grossing films
Rank | Film | Year | Director(s) | Studio(s) | Worldwide gross | Ref. |
---|---|---|---|---|---|---|
1 | K.G.F: Chapter 1 | 2018 | Prashanth Neel | Hombale Films | ₹220 crore (US$26 million) | [1] |
2 | Hebbuli | 2017 | S. Krishna | SRV Productions | ₹100 crore (US$12 million) | [2] |
3 | Raajakumara | 2017 | Santhosh Ananddram | Hombale Productions | ₹75 crore (US$9.0 million) | [3] |
4 | Kirik Party | 2016 | Rishab Shetty | Paramvah Studios | ₹50 crore (US$6.0 million) | [4] |
Mr. and Mrs. Ramachari | 2014 | Santhosh Ananddram | Jayanna Combines | ₹50 crore (US$6.0 million) | [5] | |
Mungaru Male | 2006 | Yogaraj Bhat | E. K. Entertainers | ₹50 crore (US$6.0 million) | [6] | |
5 | Doddmane Hudga | 2016 | Duniya Soori | Ajay Pictures | ₹40 crore (US$4.8 million) | [7] |
Krantiveera Sangolli Rayanna | 2012 | Naganna | Sri Sangolli Rayanna Cine Combines | ₹40 crore (US$4.8 million) | [8] | |
Uppi 2 | 2015 | Upendra | Upendra Productions | ₹40 crore (US$4.8 million) | [9] | |
6 | Kotigobba 2 | 2016 | K. S. Ravikumar | Rambabu Productions | ₹35 crore (US$4.2 million)–₹38 crore (US$4.6 million) | [10] |
B: List of highest-grossing films
Rank | Film | Year | Director(s) | Studio(s) | Worldwide gross | Ref. |
---|---|---|---|---|---|---|
1 | K.G.F: Chapter 1 | 2018 | Prashanth Neel | Hombale Films | ₹220 crore (US$26 million) | [1] |
2 | Hebbuli | 2017 | S. Krishna | SRV Productions | ₹100 crore (US$12 million) | [2] |
3 | Raajakumara | 2017 | Santhosh Ananddram | Hombale Productions | ₹75 crore (US$9.0 million) | [3] |
4 | Kirik Party | 2016 | Rishab Shetty | Paramvah Studios | ₹50 crore (US$6.0 million) | [4] |
Mr. and Mrs. Ramachari | 2014 | Santhosh Ananddram | Jayanna Combines | ₹50 crore (US$6.0 million) | [5] | |
Mungaru Male | 2006 | Yogaraj Bhat | E. K. Entertainers | ₹50 crore (US$6.0 million) | [6] | |
7 | Doddmane Hudga | 2016 | Duniya Soori | Ajay Pictures | ₹40 crore (US$4.8 million) | [7] |
Krantiveera Sangolli Rayanna | 2012 | Naganna | Sri Sangolli Rayanna Cine Combines | ₹40 crore (US$4.8 million) | [8] | |
Uppi 2 | 2015 | Upendra | Upendra Productions | ₹40 crore (US$4.8 million) | [9] | |
10 | Kotigobba 2 | 2016 | K. S. Ravikumar | Rambabu Productions | ₹35 crore (US$4.2 million)–₹38 crore (US$4.6 million) | [10] |
Which is correct? A and B? - Siddiqsazzad001 <Talk/> 05:48, 26 January 2019 (UTC)
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)
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)
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.- Mr X 🖋 12:57, 27 March 2019 (UTC)
In my experience, left align works well for text and center align works well for numbers. The table formats in the examples in the article all look fine to me and should be a useful reference for readers. CUA 27 ( talk) 18:54, 30 March 2019 (UTC)
can look very good center-aligned(otherwise it not only looks horrible, but also hinders visual comparison). In fact, columns of decimals with the same number of digits before and after the decimal point can also look very good center-aligned, so it's the decimal point, actually, that needs to be aligned (whether explicit or implicit, as it is with integers). And there are templates to do this—e.g. {{ decimal cell}}, {{ decimal-align}}—when the figures don't come from the sources with the same number of decimal places, without making them appear to be more precise than they are there.
Wikipedia tables are are set flush-left, and allowed to grow rightward, not centered on the page, but not to say that numbers ought to be aligned at the decimal point, SMcCandlish. How come the arguments you laid out above apply here and not there? Guarapiranga ( talk) 10:41, 28 November 2019 (UTC)
left-aligns by default, that's not an
operational consensus, but simply the preference of whomever designed it (or perhaps even a behaviour that was created without any particular consideration, simply bc English is read from left to right). Guarapiranga ( talk) 10:46, 28 November 2019 (UTC)
we should not add new rules to an already over-long set of guidelines…
Wikipedia tables are are set flush-left, and allowed to grow rightward, not centered on the page. Good for thee, not for me? Guarapiranga ( talk) 00:24, 3 December 2019 (UTC)
E.g. Country or Countries? Guarapiranga ( talk) 23:52, 20 November 2019 (UTC)Í
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.
I reverted
SMcCandlish's addition last year saying: Wikipedia tables are are set flush-left, and allowed to grow rightward, not centered on the page.
Why should that be standard? What other publication left justifies tables instead of centring it horizontally across the page? Personally, I always felt the left-justified tables in Wikipedia look crude and amateurish.
Guarapiranga (
talk)
22:24, 26 November 2019 (UTC)
There is a section of this article that has bothered me for an extremely long time and I'd finally like to bring it up: the idea that prose is inherently preferable to tables. I find this to be nonsense of the highest order. Tables are fantastic for centralizing key pieces of information in a format that is quick and easy to parse. Prose is the exact opposite of that. Am I alone in this? I've felt insane for years because I've seen so many articles have useful tables removed and converted to prose that is nowhere near as useful. I have only ever seen this specific part of the guideline used to justify making articles worse, not better. Lazer-kitty ( talk) 19:26, 2 December 2019 (UTC)
Arriving slightly late to the conversation, but wanted to state that neither prose nor tables are inherently better as a blanket rule of thumb. I don’t think it’s productive to convert a useful table to prose just for the sake of it; a better approach may be to add text that explains the table. Certain subjects and information (e.g., sports) naturally lend themselves to table format. Many high-quality newspapers and magazines present sports information in tables. In conclusion, I would be fine with editing the prose section to state they are complements and one is not better than the other, and I’d also be fine with just deleting the entire section if the group cannot agree on the right language. CUA 27 ( talk) 05:17, 6 December 2019 (UTC)
That's clearly not the cases we're discussing. We're talking about tables with actual content. hi Guarapiranga ( talk) 22:31, 7 December 2019 (UTC)When to Use a Table
… Tables are just as valuable to someone who is blind as to someone who is sighted. They provide information about relationships, simply explaining how one piece of information relates to another, and how sets of information relate to one another. Tables also make it easier to sort through a lot of information more quickly.
When Not to Use a Table
The biggest problem is when a developer uses a table in order to format a page. …
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)
I thought this page has guidance on that, but it doesn't. Anyone has ideas? For example:
Usual | Table | Stuff | Here |
Random section header | |||
Usual | Table | Stuff | Here |
Random section header | |||
Usual | Table | Stuff | Here |
Howard the Duck ( talk) 16:26, 2 May 2020 (UTC)
Here or somewhere else?-- Prisencolin ( talk) 06:32, 25 May 2020 (UTC)
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)
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)
Filmographies used to follow the example shown on the page ...: The filmography example on Wikipedia:Manual of Style/Tables and the Aniston filmography both have rows beginning with the year and then the title. Perhaps you instead meant to say discographies differ from the example? At any rate, this MOS seems to be presenting examples of how to use tables, as opposed to recommending a preferred version for a given domain. As far as accessibility, I think "scope" can be specified if the "primary info" is not in the first column. That said, I would generally place the key that is used to sort the default table in the first column; however, I don't believe that is formalized in a written guideline.— Bagumba ( talk) 04:12, 28 May 2020 (UTC)
What is current best-practice for adding notes to tables, such as for defining/explaining headers, abbreviations, symbols, or formatting? Lots of filmography tables use a row background color and dagger symbol, with a separate "table" used to define its meaning, so it is not semantically connected. Some tables have fairly long column-titles for narrow contents, which makes the column wide and hard to track across visually. Sometimes a regular <tag|ref> is used (or a separate "notes" group), which makes the marker clickable but entails being scrolled all the way to the page end (and having to jump back again) for simple understanding of concise info. Rarely I see the ref-group immediately below the table, which seems the most useful place. But sometimes it's regular text (not clear that it's notes for the table) rather than small and width-matched to the table. And other times it's in a final row of the table itself (rowspan=X for full width), which makes the best formatting result but is semantically wrong and breaks with sortable tables. Rarely I've seen a container table or frame used to bind the ref-group to the table size and position, which also works, but is a bit of formatting abuse for something that seems so simple. DMacks ( talk) 03:05, 13 July 2020 (UTC)
<abbr>...</abbr>
or {{
abbr}}. Off the cuff, I think you could use this with symbols and the HTML semantics would be acceptable, but I am pretty sure I would not favor that use.summary
for tables that you can use, but it hides that explanation of table use away from sighted readers, which I believe is why it is deprecated. You really shouldn't use it.) --
Izno (
talk)
15:48, 13 July 2020 (UTC)I came here since I'm reviewing a featured list candidate,
List of Broadway Theaters, and I'm wondering which columns ought to have text be left-aligned and which ought to have it centered. There appears to be no guidance on that, though. What is the general/best practice? (please use {{
ping|Sdkb}}
on reply) {{u|
Sdkb}}
talk
20:05, 5 September 2020 (UTC)
{{
ping|Sdkb}}
−
Woodstone (
talk)
06:16, 25 September 2020 (UTC)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)
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)
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):
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:
1968 | Rosemary's Baby | Girl at Party | Film; uncredited |
---|---|---|---|
1968 | The Wrecking Crew | Freya Carlson | Film |
1968 | Rosemary's Baby | Girl at Party | Film; uncredited |
---|---|---|---|
1968 | The Wrecking Crew | Freya Carlson | Film |
Rosemary's Baby | 1968 | Girl at Party | Film; uncredited |
---|---|---|---|
The Wrecking Crew | 1968 | Freya Carlson | Film |
Here is a history of the two tables in question in MOS:TABLE, which may be useful:
I have placed notices of this discussion at WT:ACTOR (since this discussion concerns the guidance in WP:FILMOGRAPHY), at WT:DISCOG (for the same reason), and at WT:ACCESS and WT:WPACCESS. — Goszei ( talk) 06:38, 24 March 2021 (UTC)
scope="row"
to that column's entries (film names). That's (not coincidentally) the form we use in
WP:DISCOGSTYLE for the singles table.scope="row"
treatment, as in Exhibit A. It's kind of a compromise solution for (may I resprectfully say: stubborn/uneducated?) Wikipedia editors.scope="row"
into the 1st-column cells, so it "looks" "right".scope="row"
added. Then (says I), the "Multi-column mixed sortable unsortable" section should be changed, swapping Year and Title content, but leaving scope="row"
in the first row.<table>
. Meanwhile, putting rowheaders in mid-row (Exhibit A) is actually a screen-reader as well as a sighted-reader impediment to understanding. Exhibit B isn't a problem in alphabetical-by-subject tables, but is not helpful when our intent for a table is to be chronological, which is almost always the case for lists of works as well as for many other table types. That is, a "title title of the work must be rowheader and before the date and other data" is not a fixed rule we can sensibly impose.In short: The first column should contain the rowheaders, and should be whatever the table is sorted by (or default sorted by, in the case of re-sortable tables).
PS: Yes, I agree that the two (three?) guidelines, and any non-guideline style essays, all need to agree on whatever the final outcome of this discussion is, per
WP:POLICYFORK and
WP:ESSAYFORK.
—
SMcCandlish
☏
¢ 😼
03:34, 25 March 2021 (UTC)
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?
13 October 2020 2022 World Cup qualification | Bolivia | 1–2 | Argentina | La Paz, Bolivia |
16:00 UTC−4 |
|
Report |
|
Stadium:
Estadio Hernando Siles Attendance: 0 Referee: Diego Haro ( Peru) |
Hello, is the format above considered a kind of table that is recommended and not mandatory in sports articles, especially if the articles contain details and an extensive context? It seems to me that it can be considered a table. It also makes browsing such articles on mobile devices much easier. Thank you-- Sakiv ( talk) 22:17, 5 June 2021 (UTC)
Is there any guidance for using a key if a table uses abbreviations in its headers? For example, consider Template:NBA player statistics start, which uses basketball domain specific abbreviations. While it provides a tooltip, those are not accessible on mobile without a mouse (though apparently it's not an issue for screen readers per MOS:NOHOVER). The question has come up whether Template:NBA player statistics legend is overkill.— Bagumba ( talk) 13:32, 19 June 2021 (UTC)
The meaning indicated by color coding ... should be explained in a legend (also called a "key") accompanying the table.
accessible symbol matched to a legend, as indicated by MOS:COLOR.
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)
I don't see any guidance on the use of dashes in tables. In many instances, the emdash is used, but endashes also have a presence, though I'm uncertain if one style has prevalence over the other. Dawnseeker2000 18:00, 31 July 2021 (UTC)
I've recently come across an article which has long (>900 character) prose in several cells of a table. (It's NASA Astronaut Group 4.) Everything I can find in the MOS talks about putting information in prose versus in tables. To me, that means table entries aren't supposed to be prose, just things like short things like names, dates, etc. I also think lengthy prose in a table entry makes messes up the formatting and makes it hard to read. Is there any consensus on putting multiple sentences of prose in a single cell of a table? Fcrary ( talk) 23:39, 19 September 2021 (UTC)
Astronaut | Mission |
---|---|
Fred Flintstone | Apollo Stones |
Gemini Rocks | |
Soyuz Sands | |
Barney Rubble | Gemini Rocks |
Apollo Stones |
I am wondering if there is currently any guidance at all in the MOS about when to group cells in a table using rowspan
or colspan
? I've noticed that there are quite a bunch of wildly varying philosophies among editors about when to do so; I see some people group cells almost anytime they contain the same content, and others actively removing it because it makes the table look ugly. I think that having a dedicated section in the MOS could make these kinds of decisions a lot easier. ―
Jochem van Hees (
talk)
10:59, 25 October 2021 (UTC)
Country | Population | |
---|---|---|
amt | pct | |
The same can be said for row headings. Now, in relation to data cells, I'd say colspan can be used when the data is shared across fields (e.g. {{oldid2|1034694173|List of countries and dependencies by area), or rowspan when it's shared across records (presuming records are on rows; the other way around otherwise). — Guarapiranga ☎ 06:15, 9 June 2022 (UTC)
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: /info/en/?search=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)
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:
— Guarapiranga ☎ 06:33, 9 June 2022 (UTC)
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)
align
attribute according to
this document, so if you have to choose, then style="text-align: left;"
is better. ―
Jochem van Hees (
talk)
11:31, 3 May 2023 (UTC)Aurochs has an RFC 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)
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 /info/en/?search=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)
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)
Please see: Help talk:Table#Tool(s) for working with wikitables. — SMcCandlish ☏ ¢ 😼 03:37, 26 August 2023 (UTC)
4.4.1 Edit tables with the same attention given to text, and set them as text to be read.
Tables are notoriously time-consuming to typeset, but the problems posed are often editorial as much as typographic. If the table is not planned in a readable form to begin with, the typographer can render it readable only by rewriting or redesigning it from scratch.
Tables, like text, go awry when approached on a purely technical basis. Good typographic answers are not elicited by asking questions such as "How can I cram this number of characters into that amount of space?"
If the table is approached as merely one more form of text, which must be made both good to read and good to look at, [then] several principles will be clear:
1: All text should be horizontal, or in rare cases oblique. Setting column heads vertically as a space-saving measure is quite feasible if the text is in Japanese or Chinese, but not if it is written in the Latin alphabet. [1]
— Robert Bringhust, The elements of typographic style
References
Setting column titles vertically (and diagonally) has long been a facility of Microsoft Office; HTML 5 and CSS 3 introduced the technology for web pages;
Help:Tables#Vertically oriented column headers is a whole section of instructions on how to do vertical headers like this, and there is a template, {{
Vertical header}}
for doing it.
MOS:UNITNAMES (at the table "General guidelines on use of units") has an example of existing use. None of that excuses poor practice.
Has no-one considered the accessibility implications of this technique? Visitors with screen-readers at least have the advantage that the markup is ignored. When used in a book (despite being poor typographic practice), at least one can rotate the book: that is not so easy with a desktop screen; do so with a mobile and the OS helpful rotates the display in the opposite direction. Book typographers at least have the excuse of the physical dimensions of the paper size; no such constraint applies to a Wikipedia. We don't even have the excuse of "How can I cram this number of characters into that amount of space?"
This is to invite discussion on whether the MOS should at least discourage (preferably deprecate) the practice. (I will notify WT:MOSACCESS, Help talk:Table, Template talk:Vertical header of this debate.) 𝕁𝕄𝔽 ( talk) 17:07, 6 December 2023 (UTC)
{{
Tooltip}}
with {{
Abbr}}
. The latter is for abbreviations (including contractions); the former is for other kinds of annotations that are done as pop-up tooltips (and it does not misuse the underlying <abbr>...</abbr>
markup properly used by {{
abbr}}
). —
SMcCandlish
☏
¢ 😼
04:08, 7 December 2023 (UTC)<br />
as needed to break up a long header or other cell entry, and the more robust solution is to use CSS column-width controls. —
SMcCandlish
☏
¢ 😼
04:08, 7 December 2023 (UTC)column-width
or a key + an {{
abbr}}
eviated header. Does anyone have any first hand experience on how this technique plays with screen readers and the like?
Remsense
留
19:42, 10 December 2023 (UTC)
{{abbr}}
eviated text.
Jroberson108 (
talk)
19:51, 10 December 2023 (UTC)
<br>
, often removing the need to scroll horizontally, with a concomitant increase in comprehensibility.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)
{{
tooltip}}
template for this purpose which does not abuse the <abbr>
element, and have for many years. So, the material on that (if kept in any form) would have to be completely rewritten (and
MOS:TOOLTIP might also need revision; I haven't checked). In the interim, I'm removing it as simply counterfactual. —
SMcCandlish
☏
¢ 😼
05:37, 13 January 2024 (UTC)
{{
if mobile}}
use cases. "Tell me more!" I've seen a similar interesting use of {{
sronly}}
(which provoked some controversy from one editor but which I think will eventually be good community-accepted advice about invisible-izing table captions that are simply repetitive of table headers). —
SMcCandlish
☏
¢ 😼
13:32, 4 February 2024 (UTC)
First 2 tables below use {{ sort under}}. Unlike other methods it allows use of the data-sort-type=VALUE attribute (see Help:Sortable tables). And it is easy to use.
Using class=sort-under-center:
Location | Rate | Count | Year | Region | Subregion |
---|---|---|---|---|---|
Afghanistan * | 4.0 | 1,613 | 2021 | Asia | Southern Asia |
Anguilla | 28.3 | 4 | 2014 | Americas | Latin America and the Caribbean |
Using class=sort-under-right:
Location | Rate | Count | Year | Region | Subregion |
---|---|---|---|---|---|
Afghanistan * | 4.0 | 1,613 | 2021 | Asia | Southern Asia |
Anguilla | 28.3 | 4 | 2014 | Americas | Latin America and the Caribbean |
There is no class=sort-under-left yet. But here is a table with left-aligned sorting icons using a different method. Unfortunately it has borders just above the sorting icons:
Location | Rate | Count | Year | Region | Subregion |
---|---|---|---|---|---|
Afghanistan * | 4.0 | 1,613 | 2021 | Asia | Southern Asia |
Anguilla | 28.3 | 4 | 2014 | Americas | Latin America and the Caribbean |
My questions for this talk page:
I now think we should only allow center alignment. To avoid unnecessary arguments and slow-going edit wars.
No matter which alignment we choose now for class=sort-under, if we change our minds as a group later, it is easy to change it in the CSS. So all tables using class=sort-under will change to the new choice. -- Timeshifter ( talk) 11:57, 4 February 2024 (UTC) Additions, changes, and strikeouts: -- Timeshifter ( talk) 09:47, 5 February 2024 (UTC)
General commentary from another thread about this: I would suggest that more options are better, but only up to a point (
KISS principle; and the observation than a left-aligned version of such a control widget would not be of use in an LTR language is probably correct). Concision in class, parameter, and other names is generally better (may be pertinent to both the template parameter code and the TemplateStyles material), but also just up to a point (they need to still be intelligible). Default behavior of the template should probably be what best matches default appearance of sortable wikitable controls (principle of least astonishment; here that would be right alignment). If some particular variant is expected to be needed over and over again, make a simple template wrapper that does that version with a shorthand name that doesn't require lots of parameter futzing. —
SMcCandlish
☏
¢ 😼
13:21, 4 February 2024 (UTC)
{{static row numbers}}{{sticky header}}{{sort under}}
{| class="wikitable sortable static-row-numbers sticky-header sort-under"
"Allow at least right and center to be parameter-specifiable, but default right."? A class has to be added to use this template. Does "default" mean sortable without the use of this template? Jroberson108 ( talk) 16:39, 4 February 2024 (UTC)
{{
sort under}}
, it should default to including what above is being called class=sort-under-right
(with a proposed shorthand alias of class=sort-under
). People should not have to manually add a class when doing something by default would be sensible. And for editors who are not CSS experts, it would be sensible to support a simple template-parameter syntax like {{
sort under|center}}
or {{
sort under|align=center}}
or {{
sort under|center=yes}}
or someting to that effect. And with a right
version that can be explicitly specified without breaking anything. —
SMcCandlish
☏
¢ 😼
23:45, 4 February 2024 (UTC)
sort-under
class that duplicates another class's styles is relevant to this RfC, then it should be added to the top with the other questions for equal consideration instead of having what appears to be a side conversation with a select individual. You already requested it on the template's talk page, so I'm not sure why you didn't add something you wanted to the questions? I may be opposed to it mainly because it adds an extra 16 CSS selectors (thus far) to
Template:Sort under/styles.css and adds ambiguity for what appears to be a very minor and debatable improvement, but I follow consensus.Are there any other templates that duplicate styles like this for something like a "popular choice" or is this a first?If some exist, then at least there is a live example that might be referenced in that other discussion. Jroberson108 ( talk) 11:20, 5 February 2024 (UTC)
class=sort-under-right
and a class=sort-under
that do the same thing, the latter being a shorthand form. The only issue I could see arising is if we settled on right as the default (and that's clearly going to happen), then if class=sort-under
were later changed to be equivalent to class=sort-under-center
, then a whole bunch of tables would suddenly change (because people are apt to prefer the shorter syntax) and this would piss people off. But that's ultimately not any different from making any other sudden display change to template output. I.e., there's nothing unique about the matter. —
SMcCandlish
☏
¢ 😼
00:14, 6 February 2024 (UTC)
sort-under
and sort-under-center
as a centered variant of that, and maybe also a sort-under-right
as a more specific name of the former, and they can just be specified inline at the same time: .sort-under, .sort-under-right { ... }
having the shorter name available would be nice, though the world would not end without it. —
SMcCandlish
☏
¢ 😼
20:20, 6 February 2024 (UTC)
sort-under-right
if sort-under
will do. However, I'm aware that various people are OCD in ways different from me, and may grit their teeth about the lack of a short-under-right
that is specific. It is completely harmless to give them that longer and more detailed class name to get at the same result as the short version. It's certainly not worth all this argument. People get rankled when they lack options. "Somone gave me a choice?! To hell with that!" is not a common reaction, in any sphere. —
SMcCandlish
☏
¢ 😼
02:29, 7 February 2024 (UTC)sort-under
might have if multiple alignments exist. If only one alignment exists, then the shorter class name is preferred.
Jroberson108 (
talk)
23:48, 4 February 2024 (UTC)
sort-under
class. It introduces ambiguity, especially if seen used in an article where, if you are unfamiliar with the template, you cannot tell right away that other alignments are possible without needing to reference the documentation. The sort-under-right
and sort-under-center
classes clearly and sufficiently describe their alignments and, when only one is seen in code, hints at other alignment options at first glance without needing documentation, just like sortable's sorttop
and sortbottom
classes, and {{
Table alignment}}'s classes. It is unlikely that someone is going to have any trouble using the more descriptive class names if all they are doing is copying and pasting code. The documentation has two easy to understand options, so it's already clear without the added complication. I feel duplication is a bad practice, which would add 16 additional CSS selectors (thus far) to the styles at
Template:Sort under/styles.css. If adding it offers any improved usage of the template, it's very minor and debatable since someone is either copying code, already familiar with the template, or looking at the easy-to-understand documentation. Not worth the overhead, added ambiguity, and, as SMcCandlish pointed out, "pissing people off" if the expected alignment of sort-under
changes later on.
Jroberson108 (
talk)
05:10, 6 February 2024 (UTC)
{{table alignment}}
had a default
class set to "left" alignment and you weren't familiar with the other classes. You wouldn't intuitively know that other alignment options exist or what to change it to if you want defaultright
without the documentation. You could if it was originally defaultleft
, just change "left" to "right", which is so much easier. The same applies to this template, as I previously mentioned: "hints at other alignment options at first glance without needing documentation".
sticky-header
class only works with sortable, shouldn't be used with sortable's sorttop
class, and requires adjustments if there are subsections. When you can't use the template in this way, you alternatively have to add a different sticky
class to make exactly one row top-sticky, added to the row instead of the table (different implementation). It's new and there could be other unknown issues. Those are some very strict, complex, and hard-to-remember usage cases compared to all the other templates I've seen, even if you are only using the class that is named similar to the template. Not to personalize or offend, but you already demonstrated this in
Template_talk:Sticky header#Why does this not work on this table?, and, as I recall, made the "It only works on sortable tables." warning more prominent in the doc lead so you wouldn't forget. Per its talk, that template is still in need of fixes that can change both the class name and implementation such as deprecating the old row sticky
class and applying new table classes to target the first or second row so that styles similar to sticky-header
can be applied to the table as a whole to fix other things like borders. If fixed, it would have multiple "main" classes that don't have identical styling, for example new sticky-header-row1
, etc., which in this case are temporary depending on WikiMedia fixes (ex. move non-sortable headers to the thead
element). Since they don't duplicate, its acceptable to name the non-temporary "main" class the same as the template (dashed).sort-under
and sort-under-center
classes, now that we know right is preferred, although my "ideal" preference still remains the current classes for the intuitive reasons mentioned above. Not sure if this RfC should remain open for more comments or closed and moved to the relevant template talk page?.sort-under, .sort-under-right { ... }
so the more specific version is available. I tend to prefer that, since it'll make a certain kind of OCD happier, and people unfamiliar with the template's guts can also just guess that sort-under-center
can be changed to sort-under-right
and be correct. But it's not something I would push strongly for, especially if just having .sort-under { ... }
and .sort-under-center { ... }
makes the dispute end. —
SMcCandlish
☏
¢ 😼
02:34, 7 February 2024 (UTC)
sort-under
(right aligned) to the current descriptive classes (duplication for more intuition) and OK with the current proposal.
Timeshifter, since you proposed both, which do you prefer more?
Jroberson108 (
talk)
04:30, 8 February 2024 (UTC)
.sort-under { ...
to .sort-under, .sort-under-right { ...
so the same block of CSS is triggered by either class name. —
SMcCandlish
☏
¢ 😼
15:13, 8 February 2024 (UTC)
sort-under
still exists, which is only fixable if we only allow one alignment or remove sort-under
.
Jroberson108 (
talk)
05:04, 9 February 2024 (UTC)Location | Rate | Count | Year | Region | Subregion |
---|---|---|---|---|---|
Afghanistan * | 4.0 | 1,613 | 2021 | Asia | Southern Asia |
Anguilla | 28.3 | 4 | 2014 | Americas | Latin America and the Caribbean |
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. ¯\_(ツ)_/¯
Screenreader audio
|
---|
<br />
tags were used to emulate rows (I've since fixed them). Off topic: another issue for screenreaders is when only flag icons are used, like seen here:
recent signings or tables that use colors to convey information like seen here:
results. Screenreaders can't read flag icons or colors, so those tables are not accessibility compliant.sort-under-center
and sort-under-right
, with a preference for "right", which both SMcCandlish and I clearly see. The new option that Timeshifter wants is to add a third shorter class name called sort-under
that would have identical styling with the preferred style (right). Basically two classes align right and one aligns center. He added his reasons above, which is mainly to make the template easier to use. So, the same pointed question I asked SMcCandlish. Are the current descriptive class names and the documentation sufficient for using this template or does this new short class need to be added to improve the template's usage according to Timeshifter's or other reasons and why?
Jroberson108 (
talk)
02:43, 6 February 2024 (UTC)sort-under
class OK), which matches consensus. Yeah, center was added because of {{
sorting row}}, but should be available otherwise.
Jroberson108 (
talk)
04:41, 8 February 2024 (UTC)
sort-under
class be added with preferred alignment (right)? (consensus: OK)sort-under-right
class)? (almost finalized)Thanks. Woohoo! I added the first use of the template in article space. See the main table here:
Note also that the total vertical height of the sticky header is now a little less than before. That is good for cell phones. Especially when there is more than one line of text in the header. Every little bit less is helpful. This country table header has only line of text by having the rate info in the caption. Moving stuff to the caption is a good way to lower the number of lines in table headers. -- Timeshifter ( talk) 14:13, 9 February 2024 (UTC)