Help talk:Table

HTML elements. What exactly is true?

So does Mediawiki support an element or not? For each element. I want to be precise in Help:Table. As in, "this element is deprecated, but still supported by Mediawiki".

See:

• Help:HTML in wikitext#thead, tfoot, tbody

<thead>, <tfoot> and <tbody> are not supported, but are automatically generated when the page is rendered.

• Help:HTML in wikitext#Obsolete/deprecated elements

How much of this is true below, and can it be better written.

From Help:Table#Other table syntax:

See also HTML element#Tables. Note, however, that the thead, tbody, tfoot, colgroup, and col elements are currently not supported in MediaWiki, as of July 2015.

From Help:Table#Pipe syntax tutorial:

The table parameters and cell parameters are the same as in HTML, see http://www.w3.org/TR/html401/struct/tables.html#edef-TABLE and Table (HTML). However, the <thead>, <tbody>, <tfoot>, <colgroup>, and <col> elements are currently not supported in MediaWiki, as of December 2021.

--Timeshifter (talk) 21:05, 15 August 2023 (UTC)

There are two stages to consider: (i) parsing of the Wikitext when you save an edit; (ii) serving a page to your browser.

At stage (i), MediaWiki has a "whitelist", and if a HTML element is not in that list, it is treated as plain text and saved as such. As far as tables are concerned, the table, caption, tr, th and td elements are all in the whitelist, whereas colgroup, col, thead, tfoot and tbody are not.

At stage (ii), MediaWiki takes the saved page and carries out a certain amount of additional cleanup. As far as tables are concerned, this primarily means wrapping all the tr elements in a single tbody element.

If you construct a table using pure HTML, as in

<table class=wikitable>
  <caption>Example of a valid table in HTML</caption>
  <thead>
    <tr>
      <th>Column A</th>
      <th>Column B</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Cell A2</td>
      <td>Cell B2</td>
    </tr>
    <tr>
      <td>Cell A3</td>
      <td>Cell B3</td>
    </tr>
  </tbody>
</table>

it looks like this:

<thead> </thead> <tbody> </tbody>

Example of a valid table in HTML

Column A	Column B
Cell A2	Cell B2
Cell A3	Cell B3

notice how four tags are shown as plain text, before the table begins. So whilst the MediaWiki software emits a tbody element, you can't actually use one yourself. --Redrose64 🌹 (talk) 22:32, 15 August 2023 (UTC)

I couldn't stop the indentation on my post even with multiple placements of {{clear}} which fixed one problem, but not the indentation problem. I had to remove the indentation halfway through your post to fix the problem. Or move the first line of your last table so that it started a new line. I couldn't just indent the first line of your table wikitext. I believe we had a similar problem in a previous talk section here. Only removing the indentation fixed the problem there too.

This below is weird. I had to see it more clearly:

Wiki source:

<table class=wikitable>
  <caption>Example of a valid table in HTML</caption>
  <thead>
    <tr>
      <th>Column A</th>
      <th>Column B</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Cell A2</td>
      <td>Cell B2</td>
    </tr>
    <tr>
      <td>Cell A3</td>
      <td>Cell B3</td>
    </tr>
  </tbody>
</table>

Rendered result:

<thead> </thead> <tbody> </tbody>

Example of a valid table in HTML

Column A	Column B
Cell A2	Cell B2
Cell A3	Cell B3

It's weird how it (as you said) deposits the unused elements above the table.

Could you add tfoot, colgroup, col to the table? That would illustrate the problem clearly in Help:Table. --Timeshifter (talk) 00:14, 16 August 2023 (UTC)

They'll just be ejected out the top as plain text, same as <thead>. --Redrose64 🌹 (talk) 19:01, 16 August 2023 (UTC)

Redrose64. I know, but I want to put that table in Help:Table to illustrate things clearly to others. I don't know how to use those elements in an HTML table, or I would add them in myself. --Timeshifter (talk) 19:24, 16 August 2023 (UTC)

Help:Table is about creating tables in Wikipedia. Since you can't use those elements in Wikipedia, there's no point in giving examples of their use. --Redrose64 🌹 (talk) 22:01, 16 August 2023 (UTC)

Redrose64. I am trying to show editors why they can't be used on Wikipedia via an illustration. It will save editors a lot of time if they mistakenly think (as I did at the beginning) that the reason it is not recommended to use them is solely because they are deprecated on Wikipedia. There is a lot of deprecated stuff used on Wikipedia. This table illustration shows editors that these elements just don't work on Wikipedia. --Timeshifter (talk) 22:47, 16 August 2023 (UTC)

@Timeshifter: They are not deprecated, they are simply not whitelisted. As I mentioned earlier this year, in a different thread elsewhere that you participated in, there are more than fifty elements defined in the HTML 5.2 spec which are not whitelisted. If you want to demonstrate the effect of using such elements, I suggest that you choose just one such element - <thead>...</thead> is probably best, as some people may want to use it (with very good reason) to enclose the row containing the header cells - and then list all the others with a simple note along the lines of "these elements, whilst part of the HTML 5 spec, cannot be used in Wikipedia tables". --Redrose64 🌹 (talk) 18:36, 17 August 2023 (UTC)

What is the status of tables in HTML5? I was under the impression that they were deprecated on favor of CSS. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:59, 17 August 2023 (UTC)

@Chatul: Why would you think that? The current HTML 5 spec is here, and I see no such deprecation. --Redrose64 🌹 (talk) 18:36, 17 August 2023 (UTC)

It might be something that I (mis)remembered from StackExchange. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:34, 18 August 2023 (UTC)

Basically MediaWiki has deprecated some HTML table elements. Though those elements are not deprecated outside MediaWiki.

An illustrated example for Help:Table:

<thead>, <tbody>, <tfoot>, <colgroup>, and <col> elements are currently not supported in MediaWiki. Those tags are ejected to above the table as plain text. Including whatever styling is within the tag itself.

HTML5 table code:

<table border=1 style=border-collapse:collapse>
  <caption>HTML5 table</caption>
  <colgroup>
    <col span=2 style=background-color:red>
    <col style=background-color:yellow>
  </colgroup>
  <thead>
    <tr>
      <th>Column A</th>
      <th>Column B</th>
      <th>Column C</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Cell A2</td>
      <td>Cell B2</td>
      <td>Cell C2</td>
    </tr>
    <tr>
      <td>Cell A3</td>
      <td>Cell B3</td>
      <td>Cell C3</td>
    </tr>
  </tbody>
  <tfoot style="background-color:blue; color:white;">
    <tr>
      <td>Cell A4</td>
      <td>Cell B4</td>
      <td>Cell C4</td>
    </tr>
  </tfoot>
</table>

Rendered by W3Schools Tryit Editor:

Rendered by MediaWiki:

<colgroup> <col span=2 style=background-color:red> <col style=background-color:yellow> </colgroup> <thead> </thead> <tbody> </tbody> <tfoot style="background-color:blue; color:white;"> </tfoot>

HTML5 table

Column A	Column B	Column C
Cell A2	Cell B2	Cell C2
Cell A3	Cell B3	Cell C3
Cell A4	Cell B4	Cell C4

I am not sure if border=1 is still a part of HTML5. It was. But MediaWiki still accepts it, and it is the easiest way inline to add borders around all cells without using a class.

rules=all border=1 adds single line borders around all cells, but rules=all is not part of HTML 5.

I am not sure if the HTML table code is correct, or in the correct order. I only figured out some of this stuff today. This HTML table checker says it is fine:

• http://cerebrumcontorquet.debun.nl/brainwaves/tablecheck/index.php

Others find errors. --Timeshifter (talk) 03:36, 18 August 2023 (UTC)

Please don't use words like "deprecated" unless there is clear documentation that states as such. The actual status of elements such as thead is that they are not whitelisted, as I have mentioned before. Other examples of non-whitelisted tags are <a>...</a>, <img />, <link /> and <script>...</script>, yet you will find these in the HTML source for every single Wikipedia page. Occasionally HTML elements get added to the whitelist, and then they may be used in Wikimarkup - one example is <q>...</q>, which was added to the whitelist about nine years ago.

The <tfoot>...</tfoot> element should not be placed inside the <tbody>...</tbody>: the correct placement, as shown in section 4.9 Tabular data, is between the <tbody>...</tbody> element and the </table> tag.

The border attribute is obsolete in HTML 5 except for the special value border=1 as described here. The rules attribute is entirely obsolete in HTML 5. --Redrose64 🌹 (talk) 21:23, 18 August 2023 (UTC)

OK, I googled the dictionary definition of deprecate, and also read the article: Deprecate. So I will try to use the word correctly in the future.

I think you meant to say:

The <thead>...</thead> element should not be placed inside the <tbody>...</tbody>.

See section links: The thead element. And: The tfoot element.

So as far as I know the HTML table code in the above table is correct.

Thanks much for the HTML5 border attribute link. I bookmarked it. It is good to know that border=1 is OK in HTML5. I knew rules=all was not part of HTML5. It should be put back in. --Timeshifter (talk) 23:56, 18 August 2023 (UTC)

No, I wrote The <tfoot>...</tfoot> element should not be placed inside the <tbody>...</tbody> because that's what I meant. Read through your examples above: you have placed the </tbody> after the </tfoot>, not before the <tfoot>. --Redrose64 🌹 (talk) 05:45, 19 August 2023 (UTC)

These are your links:

The tfoot element says: "Contexts in which this element can be used: As a child of a table element, after any caption, colgroup, thead, tbody, and tr elements, but only if there are no other tfoot elements that are children of the table element."

The thead element says: "Contexts in which this element can be used: As a child of a table element, after any caption, and colgroup elements and before any tbody, tfoot, and tr elements, but only if there are no other thead elements that are children of the table element." --Timeshifter (talk) 06:40, 19 August 2023 (UTC)

Exactly; and by placing the </tfoot> tag before the </tbody> tag, you have made the tfoot element a child of the tbody element, where it is not permitted. --Redrose64 🌹 (talk) 17:26, 19 August 2023 (UTC)

OK. You are right. Thanks. I was thinking of the <tbody> tag instead of the </tbody> tag. I only started working with some of this HTML table stuff the last few days. I fixed the code in the above table. It renders exactly the same in the W3Schools Tryit Editor. By the way that editor renders the table even without the page wrapping HTML initially in the edit window. It can all be deleted. Then paste in just the table HTML. Then click "Run". --Timeshifter (talk) 18:56, 19 August 2023 (UTC)

Don't believe everything that w3schools tells you. Some people refer to it as w3fools for a reason. --Redrose64 🌹 (talk) 21:09, 19 August 2023 (UTC)

I don't. A lot of websites giving technical advice on the web have incorrect info. I was just using the Tryit Editor to make the chart image. It came up near the top of a Google search to run HTML code online. --Timeshifter (talk) 22:47, 19 August 2023 (UTC)

Timeshifter, Redrose64: Mediawiki does not allow any of <colgroup>, <thead>, <tbody>, <tfoot>; using any of these in a table results in fostered content lint errors and such markup appearing above the table. Unfortunately, that means that this page now has 3 fostered content lint errors that should not be fixed. —Anomalocaris (talk) 07:05, 2 October 2023 (UTC)

To respond to the OP, I have to object to the notion that our documentation should contain "this element is deprecated, but still supported by Mediawiki" stuff, as an obvious WP:BEANS problem. We (at least all editors involved in WP:LINT cleanup) already know for a fact that editors who are lazy or have ingrained habits from the 1990s will continue to use deprecated markup that they happen to prefer if they don't think it's going to outright destroy anything, and getting them to stop is very difficult. We have absolutely no reader-facing interest in promoting this behavior, and a very strong editor-/maintenance-facing interest in discouraging it. If someone wants to do a buttload of testing to figure out what deprecated elements and attributes do not cause MW to barf, and to maintain such a list every time MW is upgraded, they can perhaps do that in their own time in their userspace, though honestly a strong WP:MFD argument could be made to delete that as non-pertinent to building en.wikipedia. I.e., if anyone is hell-bent on this idea, they should do it in their userspace at MediaWiki.org or maybe Meta.Wikimedia.org. Creating and maintaing such a list is absolutely outside the scope of en.Wikipedia.org documentation, which exists to record and advise best practices for working on the English-language Wikipedia, so such cruft does not belong in en:Help:Table or any similar page here.  — SMcCandlish ☏ ¢ 😼  04:06, 4 January 2024 (UTC)

SMcCandlish. Feel free to rewrite or remove any of that info on Help:Table. I never wrote any of it, I believe. I was just trying to figure out what was going on with HTML for tables. I always use wikitext for tables. --Timeshifter (talk) 06:10, 4 January 2024 (UTC)

Indenting tables

This section needs revision to produce something that is not an accessibility problem. Presently it says (and provides matching examples): "you can indent tables using one or more colons (":", the normal indent code) at the beginning of a line, the same way you'd indent any other wiki content." But : is not an indent, and is certainly not "the normal indent code" and is not, except by lazy editors making other people clean after them, "the same way you'd indent any other wiki content". It is a definition-list markup that should not be abused for indenting and produces output that is confusing in a screen reader. The advice in this help page is directly conflicting with our own style guidelines.

This needs to be changed to recommend some other indentation method, after some testing. Some potential candidates are {{in5}}, {{block indent}}, {{spaces}}, {{indent}}, and a custom new template or CSS class just for indenting tables.  — SMcCandlish ☏ ¢ 😼  03:11, 26 August 2023 (UTC)

SMcCandlish. Please see Wikipedia talk:Manual of Style/Accessibility#Paragraph breaks in a comment. Scroll down to the part about tables on talk pages.

Also, see the latest version of Help:Table#Indenting tables. I did not write the part about table margins, so I don't know if it is accessible when not on talk pages. --Timeshifter (talk) 16:45, 29 December 2023 (UTC)

Our talk pages are a lost cause, constantly abusing list markup to do visual indentation and producing all kinds of invalid markup as a result, and accessibility nightmares (mostly constant announcements of lists within lists within lists). The fact that we abuse definition/description/association lists in talk pages has nothing to do with how to visually indent material in an article. For other than a single short item, this is usually done with {{block indent}} and is probably what should be advised here (along with the technique of setting a table width in relation to the page width), for indentation in article content. That is, how to handle tables varies by context. Putting a table inside a list is one thing, visually indenting is another, and this "Help" page is incorrectly confusing them, treating lists as "indentation", when they take three forms, only one of which (entirely incidentally) produces a visual indentation effect without other markup, and which should not be abused in our articles per MOS:DLIST for visual indentation purposes.  — SMcCandlish ☏ ¢ 😼  22:23, 29 December 2023 (UTC)

SMcCandlish. Feel free to rewrite/rename Help:Table#Indenting tables, but please do not delete the section: Help:Table#Tables on talk pages. And please run your rewrite by the experts at Wikipedia talk:Manual of Style/Accessibility. --Timeshifter (talk) 22:44, 29 December 2023 (UTC)

Sure, I can rework it pretty easily (I don't think anyone has more experience fixing WP:POLICYFORK issues than I do at this point, and I also do a lot of markup documentation). I wouldn't remove an entire section; we just need to distingish between best practice in articles, and the "it's a trainwreck, but the trainwreck we've agreed to live with" situation on talk pages. I would definitely have the WT:MOSACCESS regulars check it out; I usually drop a notice there when there's an accessibility matter pertainting to lists, tables, etc. I haven't gone diving directly into this yet because I've had my nose buried in other stuff, plus the holidays.  — SMcCandlish ☏ ¢ 😼  09:48, 2 January 2024 (UTC)

Compact this guide

Can we see about condensing this page down ? Why does this have to contain every idiotic trick that people came up with to abuse tables for at some point in the history of Wikipedia ? This makes it completely unreadable for novices. —TheDJ (talk • contribs) 12:30, 23 September 2023 (UTC)

Yes. It's been heavily expanded since about May 2023 and has much concerning spreadsheets and external tools. I simply don't see the point of some sections e.g. Converting US state abbreviations to full names, Convert 2 or 3-letter country codes to full names. --Redrose64 🌹 (talk) 17:17, 23 September 2023 (UTC)

I feel the same way and question the need for the "Converting US state abbreviations to full names" section and the rest that follow. Jroberson108 (talk) 22:50, 23 September 2023 (UTC)

The top of Help:Table says "There is a simplified version of this page at Help:Wikitable. That redirects to:

• Help:Introduction to tables with Wiki Markup/1 - The "next" buttons, or the left sidebar, lead to:
• Help:Introduction to tables with VisualEditor/2
• Help:Introduction to tables with VisualEditor/3
• Help:Introduction to tables with VisualEditor/4
• Help:Introduction to tables with VisualEditor/5

There is also:

• Wikipedia:Advanced table formatting - it seems to be more about images, quotes, bugs, and borders.

I will separate out a large part of Help:Table to Help:Table. Advanced. The advanced stuff I am interested in, and use all the time. I didn't write a lot of the arcane stuff in Help:Table. I will leave it in Help:Table. I never use much of it.

See: User:Timeshifter/Sandbox227. That is what I propose to move to Help:Table. Advanced. I started all those sections, if memory serves. I wrote nearly all of it. I have used all of it. I don't want any of the other stuff moved there. I agree with you that much of the other stuff is arcane. I wouldn't go so far as to call that other stuff idiotic. Someone must have been using it to go to the trouble to write it up. Maybe it can be moved to Help:Table. Arcane tips. --Timeshifter (talk) 01:26, 24 September 2023 (UTC)

@Timeshifter: I am going to slap a massive on You deleted a lot of frequently used info (emphasis mine). Do you have any evidence – other than personal experience – that anyone has ever come to this page thinking to themselves, "I need to convert 2 or 3-letter country codes to full names"? I find that hard to believe, given that the sections I removed address extremely niche situations. Slowing down connections is the exact opposite of useful. HouseBlaster^talk 23:01, 8 December 2023 (UTC)

Good grief, relax. What kind of bad faith question is that? Yes, allow them to break out the meticulous statistics regarding the user experience on this page. You can take it as advice to be more discriminate in sawing out sections of the page and go from there, possibly with better consensus. Remsense留 23:07, 8 December 2023 (UTC)

I admit I could have been more polite in my above message. Thank you, with apologies to Timeshifter; I have struck and reworded. That being said, I stand by that edit; WP:BRD is a great way to go about achieving consensus.

I have gone ahead and reinstated one part of my edit, which I believe ought to be non-controversial: we don't need to show what an indented table looks like without indentation. There are numerous examples elsewhere on the page of unindented tables. HouseBlaster^talk 23:33, 8 December 2023 (UTC)

I have no problem with your removal of the non-indented table. I didn't write that help section, I believe.

See edit diff of my reversion of your massive page cut. Edit summary: "Undid revision 1188968242 by HouseBlaster (talk). You deleted a lot of frequently used info. And some not so much. See: Help talk:Table#Compact this guide. See my proposal to divide into 2 help pages."

Search for deleted sections by searching for == in the edit diff. A popular section you deleted:

• Help:Table#Adding flags and linking countries, states, etc. in lists. "extremely niche situation"? Are you that clueless about table editing? Just look up the many flag templates in use. For example, see this transclusion count for Template:Flag:
• 570,694 transclusions.

That help section makes it a lot easier, if people choose to use it.

Most of the other stuff you deleted had to do with less-used subsections of that section. Also, the stuff to do with spreadsheets and tables. And more.

That is advanced stuff that some editors greatly appreciate for long tables. That is stuff from the Visual Editor section at the bottom of Help:Table. I previously suggested moving that Visual Editor section (and more) to a new page with some other advanced stuff. I am waiting for the OK to do it. See what I am talking about moving:

• User:Timeshifter/Sandbox227.

--Timeshifter (talk) 01:16, 9 December 2023 (UTC)

Why are you waiting for the OK to do it? WP:Be bold!

"Niche situations" was perhaps an overgeneralization. The problem with Adding flags and linking countries, states, etc. in lists is in the section heading: in lists. It is useful information, but because it is not specific to tables it does not belong on this page. I understand that it can be used while making a table, but that could be said about any wikitext. For instance, you can use magic words in tables, but that does not mean we should have a section here about using magic words with tables. HouseBlaster^talk 02:24, 9 December 2023 (UTC)

That section is about tables. I just changed the section name to use "tables". I am so used to articles with long tables having the phrasing "List of ..."

You are the first person to respond to my idea of splitting Help:Table into two help pages.

I like WP:BRD, but splitting a page can be complicated. I think only an admin can do it correctly, and keep the page history correct for both new pages. So reverting it would require some work too. I think we should wait until others respond. --Timeshifter (talk) 04:04, 9 December 2023 (UTC)

It requires no use of the admin tools; see Wikipedia:Splitting#How to properly split an article. This section has plenty of support for removing the content from this page, and a split can easily be undone (undoing a split only two edits: one to re-add the material to the original article and one to redirect the newly created article to the old article). I have created Help:Tables and locations to host the material about how to use tables to display information about places.

While splitting, there were two sections I deleted entirely. I removed the section on automated tables because it does not explain how to create an automated table (and an explanation is outside the scope of this page). I removed the section on aligning the first column to the left because the very next section explains how to align any column (including the first) any way one chooses (including the left). HouseBlaster^talk 06:09, 9 December 2023 (UTC)

I returned those 2 sections. See edit summaries. I also explained things more in Help:Table#Aligning the text in the first column to the left. Still thinking about what to split out, and what to title the new help page. --Timeshifter (talk) 07:21, 9 December 2023 (UTC)

I think we are both technically at three reverts on this page, so I am not going to undo anything else (even though I do not think we are edit warring). I still do not think the section on automated tables belongs in any help page, but I would not object to moving it to Help:Tables and locations. Would you be willing to self-revert and add it to Help:Tables and locations?

I think that there are two related – but different – concepts explained at this help page. I think most of this page is about what you can do with a table, but some of it is about how to create a table. Thus, I would suggest creating Help:Creating tables. HouseBlaster^talk 17:38, 9 December 2023 (UTC)

Information overload is a problem on this page. Read the "Content" section on Wikipedia:Policies and guidelines. Per WP:CREEP, Avoid instruction creep to keep Wikipedia policy and guideline pages easy to understand. The longer, more detailed, and more complicated you make the instructions, the less likely anyone is to read or follow whatever you write.

Sections that describe a feature or template should be consolidated to the minimum and rely on the main help and template documentation pages for full information. Move any new info to the more relevant main pages and template documentation, if that info is really needed. Don't repeat info so elaborately. If an example is needed, provide the most commonly used example just to inform the user and allow the main pages to do the rest. Don't mention historical fixes, testing, or merging/deprecated/obsolete templates, all of which can become dated and is best moved, again if really needed, to the main pages. Same goes for the transclusion info. Remove any common sense instructions like visit the template and talk page for more info. Example sections:

• Tables with sticky headers, which re-explains {{Sticky header}}.
• Sortable tables, which re-explains Help:Sortable tables.
• Collapsible tables, which re-explains Help:Collapsing.
• mw-datatable – row hover highlighting. White background, which re-explains {{Row hover highlight}}.

For the "Scrolling and sticky headers" section, remove the obsolete sticky parts. There's already a section for sticky.

For the "Converting US state abbreviations to full names" section, which was moved, it just deals with providing a table of content to copy, which quite frankly wasn't needed.

These sections, which have already been moved, are MediaWiki Editor instructions that involve using regular expressions to manipulate content, something quite advanced that most people won't understand even when explained and therefore not needed.

• Convert 2 or 3-letter country codes to full names
• Adding flags and linking countries, states, etc. in tables, which some re-explains Flag help.
• Add link brackets to text in each cell in a column

These sections are spreadsheet instructions and a little more for manipulating data, which aren't needed in my opinion.

• Convert rows to columns and columns to rows
• Picking selected dates from massive .csv files
• Separating counts and rates to 2 columns

The "Automated tables updated daily by bots" section is meaningless to most, requiring a templated table invoking a custom built module fed from JSON data that is automatically populated through a bot, also custom programmed. If it is to be kept, which I don't think it should since there will probably be no one looking at it, then move it to Advanced and consolidate it.

The "Convert spreadsheet/database tables to wikitables" section discusses tools to convert other data formats to wikitable, which should be moved to Advanced.

The "Tables and the visual editor (VE)" section has MediaWiki VisualEditor instructions on table manipulation. In my opinion, it isn't needed. If needed, move to Advanced. It has enough content to be its own page though, which as it is, lacks the "Visual" aspect.

BTW, someone broke the ability to reply. Comments on this page can't be replied to because of an error in the wikitext. Jroberson108 (talk) 19:15, 9 December 2023 (UTC)

HouseBlaster. I moved automated tables section, and some other sections dealing with states and countries, to Help:Tables and locations.

I also moved sections to Help:Table. Advanced. See:

• Wikipedia:Prosesize
• Wikipedia:Article size - < 6,000 words < 40 kB. "Length alone does not justify division or trimming."

Readable prose size:

• Help:Table - Prose size (text only): 34 kB (5922 words).
• Help:Tables and locations - Prose size (text only): 15 kB (2569 words).
• Help:Table. Advanced - Prose size (text only): 27 kB (4830 words).

--Timeshifter (talk) 00:40, 10 December 2023 (UTC)

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

I have initiated a discussion at Wikipedia talk:Manual of Style/Tables#Proposal to discourage vertically oriented ("sideways") column headers, to may interest contributors to this article. 𝕁𝕄𝔽 (talk) 17:13, 6 December 2023 (UTC)

I also want to tack on the suggestion directly relevant to this page to remove the suggestion to use images of text to create vertical headers (or any analogous advice), it is incredibly ill-advised and unnecessary now, if it was ever truly acceptable practice before. Remsense留 04:18, 7 December 2023 (UTC)

Linking to User:The wub/tocExpandAll.js

I had removed the link at the top of this page to User:The wub/tocExpandAll.js, but was reverted by User:Timeshifter. I do not believe a link is appropriate because that tool has nothing to do with tables. Do other editors have thoughts? HouseBlaster^talk 02:01, 13 December 2023 (UTC)

There are still 15 expandable sections in the table of contents.

Note: Go here for a tool to fully expand/collapse the table of contents.

It's one line on a help page. It makes it easier to use this help page and many article pages with many subsections. I use it all the time. You don't have to use it. But others may appreciate the help in using this help page. --Timeshifter (talk) 03:03, 13 December 2023 (UTC)

I realize it is one line on a help page, but while useful I simply don't see why it belongs on this page. It is not related to tables, and thus does not belong on this help page.

To be clear, I use the tool. I agree it is useful. But I don't think it needs to have a link in the lead of a help page on tables. HouseBlaster^talk 03:21, 13 December 2023 (UTC)

I agree that it should be removed since it's completely irrelevant to tables. It contributes to the information overload issue I spoke of in the "Compact this guide" discussion. Jroberson108 (talk) 04:07, 13 December 2023 (UTC)

Houseblaster. You said: "It is not related to tables." It is helping people use this help page on tables. And you use it. So let's help other people use this help page more efficiently and quickly. Are you going to make them click 15 expand buttons before they find the specific help they need? Versus clicking one "expand all" button, and quickly skimming the table of contents. --Timeshifter (talk) 04:25, 13 December 2023 (UTC)

Nobody has to click 15 expand buttons. Let's say I want to put a border on every cell. I am going to skim the table of contents, see "whole table operations", and click expand. Then I would see Help:Table § Borders of every cell, and click on that. If everything else was expanded, it would needlessly clutter the interface. The KISS principle applies. HouseBlaster^talk 16:46, 13 December 2023 (UTC)

Before I installed the tool, I often had to expand many TOC sections to find what I wanted on Help:Table and many other articles. The tool does not prevent you from opening sections individually. I also have some CSS installed to minimize the space between lines in the TOC. Both in Vector 2010 and Vector 2022. See vector.css and vector-2022.css links on my user page. --Timeshifter (talk) 17:14, 13 December 2023 (UTC)

Rounding back, I am not seeing anyone who agrees with you that content which has nothing to do with tables should be included. Respectfully, your response does not explain why adding to information overload and violating the KISS principle is justified in this instance. Anecdotal evidence is not particularly strong evidence. HouseBlaster^talk 19:15, 19 December 2023 (UTC)

Having to open 15 Help:Table sections one by one is information overload, and violates the Keep It Simple principle. Cause it is slow, and not simple. --Timeshifter (talk) 21:42, 19 December 2023 (UTC)

My point is that people do not need to open all 15 sections. If I want to know how to set a caption using pipe syntax, I am not going to expand "Width", "Height", etc. I am going to expand Pipe syntax. HTML output, and then click "Captions". HouseBlaster^talk 22:24, 23 December 2023 (UTC)

You are assuming people know exactly what they are looking for, or that the info they are looking for fits into a particular heading. I remember when I looked in many sections to find what I was looking for. And I sometimes needed info from multiple sections. And someone new to tables may just want to browse around all the headings before jumping in. I often do that on article pages with many nested sections. --Timeshifter (talk) 00:58, 24 December 2023 (UTC)

I think it is clear that we are not going to come to agreement here, so I have started an RfC. HouseBlaster^talk 22:31, 24 December 2023 (UTC)

RfC: linking to User:The wub/tocExpandAll.js

Should there be a link to User:The wub/tocExpandAll.js in the lead? 22:31, 24 December 2023 (UTC)

• No, because the tool has nothing to do with tables. Information overload is a real problem. HouseBlaster^talk 22:31, 24 December 2023 (UTC)
• No, completely irrelevant to tables. This has already been discussed and other editors agree, so why is concensus not being followed, which doesn't require unanimity? Jroberson108 (talk) 23:06, 24 December 2023 (UTC)

  To clarify, it should not be on this page anywhere. Jroberson108 (talk) 03:26, 12 February 2024 (UTC)

• Yes. See my previous comments. Which HouseBlaster and Jroberson108 do not acknowledge as being true for me, or others. Thus removing a useful tool for some table editors. We are talking one sentence. Many people on the Village Pump and on Phabricator disagreed with the decision not to have an expand/collapse all toggle. So I know for a fact that many people want it. So let them have the choice, versus forcing your way on them. --Timeshifter (talk) 02:15, 25 December 2023 (UTC)
• No. This is unrelated to the topic of the help page. Every internal WP tool ever developed by anyone is probably useful to someone somewhere on random pages like this, but that is no reason to put links to them at the top of such pages.  — SMcCandlish ☏ ¢ 😼  22:29, 29 December 2023 (UTC)
  • SMcCandlish. Did you read the discussion? And there are many tools listed on the Help:Table pages. That's the point. They are help pages. I can move the tool link off the top of the help page. I will do that now. --Timeshifter (talk) 22:47, 29 December 2023 (UTC)

    Yes, I read it. The fact that you find some particular tool incidentally helpful for expanding/collapsing sections is no reason to put a link to that tool at the top of a random page just because it has a lot of sections. This is a help page – about tables, not about tools for sectional navigation and display alteration. The fact that you opened an RfC about this after meeting with unanimous resistance (i.e. there is already a clear consensus against your desire to "spam" this toCExpandAll.js script here) is a petty abuse of the WP:RFC process.  — SMcCandlish ☏ ¢ 😼  23:41, 29 December 2023 (UTC)

    SMcCandlish. So I was right, you didn't read it all. Since I didn't start this RFC. So you insulted me due to your ignorance. Nice pathetic attempt at piling on. --Timeshifter (talk) 01:34, 30 December 2023 (UTC)

    Repeat: The fact that you find some particular tool incidentally helpful for expanding/collapsing sections is no reason to put a link to that tool at the top of a random page just because it has a lot of sections. This is a help page – about tables, not about tools for sectional navigation and display alteration. My substantive objection to your proposition stands. My non-substantive objection to what I thought was you opening a pointless RfC was also valid (just addressed to the wrong editor), and is neitehr an "insult" nor a "pathetic attempt" at any thing (nor does it have anything to do with whether I read and understood your arguments for spamming us with a toCExpandAll.js "advert", which I clearly did read and understand). I'm always amazed at the propensitiy of various people to claim butt-hurt victim status when they are not getting their way and then in particular make like someone was rude to them while the rudeness in the discussion is actually coming from them. From the "unclear on the concept" department. If you think the discussion is not as civil as you'd like, then using wording like "insult" and "pathetic" is absolutely, positively guaranteed to make it worse and to make it look like you are the problem. Cf. WP:HOTHEADS for pertinent advice along these lines.  — SMcCandlish ☏ ¢ 😼  03:17, 30 December 2023 (UTC)

    I am not butt-hurt. I am amused again at your lack of reading comprehension. I had noted: "I can move the tool link off the top of the help page. I will do that now." Yet you are still talking about the link being at the top of the help page. --Timeshifter (talk) 08:20, 30 December 2023 (UTC)

    To be clear, I opened the RfC because I felt like we (i.e. Timeshifter and I) were talking past one another. There was a third (albeit minor) participant, which ruled out 3O. HouseBlaster^talk 23:48, 29 December 2023 (UTC)

    Whoever: When a proposition lacks support, we do not need an RfC to confirm that it self-evidently lacks support, especially when it's about minor trivia. RfCs consume considerable amounts of community time and energy.  — SMcCandlish ☏ ¢ 😼  03:17, 30 December 2023 (UTC)

    I am not one to start RfCs for the fun of it. Heck, I am the guy who BOLDly deprecated WP:A5 without an RfC. Some context: I was involved in two separate discussions with Timeshifter (one being the matter at hand), and neither of them have come any closer to agreement. At the other discussion, Timeshifter stated that 2 out of 3 is not a consensus. Get others involved. This discussion was likewise a two against one, so I requested further input. (Looking back, I should have tried leaving a note at Wikipedia talk:Help Project first.)

    I have withdrawn the RfC, given that this is increasingly looking like a WP:1AM scenario. I would rather not personally remove the link, but I support you (or anyone else) in doing so. HouseBlaster^talk 05:13, 30 December 2023 (UTC)

Prevent top table headers from "following" the reader (in visually "pinned" manner) when scrolling down

Resolved

 – It was the 'make headers of tables display as long as the table is in view, i.e. "sticky"' Preferences setting, under Gadgets.

Saw this before somewhere, but encountered it again in one of my user pages, User:SMcCandlish/Barnstars. When you scroll down through the long table, the top header row for the columns, beginning with "The Running Man Barnstar ...", gets stuck in place, and follows the reader throughout the table, despite later rows having their own column headers. What turns off this feature?  — SMcCandlish ☏ ¢ 😼  23:51, 28 December 2023 (UTC)

SMcCandlish. What browser, device, and OS? I am not seeing it on Firefox on Win 10 Pro PC. --Timeshifter (talk) 16:46, 29 December 2023 (UTC)

Chrome, Win 10, PC. The rendered code I'm getting at the top of the table looks like this:

<table class="wikitable">
<tbody><tr>
<th colspan="5" style="background: #AFFBEA; text-align: left; font-size: 125%;">Gratuitous
</th></tr>
<tr>
<th scope="col" style="background: #F9FACA; width: 20%;"><a href="/wiki/Wikipedia:Barnstars#Topical_barnstars" title="Wikipedia:Barnstars">The Running Man Barnstar</a>
</th>
<th scope="col" style="background: #F9FACA; width: 20%;"><a href="/wiki/Wikipedia:Barnstars#General_Barnstars" title="Wikipedia:Barnstars">The Working Man's Barnstar</a>
</th>
<th scope="col" style="background: #F9FACA; width: 20%;"><a href="/wiki/Wikipedia:Barnstars#General_Barnstars" title="Wikipedia:Barnstars">The Defender of the Wiki Barnstar</a>
</th>
<th scope="col" style="background: #F9FACA; width: 20%;"><a href="/wiki/Wikipedia:Barnstars#Category_barnstars" title="Wikipedia:Barnstars">The <style data-mw-deduplicate="TemplateStyles:r1003227249">?'"`UNIQ--templatestyles-00000005-QINU`"'?</style><var class="var-serif">E</var>=<link rel="mw-deduplicated-inline-style" href="mw-data:TemplateStyles:r1003227249"><var class="var-serif">mc</var><sup>2</sup> Barnstar</a>
</th>
<th scope="col" style="background: #F9FACA; width: 20%;"><a href="/wiki/Wikipedia:Barnstars#General_Barnstars" title="Wikipedia:Barnstars">Excellent User Page Award</a>
</th></tr>

So I'm not really sure where this is coming from. I don't have a user script or something injecting a class into this.  — SMcCandlish ☏ ¢ 😼  22:34, 29 December 2023 (UTC)

SMcCandlish. I am not seeing anything sticky on that page in Chrome on my Win 10 Pro PC. --Timeshifter (talk) 22:59, 29 December 2023 (UTC)

@SMcCandlish: Does it happen when you're logged out? If not, then check your preferences to see what gadgets you have enabled, which there is one under "Testing and development" that deals with sticky: Make headers of tables display as long as the table is in view, i.e. "sticky" (requires Chrome v91+, Firefox v59+, or Safari). It that's not it, then you can check your Special:MyPage/common.css and Special:MyPage/common.js settings for any recent changes that might be causing it, which if you are using scripts from other users, then those scripts could have changed without your knowledge. Jroberson108 (talk) 23:20, 29 December 2023 (UTC)

That prefs setting was it. I had completely forgotten it existed.  — SMcCandlish ☏ ¢ 😼  23:43, 29 December 2023 (UTC)

Request for comments concerning Template:Sort under

See:

• Template:Sort under
• Template talk:Sort under

Comment at the above-linked talk page. Comments are requested there specifically concerning whether the default class=sort-under should be centered sorting icons or right-aligned sorting icons. Or even left-aligned ones. --Timeshifter (talk) 21:51, 28 January 2024 (UTC)

For those who are interested. Someone at the technical Village Pump suggested going to this MOS discussion page since it is a style discussion, and not a technical problem. See:

Wikipedia talk:Manual of Style/Tables#Template:Sort under

--Timeshifter (talk) 14:09, 4 February 2024 (UTC)

Help:Table/Accessibility or Help:Accessibility of tables

Isaidnoway, Houseblaster, and more. I think there should be a separate page with one of the above names. Or another name.

Could move or copy these to it:

• Help:Table#Scope
• Wikipedia:Manual of Style/Accessibility#Tables
• User:Isaidnoway - some table accessibility stuff there on the user page.

What else could go in this new Help page?

I don't have the health, time, or energy to do this. Though I could do some cleanup afterwards. Houseblaster, are you interested? You have done these type of Help:Table spinoffs already. --Timeshifter (talk) 14:00, 5 February 2024 (UTC)

Wikipedia:Manual of Style/Accessibility/Data tables tutorial also exists. I don't recommend moving anything off of Wikipedia:Manual of Style/Accessibility without first discussing it there. Jroberson108 (talk) 21:09, 5 February 2024 (UTC)

I would be interested in helping out with something like this. However, I would oppose moving anything out of Wikipedia:Manual of Style/Accessibility, because that is an official guideline. HouseBlaster (talk · he/him) 23:12, 5 February 2024 (UTC)

It would be nice if all of the above was on a help page. I find "tutorial" and "manual of style" to be off-putting. On the other hand, people have little fear in trying to edit help pages. WP:BRD happens more often. Bold-revert-discuss.

"Data tables tutorial" is not a guideline or policy. Maybe change its name to Help:Table/Accessibility.

There is very little in the Tables section of the guideline page: Wikipedia:Manual of Style/Accessibility#Tables. Maybe just copy it to Help:Table/Accessibility.

The rest of the stuff listed in my first post shouldn't be a problem to copy or move there too.

Then we can all edit the new help page. We now have a new history for all the consolidated material. We don't have to worry about losing anything. --Timeshifter (talk) 23:54, 8 February 2024 (UTC)

"See also" sections, and their inclusion of somewhat related links

• Tool. to fully expand/collapse the table of contents. Help:Table TOC has many subsections.

See diff and HouseBlaster edit summary: "Undid revision 1205566101 by Timeshifter (talk) unanimous agreement against including the link at Help talk:Table#RfC: linking to User:The wub/tocExpandAll.js"

That was a 3 to 1 vote. That is for the link at the top of the article. The link was moved to the "See also" section. It has been there for awhile. Those sections allow somewhat related links. So that 3 to 1 vote does not apply. And Jroberson108 was one of those votes. He does not have a problem with somewhat related links being in the "See also" section.

See the revision history for Template:Static row numbers. See the 3 diffs starting at 01:34, 14 January 2024‎. The one at 11:24, 14 January 2024‎ says: "Clarified the relation. Undid revision 1195546324 by Jroberson108". User:Jroberson108 thanked me for that clarification, and left that somewhat related link. --Timeshifter (talk) 00:58, 12 February 2024 (UTC)

@Timeshifter: Please don't assume my opinion, just ask. I think the consensus clearly says that there is "no" relation, not even "somewhat". Since there is some question about my opinion, then I'll reclarify it in the RfC. Jroberson108 (talk) 03:26, 12 February 2024 (UTC)

To keep the current discussion here, I oppose including the link anywhere on this page. It has nothing to do with tables. HouseBlaster (talk · he/him) 03:29, 12 February 2024 (UTC)

HouseBlaster. You previously wrote: "To be clear, I use the tool. I agree it is useful. But I don't think it needs to have a link in the lead of a help page on tables." That is why I moved it to the "See also" section. As I said in another discussion. It is not about me. This is not a chess game between you and me. It is about what is best for the reader. --Timeshifter (talk) 04:46, 12 February 2024 (UTC)

I stand by that comment, because it certainly does not belong in the lead of a page on tables. But it also does not belong in the see also section on tables. I know this is not a game between us. What is best for readers is keeping it simple, which means only including information about tables. Just because you and I use a tool does not mean it should be on this page. HouseBlaster (talk · he/him) 05:01, 12 February 2024 (UTC)

"Just because you and I use a tool does not mean it should be on this page." Why not? There is no rule that it can't go in the "See also" section. What does KISS principle have to do with one useful link being put in the "See also" section? It was there for weeks. How does it hurt anything? It obviously helps since both you and I use it. I am waiting for a guideline against it being there. Otherwise it is WP:IJDLI. See: WP:CIVIL says: "Editors are expected to be .. responsive to good-faith questions." --Timeshifter (talk) 05:13, 12 February 2024 (UTC)

Timeshifter, I have said my piece. I am not required to WP:SATISFY you: I believe that it violates the KISS principle by including something that does not have anything to do with tables. It "hurts" because it is distracting from the table-related resources. That is my opinion. Please respect it. HouseBlaster (talk · he/him) 05:21, 12 February 2024 (UTC)

HouseBlaster. How is it "distracting" from the table-related resources? It actually helps find them in the TOC. And how is it distracting at all? It is at the bottom of the page in the "See also" section. You didn't even notice it being there for weeks. --Timeshifter (talk) 05:26, 12 February 2024 (UTC)

I am not going to respond further. See WP:SATISFY. It is distracting. If you think I am being uncivil, feel free to file a request at WP:ANI. HouseBlaster (talk · he/him) 05:28, 12 February 2024 (UTC)

I have not repeated myself. I have responded to your points one by one. --Timeshifter (talk) 05:35, 12 February 2024 (UTC)

I oppose including the link anywhere on this page. It has nothing to do with tables. Jroberson108 (talk) 03:38, 12 February 2024 (UTC)

Jroberson108. It helps to fully expand/collapse the table of contents. Help:Table TOC has many subsections. I use it all the time here. HouseBlaster uses it. Why not allow others to have that opportunity?

It may not be directly related to tables, but it certainly is a help. So since it is helpful with the long TOC here, then it should go in the "See also" section.

See: WP:CIVIL says: "Editors are expected to be .. responsive to good-faith questions." You have not addressed any of my points or questions in either talk section. Your position is apparently WP:IJDLI. --Timeshifter (talk) 05:32, 12 February 2024 (UTC)

Please don't assume my opinion, my thoughts, or bad faith. Can the hierarchy of the sections not be simplified so you don't feel a need for the tool? That would benefit everyone. Jroberson108 (talk) 06:03, 12 February 2024 (UTC)

See: Wikipedia:Manual of Style/Layout#"See also" section. There is nothing in there against having this kind of link. It says (emphasis added): "Links in this section should be relevant and limited to a reasonable number. Whether a link belongs in the 'See also' section is ultimately a matter of editorial judgment and common sense. One purpose of 'See also' links is to enable readers to explore tangentially related topics;" --Timeshifter (talk) 05:55, 12 February 2024 (UTC)

Consolidation ideas

Can the hierarchy of the sections not be simplified so you don't feel a need for the tool? That would benefit everyone. Jroberson108 (talk) 06:03, 12 February 2024 (UTC)

We've already spun off 3 articles from Help:Table. They are all below the recommended prose size limit of 6,000 words. I updated the numbers below. See:

Wikipedia:Prosesize

Wikipedia:Article size - < 6,000 words < 40 kB.

Readable prose size:

Help:Table - Prose size (text only): 27 kB (4675 words).

Help:Creating tables - Prose size (text only): 18 kB (3336 words).

Help:Tables and locations - Prose size (text only): 16 kB (2805 words).

Help:Table. Advanced - Prose size (text only): 11 kB (1940 words).

--Timeshifter (talk) 08:02, 12 February 2024 (UTC)

I was speaking more in terms of organizing the sections on this page, not necessarily moving anything to another help page.

Consolidating can help with the size. In Basic table markup, the "Required" column can be removed and the bold word "Required" added to the "Usage note" column, which "Optional" is implied.

Examples can be consolidated to the essentials to illustrate how to do it. In Float table left or right, would two columns suffice and can the lorem ipsum text be reduced? Same for Centering tables, would two columns suffice? Should Nested tables be on this page given it's discouraged per the accessibility link, or should it be minimized since the link illustrates it already?

Pipe syntax tutorial, Simple tables, Classes, Other table syntax, and probably some other sections seem to duplicate a lot of what's already covered on Help:Basic table markup, so can they be removed/reduced to an essential overview. Basically, go here to learn the basics because this page gives an overview of the essential markup and the rest goes more in-depth on further customization.

If the sections were organized based on the reader's goal, then it might make it easier to find what they are looking for.

The sections could be:

• Adding tables
  • Visual editing
  • Source editing
• Table markup overview
• Table styling
  • Alignment
  • Borders
  • Color
  • Colspan and rowspan
  • Floating
  • Width and height
  • Nowrap
  • etc.
• Table templates
  • Row numbers
  • Tooltip
  • Diagonal split header
  • etc.
• Table advanced usage
  • Image gallery
  • Indenting tables
  • etc.

Conditional table row should probably be moved to advanced. Jroberson108 (talk) 18:51, 12 February 2024 (UTC)

I don't think we need to create any new pages, but I think the guidance at WP:Article size is not applicable here. "Prose size" leaves out everything in a table, which for these pages is much of the content. HouseBlaster (talk · he/him) 15:29, 14 February 2024 (UTC)

Table with page sections

FYI, I've come across a few pages where page sections were added to a table to divide it up into sections. I'm sure it's an accessibility issue that's worse than MOS:COLHEAD. If someone wants to try to fix them, feel free.

• List of compositions by Johannes Brahms
• List of compositions by Richard Wagner
• List of compositions by Jean Sibelius

There's probably more. Jroberson108 (talk) 21:07, 14 March 2024 (UTC)

This is permitted by the HTML specs (because MediaWiki does not use the ARTICLE, ASIDE, FOOTER, HEADER, NAV and SECTION elements which would impose restrictions on page structure). Why is it an issue here? --Redrose64 🌹 (talk) 15:33, 15 March 2024 (UTC)

I mentioned aaccessibility. It's very similar to MOS:COLHEAD except with "header" instead of "th" elements where you are visually separating a data table. Although using "th" might cause more issues, it's still "visual". MOS:COLHEAD recommends moving the header text to a column or spliting them into separate tables with the header text in the table caption. If it's not an accessibility issue for screen readers, then that's fine. Moving it to caption is an easy way to keep it accessibile. Jroberson108 (talk) 16:57, 15 March 2024 (UTC)

Styling background-color

I've come across several pages that have a sortable table's column header's background color changed using style="background: color;". This made the sort arrows not display. The help page should change the code examples to use style="background-color: color;" instead, which fixed the issue. Although the help page has one prose line that says use "background-color", every color example uses "background". Here's the latest two fixes: [1] and [2]. Jroberson108 (talk) 21:36, 14 March 2024 (UTC)

When used inside a style= attribute, they are, in most cases, interchangeable. However, the background: property will reset any background-image:, background-position:, background-size:, background-repeat:, background-origin:, background-clip: or background-attachment properties to their initial values. I don't think that this will be a problem for us. --Redrose64 🌹 (talk) 15:53, 15 March 2024 (UTC)

I'm aware that they can be interchangeable except when another background property is also set, but most people aren't CSS savvy. Setting a more specific "background-color" in the examples would help, especially when someone later adds sortable to a table that uses the less specific "background" (after following this page's examples) causing some sort arrows to be disabled. It's a recommendation for the less savvy. Jroberson108 (talk) 17:12, 15 March 2024 (UTC)

I did a mass-replace of style="background: with style="background-color:

See diff.

Here is an edit summary for a mass find-and-replace for a whole article with multiple tables:

Replace style="background: with style="background-color: - See [[Help:Table#Colors in tables]] and [[Help:Table#Background colors for column headers]]

Replace style="background: with style="background-color: - See Help:Table#Colors in tables and Help:Table#Background colors for column headers

--Timeshifter (talk) 19:22, 15 March 2024 (UTC)

Need wrapping of the "Announced" column

Note: This concerns the table here: List of iPhone models#Release dates.

See the top table in this article version:

• https://en.wikipedia.org/w/index.php?title=List_of_iPhone_models&oldid=1213942519#Release_dates

All the other dates in the other columns will wrap when necessary. Scroll down the table to see. Narrow your browser window too, to see it more clearly.

The "Announced" column dates will not wrap. They use {{start date}}. --Timeshifter (talk) 01:39, 16 March 2024 (UTC)

Looks like that template uses non-breaking spaces ( ) instead of spaces, which prevents the wrapping. It lists some alternative templates at the bottom. It looks like {{start date text}} uses spaces, so it should wrap. Jroberson108 (talk) 05:27, 16 March 2024 (UTC)

Maybe there is a better template than that one. Also, that column doesn't appear sortable when {{start date}} is used. I recall {{Date table sorting}} needs to be used so it sorts correctly. It also uses normal spaces, so the date will wrap. Jroberson108 (talk) 05:46, 16 March 2024 (UTC)

Thanks. I switched to the abbreviated form of {{Date table sorting}}. It narrowed the column a little, but it does not sort. Which is weird because I thought that was the reason for its title. It does not wrap either. I put a soft hyphen {{shy}} in "Announced" text in header. That did not help. --Timeshifter (talk) 06:34, 16 March 2024 (UTC)

Looks like the "nowrap=off" parameter has to be added to disable the nowrap style. That template sets data-sort-value= for each data cell, so you will need to remove data-sort-type="date" from the header for it to sort. I noticed some of the other columns don't sort either. Maybe add this template for the date part of them too: "June 29, 2007; 16 years ago". Jroberson108 (talk) 07:11, 16 March 2024 (UTC)

Thanks again. That did the trick for the "Announced" column. Parts of the {{Date table sorting}} doc page are baffling, and poorly written. --Timeshifter (talk) 08:13, 16 March 2024 (UTC)

The {{start date}} template must not be used outside infoboxes. --Redrose64 🌹 (talk) 12:23, 16 March 2024 (UTC)