This page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit
the project page, where you can join the
discussion and see a list of open tasks. To browse help related resources see the
Help Menu or
Help Directory. Or ask for help on your talk page and a volunteer will visit you there.Wikipedia HelpWikipedia:Help ProjectTemplate:Wikipedia Help ProjectHelp articles
Material from
Help:Table was split to
Help:Tables and locations on 9 December 2023 from
this version. The former page's
history now serves to
provide attribution for that content in the latter page, and it must not be deleted so long as the latter page exists. Please leave this template in place to link the article histories and preserve this attribution.
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".
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
<tableclass=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)reply
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:
<tableclass=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)reply
They'll just be ejected out the top as plain text, same as <thead>. --
Redrose64 🌹 (
talk) 19:01, 16 August 2023 (UTC)reply
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)reply
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)reply
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)reply
@
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)reply
@
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)reply
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.
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:
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)reply
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>.
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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.HouseBlastertalk 03:21, 13 December 2023 (UTC)reply
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)reply
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)reply
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.HouseBlastertalk 16:46, 13 December 2023 (UTC)reply
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)reply
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.HouseBlastertalk 19:15, 19 December 2023 (UTC)reply
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)reply
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".HouseBlastertalk 22:24, 23 December 2023 (UTC)reply
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)reply
I think it is clear that we are not going to come to agreement here, so I have started an RfC. HouseBlastertalk 22:31, 24 December 2023 (UTC)reply
No, because the tool has nothing to do with tables. Information overload is a real problem. HouseBlastertalk 22:31, 24 December 2023 (UTC)reply
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)reply
To clarify, it should not be on this page anywhere.
Jroberson108 (
talk) 03:26, 12 February 2024 (UTC)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
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.HouseBlastertalk 23:48, 29 December 2023 (UTC)reply
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)reply
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. HouseBlastertalk 05:13, 30 December 2023 (UTC)reply
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)reply
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)reply
Chrome, Win 10, PC. The rendered code I'm getting at the top of the table looks like this:
<tableclass="wikitable"><tbody><tr><thcolspan="5"style="background: #AFFBEA; text-align: left; font-size: 125%;">Gratuitous
</th></tr><tr><thscope="col"style="background: #F9FACA; width: 20%;"><ahref="/wiki/Wikipedia:Barnstars#Topical_barnstars"title="Wikipedia:Barnstars">The Running Man Barnstar</a></th><thscope="col"style="background: #F9FACA; width: 20%;"><ahref="/wiki/Wikipedia:Barnstars#General_Barnstars"title="Wikipedia:Barnstars">The Working Man's Barnstar</a></th><thscope="col"style="background: #F9FACA; width: 20%;"><ahref="/wiki/Wikipedia:Barnstars#General_Barnstars"title="Wikipedia:Barnstars">The Defender of the Wiki Barnstar</a></th><thscope="col"style="background: #F9FACA; width: 20%;"><ahref="/wiki/Wikipedia:Barnstars#Category_barnstars"title="Wikipedia:Barnstars">The <styledata-mw-deduplicate="TemplateStyles:r1003227249">?'"`UNIQ--templatestyles-00000005-QINU`"'?</style><varclass="var-serif">E</var>=<linkrel="mw-deduplicated-inline-style"href="mw-data:TemplateStyles:r1003227249"><varclass="var-serif">mc</var><sup>2</sup> Barnstar</a></th><thscope="col"style="background: #F9FACA; width: 20%;"><ahref="/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)reply
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)reply
@
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)reply
That prefs setting was it. I had completely forgotten it existed. —
SMcCandlish☏¢ 😼 23:43, 29 December 2023 (UTC)reply
Request for comments concerning Template: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)reply
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:
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)reply
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.
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)reply
"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.
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)reply
@
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)reply
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)reply
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)reply
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)reply
"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)reply
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)reply
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)reply
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)reply
I have not repeated myself. I have responded to your points one by one. --
Timeshifter (
talk) 05:35, 12 February 2024 (UTC)reply
I oppose including the link anywhere on this page. It has nothing to do with tables.
Jroberson108 (
talk) 03:38, 12 February 2024 (UTC)reply
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)reply
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)reply
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)reply
Comment for others reading this. See Phabricator tasks:
Please comment there so that developers know there is a continuing desire for a TOC toggle that alternates between expand all and collapse all. --
Timeshifter (
talk) 03:27, 8 May 2024 (UTC)reply
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)reply
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:
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)reply
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)reply
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.
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)reply
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)reply
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)reply
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)reply
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)reply
I did a mass-replace of style="background: with style="background-color:
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)reply
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)reply
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)reply
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)reply
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)reply
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)reply
The {{
start date}} template must not be used outside infoboxes. --
Redrose64 🌹 (
talk) 12:23, 16 March 2024 (UTC)reply
Help table header
With all those links to main page's subpages one gets easily in the sea of links. To resolve that, I feel a help table header is long overdue, hence why I am opening this discussion.
Qwerty284651 (
talk) 06:07, 1 June 2024 (UTC)reply
I don't understand what you are asking. Please clarify.
A template would be nice. That would save me some work adding new table help pages. I may create a template. --
Timeshifter (
talk) 16:45, 1 June 2024 (UTC)reply
These links categorized by tabs:
basic, advanced. Haven't come up with a list of tabs of which like would go where.
Qwerty284651 (
talk) 20:45, 1 June 2024 (UTC)reply
What would you put it in? --
Redrose64 🌹 (
talk) 20:00, 1 June 2024 (UTC)reply
{|style="border:solid 1px; padding-left:4px; padding-right:4px;"|For more help, see [[Help:Table]], [[Help:Introduction to tables with VisualEditor/1|Help:Tables and VisualEditor]], [[Help:Creating tables]], [[Help:Introduction to tables with Wiki Markup/1|Help:Wikitable]], [[Help:Basic table markup]], [[Help:Table/Advanced]], [[Wikipedia:Advanced table formatting|WP:Advanced table formatting]], [[Help:Tables and locations]], and [[Help:Sortable tables]]. For style info, see [[Wikipedia:Manual of Style/Tables]]. For accessibility, see [[Wikipedia:Manual of Style/Accessibility/Data tables tutorial]].
|}
It requires full internal links under any shortened labels. So that the link is black, bold, and unclickable when the template is on that page. If you use a shortcut in the template (such as
Help:Wikitable) as the underlying link, it will be clickable on that page.
I say go for it. And then replace all headers in the pages above with the template. Sort of a like a predecessor to the header. A transition.
Qwerty284651 (
talk) 11:32, 2 June 2024 (UTC)reply