Help talk:Table/Archive 9

Archive 5

←

Archive 7

Archive 8

Archive 9

Archive 10

Line breaks

Note. The first post in this thread was moved from a talk page to here.

Yo, I noticed you just changed two <br /> to <br> at Help:Table. I'm curious as to your reasoning as H:BR seems to indicate that the version with the space and slash is preferred: "While valid forms without the / (such as <br> or <br >) will work properly in the rendered page because modern browsers are forgiving of malformed HTML, they can break several of the available syntax highlighters for wiki code in the editing view (mis-highlighting all text in the page after the occurrence of that tag), and so should be avoided."

I know use of <br> is very common. Anderjef (talk) 16:07, 4 February 2023 (UTC)

Anderjef. Help:Line-break handling is not a Wikipedia guideline or policy.

Please see Help talk:Line-break handling#Let us ignore syntax highlighters that do not accept <br>

Most people in that thread want <br> used. It is a detailed discussion in that thread. With participation from editors, developers, admins, etc.. --Timeshifter (talk) 00:13, 5 February 2023 (UTC)

I believe that the reason for <br /> is XHTML, and that HTML5 has displaced it in the browser world. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:26, 5 February 2023 (UTC)

See also Wikipedia talk:Line breaks usage and the section titled: <br> vs <br />

David Göthberg's reply in that 2006-2008 thread explains things well. He is a programmer. --Timeshifter (talk) 15:29, 9 February 2023 (UTC)

Both forms (HTML and XHTML) are valid Wikitext and I haven't read anywhere that one version must be used. The output to the browser is <br /> even if <br> is published, which is visible through curl or view page source (not inspect). If a gadget doesn't support both, then the gadget should be fixed to support what the MediaWiki software supports. I agree with David Göthberg's points, but its up to the editor to choose which version they wish to remember and use or they can just click the "New line" button. Jroberson108 (talk) 17:41, 9 February 2023 (UTC)

People can use what they want, but it is also OK for other users to change it to the simpler form. Especially on help pages where the KISS principle should operate. Another thing to note is that the space in <br /> allows it to split in half and to wrap in wikitext editing windows. Try it now and see by downsizing your browser window and dragging it wider or narrower until you see it wrap like that. That is bizarre to editors new and old. Please don't use <br />.

David Göthberg noted in 2008: "Also up until recently all documentation listed <br> as the code for forced line breaks. But some months ago some XHTML enthusiasts went around and edited a lot of the help pages to show the <br /> or even the <br/>." --Timeshifter (talk) 20:59, 9 February 2023 (UTC)

I will point out that MOS#Retaining existing styles suggests the existing style be left (even when the MoS supplies "no specific guidance"). That being said, one of Wikipedia's five pillars is Wikipedia has no firm rules, and I tend to find myself leaning toward your position @Timeshifter. Anderjef (talk) 21:48, 9 February 2023 (UTC)

I am only hard core on help pages. :)

Where "there is some substantial reason for the change." --Timeshifter (talk) 21:58, 9 February 2023 (UTC)

I'll add a few more points. Something added in 2008 (15 years ago) isn't a valid argument against it, but actually gives weight for continued support. The point about <br /> wrapping is a none issue since editors that do edit in code/source view expect code/markup to wrap, which plenty does (ex. citations) and we know to look for the ending similar to punctuation that ends a sentence. As for my preference, I'm OK with using either one and won't change the code to suite a personal preference that doesn't even affect the displayed content. If the goal is to reduce options and things editors have to remember (KISS), then I would recommend only allowing <br> and disallowing <br />, which the "New line" button inserts the former even though the latter is outputted to the browser. That would require a vote from the community. In a similar manner of sticking with KISS, I would also recommend requiring double quotes for arguments that only have one value like class="wikitable", which again is what the "Table" button inserts and double quotes are always outputed to the browser even when missing or single quotes are used. This would mean less to remember in regards to when quotes are optional and when they are required. As a programmer, I would think this cleanup of coding standards would have been implemented as the "Publish changes" button is clicked, but the MediaWiki software does it during render and not during save. Wikipedia doesn't follow strict coding standards and probably won't change so many standards are supported. Jroberson108 (talk) 04:32, 10 February 2023 (UTC)

I would recommend getting a vote from the community on a recommended style of code that mimics what the editing software inserts verbatim, which should represent the majority of the use cases and help to stick to an already accepted standard. Also, recommend standards that would lessen what editors would have to remember even if it isn't handled by the editing software. It's obvious that the software inserts spaces for readability, so continue with that recommendation. An editor would have to go out of their way just to change what is inserted by the software. Example:

• <br> is recommended. Using an XHTML tag (ex. <br />) is acceptable.
• == Header text == is recommended. Omitting spaces around the markup (ex. ==Header text==) is acceptable.
• {{cite |title= |last= |first=}} is recommended. Omitting spaces around parameters (ex. {{cite|title=|last=|first=}}) is acceptable.
• class="wikitable" is recommended. Omitting the quotes (ex. class=wikitable) is acceptable except when there are multiple classes, which requires the use of spaces and quotes.
• style="text-align: center;" is recommended. Omitting the space, quotes, and semicolon (ex. style=text-align:center) is acceptable except when there are multiple styles, which requires the use of semicolons and quotes. A space after semicolons (except the last style) and colons is recommended for consistency and readability sakes.

Jroberson108 (talk) 07:05, 10 February 2023 (UTC)

The 2008 argument is not the only one. See the long recent thread:

• Help talk:Line-break handling#Let us ignore syntax highlighters that do not accept <br>

Consider that as our more recent RFC. It got many replies. There is no MOS guideline that says we should be using <br />. I don't think there is any official policy or guideline page that says that.

I especially like this example from David Göthberg in 2008:

Well, let's first ask another question: Which markup should we use for bold text? '''Bold''' <b>Bold</b> <span style="font-weight:bold;">Bold</span> I think we all know that the wikimarkup '''Bold''' is the recommended one. Mainly because it is simpler to use, especially for the majority of editors that don't know HTML and CSS.

In my opinion anything but the standard Mediawiki method '''Bold''' is ridiculous, and I change to it anywhere I see the other versions. I don't want other editors, especially new editors, to start using the other methods. Or thinking that they need to remember such arcane unnecessary coding. That discourages new editors. Wikipedia is successful precisely because it is much simpler than other page editing methods on the web. --Timeshifter (talk) 17:41, 10 February 2023 (UTC)

I've already read that discussion since it was posted on your first reply, which is why I made the comment on fixing the gadget if it doesn't support the same formats that the MediaWiki software supports. Three single quotes for bold (ex. '''Bold text''') is what the MediaWiki editor inserts, so it too should be the recommended format with downgraded allowances for other formats. As David Göthberg mentioned, "we all know [this bold format] is the recommended one", but if you read MOS:BOLD you will see that no one format is recommended. I still recommend what I said in my previous reply on getting consensus to set what the MediaWiki editor inserts as the recommended formats on the help pages so things are more consistent. Make it official. Jroberson108 (talk) 18:43, 10 February 2023 (UTC)

MOS:MARKUP regards wikitext over HTML. Anderjef (talk) 20:20, 10 February 2023 (UTC)

MediaWiki editors change depending on what the developers do. And the developers often put stuff out without consensus of editors as a whole. There are huge fights over this. I use 2010 legacy Vector. It does not have a new line button in the wikitext edit window.

And MOS:MARKUP is official: "Other things being equal, keep markup simple. This makes wikitext easier to understand and edit, and the results seen by the reader more predictable. Use HTML and CSS markup sparingly."

MOS:BOLD does not recommend using the arcane bold coding alternatives mentioned by David Göthberg. Its only other bolding options besides '''...''' are <strong>...</strong>, or the template {{strong}}. I don't replace those. --Timeshifter (talk) 23:41, 10 February 2023 (UTC)

Again, no one format is recommended on the bold, newline, and probably many other help pages I mentioned in my examples. If you want more consistancy, then take the next step so it becomes clear on those help pages which one format is preferred and recommended. If not, then it's meaningless to discuss here on a talk page that hardly anyone follows. I'm done repeating myself and discussing unless you want to move forward. Jroberson108 (talk) 04:12, 11 February 2023 (UTC)

The problem with help pages is that like Help:Table they are not Wikipedia policies or guidelines. For example: Help:Line-break handling. The majority of people at the recent discussion there want that <br /> is no longer recommended there. But the regular editors there have yet to change that. I may be bold and do it, but prefer to wait a bit while these other discussions go on here and elsewhere.

I think that MOS:MARKUP is pretty clear. Also, I am less concerned with consistency, and more concerned with simplicity. For example; quotes are not needed except mainly when there are spaces. Once one learns that then it is far simpler to add the simpler version without the quotes. I edit a lot of tables, and find that to be true. But I don't want to force my version of simplicity on others for such a minor thing. If using quotes in all cases is easier for some people then let them continue to do so until they understand the point about spaces. I used to put quotes on everything. --Timeshifter (talk) 07:57, 11 February 2023 (UTC)

Scrolling tables and sticky headers.

Could someone please write basic instructions here on how to make certain rows or columns sticky in scrolling tables? The section currently only refers to articles which have them (but don't actually have horizontally scrolling tables with sticky headers contrary to the claim) and series of discussions which are Chinese to someone who does not have a degree in IT.Tvx1 17:16, 3 April 2023 (UTC)

The problem really is twofold. Firstly, scroll markup is part of the CSS language and not part of Wikitext or any Wikipedia extension. CSS in turn comes under the world wide web HTML5 umbrella. Before you can have a clue what is going on in say Template:COVID-19_pandemic_data/styles2.css you will need a good understanding of CSS and its scrolling model. Secondly, they tend to get tangled up in complicated dicing-and-slicing of pages into transcluded fragments by our editors. The guidelines at MOS:SCROLL appear to be well out of date and of doubtful help. This help page's mantra that nested tables cause accessibility problems is also about 20 years out of date; modern readers cope just fine and floating divs which break normal flow are a far worse nightmare. Any sane edits to the help would almost certainly draw down the angry priests of the last millennium and no consensus for change could be established. The way ahead would be to put together a viable modern solution, test it out on some real-world users of accessibility aids, get feedback from the same users on how crap the squalid old mantras are, and then seek a revised, evidence-based consensus on what to say here. Learning CSS for yourself is probably the less arduous road. — Cheers, Steelpillow (Talk) 18:08, 3 April 2023 (UTC)

Graham87 is an admin, is blind, and uses a screen reader. He said divs work fine for allowing multiple tables, etc. to wrap, and still be accessible. See diff.

See: Help:Table#Side by side tables.

See: Help:Table#Side by side tables and images.

I am all for getting more feedback from more people using screen readers.

About nested tables and accessibility:

https://www.google.com/search?q=nested+tables+and+accessibility

It seems nested tables are not accessible for the most part. I see some search results about how to make them accessible. --Timeshifter (talk) 19:52, 3 April 2023 (UTC)

First, I followed through one of your examples and the layout was just badly designed (nested header cells); using rowspan instead would have rendered the reader's audio output equally baffling. Design a complex table sensibly and both methods of implementation will yield sensible results. Second, don't forget that many web page creators still use headerless tables for page layout, because the code is often far easier to stabilise across disparate rendering devices than the equivalent div styling; I checked nested-table test code with one user and their reader did not even bother to inform them that a table structure was present. On the other hand an alternative implementation with divs and CSS that broke normal flow was rendered unintelligible. The important thing is not which markup you use but how you use it to produce a clean semantic flow in the page code. This is what really helps screen readers to present it intelligibly. For what it's worth, the "nested tables bad" mantra arose back in the last millennium, with early versions of like Microsoft FrontPage and Macromedia (as it then was) Dreamweaver. These tools used nested tables ad nauseam for page layout; they would even dice-and-slice an image and fit the pieces in the table cells! The mantra rightly had to be dinned into the programming community - the authoring tool creators, but wrongly broadened its aim to include the tool users - the page designers and content creators. It was then cemented in place by ignorant repetition and bad examples such as the ones you gave. Now it is carved in stone and you read it on the Internet, so it must be right. Oh, brother! — Cheers, Steelpillow (Talk) 04:45, 4 April 2023 (UTC)

Most of what you discussed is way beyond my skill level. I was only pointing to some very specific Wikipedia problems concerning wrapping of tables and/or images. Those are the sections I linked to, and helped edit, after Graham87 commented on the problem.

I did not write the nested tables sections of Help:Table. And Help:Table is for Wikipedia editors and Wikipedia pages, not other websites, nor for web page design. Wikipedia's design is done by the developers. Feel free to edit the nested table sections. I never use nested tables on Wikipedia. If you know of ways to use them, and have them be accessible to modern screen readers, then please edit that section. --Timeshifter (talk) 05:31, 4 April 2023 (UTC)

OK, I have had a go at it. Will be interesting to see if it sticks. — Cheers, Steelpillow (Talk) 06:51, 4 April 2023 (UTC)

Are you really sure it requires CSS? I found this discussion in this talk page’s archives, which does include an example of simple wiki markup to make headers sticky.Tvx1 00:44, 4 April 2023 (UTC)

The point is that the "wikitext" you refer to includes fragments of HTML+CSS, such as style="position:-webkit-sticky; position:sticky; top:-1px; left:-1px; z-index:1;" embedded in the markup. So yes, I am very sure that you need to understand what this CSS is doing if you want to use it effectively and/or debug your display. — Cheers, Steelpillow (Talk) 04:45, 4 April 2023 (UTC)

Tracked in Phabricator
Task T42763

Tvx1. That talk archive section you link to has this Phabricator task (look to the right):

It looks like they haven't solved the problem, and made a simple solution yet.

I updated and clarified the scrolling tables section of Help:Table. --Timeshifter (talk) 06:28, 4 April 2023 (UTC)

Data table under Economy of India is not updated

Hello,

The recently revised GDP data (released on 28th February) is not reflected in the table for the column GDP (real). you may want to change that. Else, I can do it if you can hep me understand how to edit the table.

Thanks, Kunalkumarkundu (talk) 08:19, 8 April 2023 (UTC)

Kunalkumarkundu. Welcome. I see that your post here is your first post on English Wikipedia with a user name.

Economy of India. Where exactly are you talking about? What section of the article? --Timeshifter (talk) 08:56, 8 April 2023 (UTC)

Rowspan making row disappear

I'm trying to merge two cells in the table at The Eras Tour#Venue records using the rowspan attribute but it's making the entire row disappear. The attribute works fine elsewhere in the same table. I've uploaded some images to Imgur to illustrate the problem. Can anyone help? Thanks. Shuipzv3 (talk) 13:36, 29 June 2023 (UTC)

@Shuipzv3: Looks like GustavoCza already fixed it? Issue may have been the "rowspan" on the preceding date cell. Jroberson108 (talk) 21:35, 29 June 2023 (UTC)

@Shuipzv3: Assuming that the portion in question is this

List of venue-based achievements, showing year, dates, venue, country and description

Year	Dates	Venue	Country	Description	Ref.
2024	February 16–18	Melbourne Cricket Ground	Australia	Biggest virtual queue in Australian history, with four million customers.
	February 23–26	Accor Stadium
				First act in history to schedule four shows on a single tour.
	March 2–4 and 7–9	Singapore National Stadium	Singapore	First solo act in history to schedule three, four, five, and six shows on a single tour.

the row hasn't disappeared, its vertical height has been reduced to the minimum necessary to display the cell contents. If you artificially constrain the width of the Description column to a smaller value, the cells will wrap and then the presence of that row becomes clear:

List of venue-based achievements, showing year, dates, venue, country and description

Year	Dates	Venue	Country	Description	Ref.
2024	February 16–18	Melbourne Cricket Ground	Australia	Biggest virtual queue in Australian history, with four million customers.
	February 23–26	Accor Stadium
				First act in history to schedule four shows on a single tour.
	March 2–4 and 7–9	Singapore National Stadium	Singapore	First solo act in history to schedule three, four, five, and six shows on a single tour.

Basically, browsers don't make a row any taller than it needs to be to hold its contents. --Redrose64 🌹 (talk) 22:10, 29 June 2023 (UTC)

@Redrose64: Thanks for your help. Shuipzv3 (talk) 00:36, 30 June 2023 (UTC)

@Redrose64: So the issue is that a number of cells with multiple rowspans is not appearing correctly, e.g. "Biggest virtual queue", "February 23–26", "Accor Stadium"; "Australia" should be 3 rowspans instead of 2 and "2024" should be 4 rowspans instead of 3. In other words, there should be a row that goes: "2024, February 23-26, Accor Stadium, Australia, Biggest virtual queue..." Because the vertical height has been reduced, this row is not appearing at all. It looks like "Biggest virtual queue..." only applies to Melbourne Cricket Ground only instead of that and Accor Stadium. Is changing the description the only way of forcing this to appear? Shuipzv3 (talk) 00:56, 30 June 2023 (UTC)

Quotes are not needed unless there is a space in the value

Note: This started on a user talk page,

This has been previously discussed on the table talk pages. Please don't revert without consensus. Quotes are not needed unless there is a space in the value. Look it up. --Timeshifter (talk) 15:25, 3 May 2023 (UTC)

Just because you decided something, does not mean it is so. Quotes are used throughout the pedia much more than unquoted strings. The edit I did, fixed inconsistent usage on those pages, while your edit was purely cosmetic and of your own preferred style. Gonnym (talk) 21:52, 3 May 2023 (UTC)

Gonnym. Just because you decided something, does not mean it is so. It works both ways. Stop your edit war, and look through the talk archives. Just because people are unaware of how to use quotes doesn't mean we should continue to add quotes when unnecessary.

You know I am right about them being unnecessary except for when there are spaces in the values. Because the CSS worked fine without them before you went on your "consistency" tear on multiple help pages, etc.. --Timeshifter (talk) 00:30, 4 May 2023 (UTC)

I can't speak for Gonnym, but I don't think anyone is saying you are not right about them being unnecessary except for when there are spaces in the values. My point has always been that consistency is an aid to the reader (and let's respectfully call them the "help-less user"). If we give examples that consistently show property="value", then users can—more quickly, says I—see how the things work. (The format is consistent with how HTML and CSS work, which is beneficial if they've seen that.) And if they then try to change from our provided examples to something with a space or multiple values, then there's less chance that the thing breaks inexplicably. In that case we offer more helpful help, which is the goal.

And on that last point, the recent edit of yours, Timeshifter, with the edit summary Help pages are about simplicity caught my eye, as I feel differently about it. I'd say, "Help pages are about helpfulness, that is, understandability". There is such a thing as too simple, and while we're not arguing about quantum mechanics-level complexity, it behooves us to be indulgent to those who don't immediately know the fine points about space- or comma-including values. — JohnFromPinckney (talk / edits) 10:29, 4 May 2023 (UTC)

I used to be confused by all the quotes around everything, but like the newbie we all are at first I followed the herd. Because few showed the CSS operating without the quotes. Once I found out the reasoning for the quotes it made my editing of data tables much easier. Especially when aligning text in columns. I used quotes much less. I removed spaces sometimes to do so. Especially helpful for mass find-and-replaces.

So let's use the quotes the correct way, and newbies and regular editors will follow our correct examples on this help page. It's not at all difficult to understand. I can say from experience that in my case the overwhelming use of quotes only confused me and slowed me down. Don't assume that consistency is easier in all cases. --Timeshifter (talk) 11:45, 4 May 2023 (UTC)

I've had a similar discussion with Timeshifter. Saying that it is "correct" to omit quotes when they are optional is in fact incorrect. All it amounts to is a personal preference for minimalist code. Depending on your view, you could say "Unquoted attribute values are optional in certain circumstances and not allowed in others". My preference is that double-quotes be used in all instances, at least on the help pages. A consistent format that works in all instances would cause noobs less confusion (less variants) and have less need to remember exceptions (space or certain special characters), which keeps it simple and easy. This better follows Wikipedia's desire for consistency (WP:MOS), which I will point out that three editors (including me) in this discussion have now brought up consistency. Jroberson108 (talk) 22:35, 4 May 2023 (UTC)

Where does it say in WP:MOS that we should tell people incomplete info? "space or certain special characters": What special characters are you referring to? Why not continue to omit the quotes when possible on the table help pages as we have been doing with few problems? "If it ain't broke, don't 'fix' it." We can put a section on the help page telling editors that they have the option to use quotes all the time on values. Let the editor decide. In the meantime they see in the wikitext of the table help pages the many cases where they don't need the quotes. People copy what they see in the wikitext. Do you not believe me when I tell you it saves a lot of time? Or is it "consistency above all". I actually have had people (morons in my opinion) who have added quotes on a functioning table I just created. Do we want to encourage that? I will create a section in the help page explaining the options, and that people shouldn't "correct" existing tables by adding quotes. If you consistarians want to make lives more difficult for table editors, then you can add double quotes to everything on the table help pages. But you are assuming editors are stupid. --Timeshifter (talk) 23:42, 4 May 2023 (UTC)

Some context would be good. The only direct suggestion as to what all this is about is the link in JohnFromPinckney's post of 10:29, 4 May 2023 (UTC) shown as "recent edit of yours". So, is it whether to write <syntaxhighlight lang="wikitext"> or <syntaxhighlight lang=wikitext>. I can tell you that it really does not matter. The value of the lang= parameter only needs to be quoted if it contains either spaces, quotemarks, less-than or greater-than, but that's about it. Indeed, in the list of available lexers, I cannot find any entries where the short names include any of those five characters, so for practical purposes, the value of the lang= param of the <syntaxhighlight> tag never needs to be quoted. The syntaxhighlight feature is part of mw:Extension:SyntaxHighlight, and being processed by MediaWiki, is not subject to the same rules as CSS or HTML (which are less tolerant). It is certainly not worth edit-warring about. --Redrose64 🌹 (talk) 16:46, 9 May 2023 (UTC)

My previous discussions with Timeshifter involved style and class attribute values. This recent edit war on this article was about the lang attribute, specifically removing quotes because they are optional. I've seen this kind of editing on other help pages too. I took the discussion to be about all attributes on all help pages and what is seen by editors unfamiliar with the options. Editors in this discussion are aware of spaces requiring quotes. As I recall, there are a few more than what you listed that require quoting such as equal (=) and tick (`). There use to be a section on one of the help pages describing the variations (double-quoted, single-quoted, and unquoted attribute values), but I can't find it anymore. Perhaps it was deleted? Jroberson108 (talk) 22:39, 9 May 2023 (UTC)

For style= and class= attributes of HTML tags, their values normally need to be quoted, unless the only characters found in the value are the digits 0-9, the letters A-Z and a-z, the full stop and the hyphen-minus (64 different characters). The value of a style= attribute is a valid CSS declaration block, which is a semicolon-separated list of zero or more CSS declarations. Since a valid non-empty CSS declaration always contains at least one colon (which is not among the 64), it follows that the value of a style attribute will always be quoted, e.g. style="background:yellow". As for class=, the value of this attribute is a set of space-separated tokens representing the various classes that the element belongs to. Since these tokens can be formed from any non-whitespace ASCII characters, it follows that e.g. class="wikitable sortable" and class="!vote" both need to be quoted, but class=wikitable does not. --Redrose64 🌹 (talk) 23:31, 9 May 2023 (UTC)

I did some more searching for that help section I mentioned. The only help sections I could find on attributes are Help:Basic table markup#HTML attributes, Help:Table#HTML attributes, and Help:HTML in wikitext#Attributes, which all link to the HTML attribute article page for further reading. The help page sections only discuss double-quoted attribute values (attribute="value"), while the article page uses double-quoted, mentions a single-quoted option, and discourages unquoted. The original help section I remember from a few years ago that discussed all three options was either deleted or changes for some reason, probably for simplicity and consistency, but someone would need to do more digging. Jroberson108 (talk) 23:58, 9 May 2023 (UTC)

Please explore the versions of Help:Table before User:Timeshifter started editing at 2018-09-09. Every attribute values are quoted. So this means that he started replacing it with unquoted attribute values after that.Cedar101 (talk) 06:32, 10 May 2023 (UTC)

Yeah, it's a plot to remove quotes. And few people complained over the years. Because few people like extra work for no good reason. Except for a few consistarians who like rules that exist only in their minds. I edited Help:Table the same way I edited tables in articles. As I learned more I removed useless stuff that annoyed me. We can put in a section in Help:Table giving people the options, and let them choose what is simplest for them. I started by adding quotes to everything. Then I wised up with experience.

And my oldest edit is from August 12, 2009. Some edits in 2011, 2012, 2015, 2018, etc..--Timeshifter (talk) 16:29, 10 May 2023 (UTC)

Redrose64. Quotes are not needed for a style declaration block of single or multiple property:value pairs if there are no spaces or prohibited characters.

• https://css-tricks.com/problems-with-unquoted-attributes

You can search the Help:Table page for style= and go down the page and see many examples of style declaration blocks with a single property:value pair without quotes. Because the space has been removed. For example: style=text-align:left

But it is also true for multiple property:value pairs one after another. As long as the spaces are removed. For example:

• <div style=display:inline-table;vertical-align:top;>

You may not find any examples on Help:Table. I kind of like separating the property:value pairs for easier reading. But I find the quotes around a single property:value pair annoying. I can add the styling quicker to a table without the quotes. And the final semi-colon in a declaration block is unnecessary: style=text-align:left --Timeshifter (talk) 06:06, 10 May 2023 (UTC)

See HTML Style Guide and Coding Conventions - W3Schools.

Always Quote Attribute Values
HTML allows attribute values without quotes. However, we recommend quoting attribute values, because:

• Developers normally quote attribute values
• Quoted values are easier to read
• You MUST use quotes if the value contains spaces

Cedar101 (talk) 09:06, 10 May 2023 (UTC)

Wikitext is not HTML, nor XML, nor XHTML, etc.. Even though it copies many of their rules. Wikitext is simpler. If you desire to put quotes around everything, no one is stopping you.

I personally don't like to waste my time adding quotes to things like rowspan=2 and colspan=2 and class=wikitable and style=text-align:left and lang=wikitext

See MOS:SIMPLIFY and the KISS Principle. Do whatever is simplest for you. If adding the quotes to everything is simpler for you, then do it. But don't tell others they have to do it too. And don't go around in articles and "correct" others by adding quotes to everything. It only shows your ignorance. --Timeshifter (talk) 16:10, 10 May 2023 (UTC)

Consistency is a form of simplicity. Consistency makes it easy to deal with the world. Omitting quotation marks is an unnecessary extra rule and complexity. All articles on Wikipedia are not the work of a single individual user and should follow common sense conventions agreed upon by the majority of users. Cedar101 (talk) 00:41, 11 May 2023 (UTC)

And that common sense rule is that what is simplest depends on the person. "Consistency is the last refuge of the unimaginative." By Oscar Wilde. "The lawyer's truth is not Truth, but consistency or a consistent expediency." By Henry David Thoreau. "A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines." By Ralph Waldo Emerson. "Consistency is contrary to nature, contrary to life. The only completely consistent people are dead." By Aldous Huxley. "Rule-following, legal precedence, and political consistency are not more important than right, justice and plain common-sense." By W. E. B. Du Bois. "Consistency is the most overrated of all human virtues... I'm someone who changes his mind all the time." By Malcolm Gladwell. "Consistency requires you to be as ignorant today as you were a year ago." By Bernard Berenson. "True consistency, that of the prudent and the wise, is to act in conformity with circumstances and not to act always the same way under a change of circumstances." By John C. Calhoun. "Consistency is found in that work whose whole and detail are suitable to the occasion. It arises from circumstance, custom, and nature. By Vitruvius. "Consistency is the paste jewel that only cheap men cherish." By William Allen White. --Timeshifter (talk) 04:35, 11 May 2023 (UTC)

You have a major misconception about Wikipedia. Wikipedia articles are not literature, they are encyclopedic texts written collaboratively by many users. You shouldn't use rules that are dependent on any one user, but rather conventions that are agreed upon by all users of Wikipedia.

Since you have been the main editor of this help document in recent years, it is not that you have agreed to write it differently from other articles, only that other editors who cannot spend enough time on it have neglected it to avoid unnecessary editorial disputes. Cedar101 (talk) 07:32, 11 May 2023 (UTC)

It isn't just that other editors cannot spend enough time on it, it's also that we're not allowed to edit his page. The maddening air of ownership keeps people away who may have useful input and the ability to improve the article. There's not necessarily an explicit consensus (about quotation marks, use of bold, tone, shilling of LibreOffice, etc.), but a lack of appetite to argue with someone who seems unable to accept other views. — JohnFromPinckney (talk / edits) 11:10, 11 May 2023 (UTC)

• I was (Summoned by bot). While not a fan of sections that begin with "Note: This started on a user talk page, This has been previously discussed on the table talk pages," with no links or diffs, I have to agree with Timeshifter's MOS:SIMPLIFY that is reflected in the KISS principle. I also agree with "Don't tell others they have to do it" even though I would probably not have an aneurysm if someone added quotes for some markup reasoning. I would be against some local consensus to "mandate" something many, Wikipedia-wide, might have a problem with. This would be especially problematic if "HTML allows attribute values without quotes" is true. I assume there is content: "There is a simplified version of this page at Help:Wikitable", because this "how-to guide" might be complicated for some. I did not see any figures on article counts "include quotes versus exclude quotes". I am pretty sure that there are many articles using tables I would think a change as suggested would be better brought up at Wikipedia:Manual of Style/Tables that also has Wikipedia:Manual of Style/Accessibility/Data tables tutorial. I would think this would need a more broad community consensus or it might be a "rule" that is more often ignored. -- Otr500 (talk) 20:59, 12 May 2023 (UTC)

This discussion has been so blown out of proportion that it's hard to tell what is actually being discussed. As far as I can tell, there isn't any discussion about changing article pages or mandating new rules as the user Otr500 mentioned. The discussion is more about a few help pages that have been purposefully changed from consistent double-quoted HTML attributes to some unquoted ones out of what seems like one editor's personal preference, which appears to go against MOS:VAR and accordingly should be changed back to the original style until a consensus is reached on a "substantial reason" to change them to unquoted.

There are already a few help sections that only mention double-quoted attributes without mention of single-quoted or unquoted versions. I recall several years ago there was a help section that discussed the double-quoted, single-quoted, and unquoted options, but that has since been simplified to double-quoted attributes probably for good reason. If these sections need to be modified so editors are aware of the single-quoted and unquoted syntax that some editors may still use on article pages, then discuss that with a broader audience.

• Help:Basic table markup#HTML attributes: attribute="value", {| class="wikitable" style="color:red", etc.
• Help:Table#HTML attributes: class="wikitable"
• Help:HTML in wikitext#Attributes: name="value", and says "A best practice is to use the proper syntax: Double-quotes all attribute values."

Editors probably should follow these help sections in regards to attributes, which would basically invalidate the need for this discussion. There may be a few exceptions where single-quoted or unquoted are needed such as passing an attribute name-value pair into a template as a parameter (Help:Template#Parameters), but those rare needs are probably discussed on the individual template pages.

All three help sections link to the HTML attribute article page for further reading, which again uses attribute="value" throughout and says "The value may be enclosed in single or double quotes, although values consisting of certain characters can be left unquoted in HTML (but not XHTML). Leaving attribute values unquoted is considered unsafe." Obviously, Wikipedians should follow the styles and guidelines on the help pages, which will stay within the boundaries of what is and isn't allowed with HTML attributes.

Timeshifter has pointed out that Wikitext is not HTML. Although this is true, we aren't discussing Wikitext or HTML. We are discussing HTML attributes, which Wikipedia's markup and templates can use as the help sections indicate ("HTML attributes").

I will also point out that the Wiki Markup guide at Help:Wikitable as well as the insert table button on the page editor (visual and source) also use double-quoted attributes for tables ({| class="wikitable"), a standard that seems to be repeatedly used. An editor would have to go out of there way just to remove the default double-quoted format from every table they insert.

In my opinion, making all attributes double-quoted:

• follows a consistent style emphasized on WP:MOS where unquoted can only be used in certain circumstances
• follows the standard found in the above mentioned Wikipedia help sections and article page, standard inserted by Wikipedia's page editor, standard used in the Wiki markup guide mentioned above, and standard recommended by W3C ("We recommend using quotation marks even when it is possible to eliminate them." W3C 3.2.2 Attributes)
• reduces the need to remember exceptions for when unquoted is allowed, which better follows MOS:SIMPLIFY and KISS principle:
  • "[unquoted] attribute value may only contain letters (a-z and A-Z), digits (0-9), hyphens (ASCII decimal 45), periods (ASCII decimal 46), underscores (ASCII decimal 95), and colons (ASCII decimal 58)" W3C 3.2.2 Attributes
  • OR can contain text and character references, and must not contain space, """ (double-quote), "'" (single-quote), "=", ">", "<", or "`" (tick) characters, and can't be empty W3C Unquoted attribute-value syntax
• works in all instances with the exception of a literal double-quote character reducing issues when editors modify the value and are unaware of the requirement to convert unquoted to quoted because both the page they are editing and the example they are following weren't quoted, as well as other potential issues described at Why attribute values should always be quoted ...

Jroberson108 (talk) 04:15, 13 May 2023 (UTC)

Wikitext is not HTML. MOS:VAR actually goes along with what I have been saying. Don't "correct" tables in articles by adding unnecessary quotes.

Help:Line-break handling (after months of discussion) follows the MOS:VAR advice. See the section titled "<br>". It doesn't enforce one viewpoint.

<br> <br>, <br >, <br/>, <br /> Use whichever form is simplest for you to remember. The MediaWiki software uses any of them for a single forced line break. All of them are converted to <br /> in the HTML that browsers read. All other forms will display as just plain text, and will not create line breaks. Please correct them. For content that is semantically a list, such as in infoboxes, actual list markup is preferred. See § Lists below. Markup Renders as And this line of text<br>will break in the middle. And this line of text will break in the middle. Examples below. 5 accepted forms, and 2 that display as plain text. Wiki source One <br>Two <br >Three </br>Four <br/>Five <br />Six < br>Seven </ br>Eight Rendered result One Two Three Four Five Six < br>Seven </ br>Eight

--Timeshifter (talk) 09:58, 13 May 2023 (UTC)

Not sure why you are discussing line-breaks, which seems irrelevant to the discussion at hand. You attempted to change the style of HTML attributes from double-quoted to unquoted on this page multiple times, and apparently have been doing the same on other help pages. Thus far in this discussion consensus disagrees with your changes. That's what started this discussion, so stick to the topic (WP:TALK#TOPIC). Arguing a personal point of view goes against WP:TALKPOV. Give a substantial reason as to why the style of HTML attributes should be changed from double-quoted to unquoted on these help pages ("When either of two styles are acceptable it is inappropriate for a Wikipedia editor to change from one style to another unless there is some substantial reason for the change." MOS:VAR). This is exactly what you have been doing, change from one style to another. There is no reason this discussion needs to go on for "months", just keep it simple and follow guidelines by giving some substantial reasons for your changes. Any other changes can be discussed at WP:MOS where there is a larger audience. Jroberson108 (talk) 21:40, 13 May 2023 (UTC)

Redrose64 and Otr500 don't seem to agree with you. Help:Line-break handling is relevant because there were mainly 2 camps trying to push one form of <br> over another. I think you were part of the minority <br /> camp after discussion spread to this talk page too. I kind of pushed <br> though not as the only allowed choice. Finally we came up with not pushing for any of them. And that none were necessarily simpler than the other. Programmers like you favored <br /> since that was what you were used to. Redrose64 and I edited the final draft to mutual satisfaction, I believe. My initial insistence that <br> should be recommended because it is simpler for most non-programmers to remember is not in the final draft at all. I am happy with that. That's what we should do here. Point out that quotes are not necessary in certain circumstances, and let the editors decide what is simpler for them to use.

MOS:VAR: "Edit-warring over style, or enforcing optional style in a bot-like fashion without prior consensus, is never acceptable."

There has never been a consensus on this issue. This is the first substantial in-depth discussion. It has been literally years with both quotes and no quotes on the help page.

So there is no consensus to go bot-like over this help page and change everything to double quotes. Or even worse to encourage editors to go forth and do the same in a bot-like fashion in all articles with tables. Read more on the meaning of "bot-like" at MOS:VAR and the penalties for doing so (see notes B and D). --Timeshifter (talk) 23:50, 13 May 2023 (UTC)

When an attribute value is quoted, either single or double quotes may be used, neither is "preferred" over the other. There are really only two rules: (i) the opening and closing quotes must match; and (ii) where the value contains a quote character (of either type), the other type must be used as the delimiter. That is, style="font-family: 'Times New Roman', serif" and style='font-family: "Times New Roman", serif' are equivalent and equally valid. So just as unnecessarily removing quotes should not be encouraged, changing single quotes to double should also not be encouraged - unless it fixes a syntactical error such as style='font-family: 'Times New Roman', serif'. --Redrose64 🌹 (talk) 00:56, 14 May 2023 (UTC)

@Timeshifter:, I was never involved in a "months" long discussion about <br> or changing that page. Giving my opinions once in an unrelated discussion doesn't involve me in the other discussion. Again, this "br" tangent is irrelevant to this discussion about changing the HTML attribute styling from double-quoted to unquoted on the help pages. Again, if you want to change the sections that describe HTML attributes so single-quoted and unquoted HTML attributes are represented, then have that discussion at WP:MOS where there is a bigger audience. If you can't give any substantial reasons for changing the styling from double-quoted to unquoted on the help pages, then there is nothing more to discuss. Jroberson108 (talk) 01:51, 14 May 2023 (UTC)

I never said you were involved in the months long discussion at Help talk:Line-break handling. Only the much smaller and shorter side discussion on this talk page. And I am not trying to change the sections here on Help:Table. They have been changed for years. As at the line break discussions programmers like yourself are the most insistent on trying to force programmer habits on others here even though wikitext is not HTML.

So you are the one trying to impose a new rule without discussion. Your rule insisting on using quotes. It is almost as bad as the old almost-totally-ignored rule that people had to use <br />. Once there was a comprehensive discussion that rule was thrown out.

The solution is very simple. Tell people they have the choice of using quotes all the time, or that they can choose to forego the quotes if there are no spaces (or the other special characters). In my experience with table editing I am not sure I have ever seen those special characters used in attribute values in tables.

Some examples that can be given in a help section: rowspan=2 and colspan=2 and class=wikitable and style=text-align:left and lang=wikitext and scope=col

There are many variations of the above examples used in the current version of Help:Table:

https://wiki.riteme.site/w/index.php?title=Help:Table&oldid=1153606932

And they have been working fine here for years. Have to go back a few revisions to see the lang=VALUE uses without quotes. Due to Gonnym's recent addition of quotes to them.

--Timeshifter (talk) 14:50, 14 May 2023 (UTC)

Timeshifter, you are, not for the first time, hurling a huge platter of mixed cold cuts at the wall and expecting others to find what they expected when they ordered their lunch.

1. The line-break situation is indeed similar because you stomped your feet loudly to get rid of the unnecessary slash in <br />. Otherwise, it has no relevance here and it doesn't help us find clarity for you to bring it up.

2. Just because something has been in place for years does not make it right or good. In fact, some of these things have been here because you reverted and barked at other users, scaring them away from discussing their value or appropriateness.

3. It's tragically hilarious when you quote MOS:VAR: "Edit-warring over style, or enforcing optional style in a bot-like fashion without prior consensus, is never acceptable" when that is exactly your methodology. You revert repeatedly and say "don't edit war" every time.

4. You said to Jroberson108, you are the one trying to impose a new rule without discussion. Your rule insisting on using quotes. This is a silly claim, as Jroberson108 is discussing it right here, firstly; is not "trying to impose a new rule", secondly, but suggest a standard usage; and thirdly, your use of the word "insisting" is a bit inflammatory when Jroberson108 has merely presented a four-point argument in favor of moving to a with-quotes standardization on this page. At no point has anybody (except you, perhaps) done any insisting or demanding.

5. You say there is no consensus. Okay, if that were actually true, what of it? We're here on a Talk page, discussing, providing arguments, which is the process we use to achieve consensus.

6. And about the supposed lack of consensus: I view any lack of consensus to be what happened after you started removing quotation marks back around May 2021 (or before). I don't know what this little slice of salami is meant to achieve, but it doesn't help the flavor of the discussion here.

Can't you please just stick to the arguments that have been presented by Jroberson108 and others above? I'm sorry if I have gotten too personal but your distraction from the points we're trying to work out has ruffled my feathers. Again. Let's go back to talking about usefulness for the Help page users. — JohnFromPinckney (talk / edits) 15:56, 16 May 2023 (UTC)

Please see my previous replies. --Timeshifter (talk) 12:42, 17 May 2023 (UTC)

The single instance of {{markup}} in this section breaks the indent on the rest of the page. This post should be hard left, but it isn't. --Redrose64 🌹 (talk) 21:54, 29 June 2023 (UTC)

It is hard left for me in Firefox in Win 10 Pro. {{markup}} is found in the <br> section of Help:Line-break handling. I don't remember adding that template. --Timeshifter (talk) 22:19, 29 June 2023 (UTC)

It is not hard left for me, but somewhat indented (as is the Rowspan section which follows), on my Firefox in Win 10 Home. Likewise in Chrome and in Edge, all three whether logged in (MonoBook skin) or not.

And you don't have to remember it; Wikipedia does. You added it here. — JohnFromPinckney (talk / edits) 23:19, 29 June 2023 (UTC)

I should have been clearer. I don't remember adding the template to the <br> section of Help:Line-break handling. I copied that section to here. Are you seeing a problem at Help:Line-break handling?

Try adding {{clear}} after {{markup}} here and see if that helps. If it does, then it might be added to the template. I would do it, but apparently I am not seeing the indentation problem. So I wouldn't notice an improvement. I am using Vector 2022 skin. --Timeshifter (talk) 08:26, 30 June 2023 (UTC)

There is no problem at H:BR, the problem only shows here. The differences are that the portion copied above from H:BR has been enclosed in a table, and that table is single-colon indented. The single-colon indent generates the HTML tags <dl><dd> as you would expect; but the presence of the table and the {{markup}} as well as the indent means that those two tags are unterminated, they persist to the end of the page content. --Redrose64 🌹 (talk) 07:01, 1 July 2023 (UTC)

I was mistaken. I see the indent now. I tried {{clear}} after {{markup}}. It did not help. I tried {{clear}} just after the table. It did not help. Getting rid of the indent on the table fixed the problem. I substituted a div for the table. It would not work if indented. The CSS border would not show up. If not indented, then the bordered div showed up. And there was no indentation problem after it. So I did the simplest solution. I removed the indent on the table.

Removing {{markup}} from the indented table also fixes the problem. --Timeshifter (talk) 09:43, 1 July 2023 (UTC)

Yes, that is what I said in my post of 21:54, 29 June 2023 (UTC). --Redrose64 🌹 (talk) 13:28, 1 July 2023 (UTC)

Bottom border not showing on mobile

Sometimes, the bottom border of a table disappears when viewing on mobile. Can this be fixed? Flower Pot Zip (talk) 06:07, 7 July 2023 (UTC)

Flower Pot Zip. Can you give the URL of a page with such a table? And what browser are you using to view the table on mobile? --Timeshifter (talk) 17:26, 24 July 2023 (UTC)

Empty cells

Tables with empty cells seem to be working fine without adding &nbsp; or &#x200B;. Can anyone give an example where such a character is needed to prevent bad rendering? If not, I would be inclined to remove the advice to add them, to keep markup simple. -- Beland (talk) 17:03, 15 August 2023 (UTC)

Beland. Can you link to the section in question in Help:Table? --Timeshifter (talk) 17:19, 15 August 2023 (UTC)

@Timeshifter: There's one mention in Help:Table#Pipe syntax tutorial and another for nbsp only in Help:Table#Combined use of COLSPAN and ROWSPAN. -- Beland (talk) 17:43, 15 August 2023 (UTC)

Beland. I changed Help:Table#Pipe syntax tutorial. I was able to test it there in preview, and it is no longer needed in most cases.

If all the cells in a row are empty the cells still show up. If the header cell is also empty for that row all the cells show up, but they are narrow. That can be fixed with a simple <br> in one of the cells. That is what is done here:

• Help:Sortable tables#Sorting buttons in a separate row

Help:Table#Combined use of COLSPAN and ROWSPAN. It is such an obscure rare use that I am inclined to leave it in. I need to see an example of what the author of that section is talking about. And if it only occurs with some browsers. That whole section makes my brain hurt. But someone spent a lot of time figuring out that difficult stuff. So maybe it is still true. --Timeshifter (talk) 18:35, 15 August 2023 (UTC)

@Beland: This appers to be a problem back in the IE7 days. Empty cells weren't showing borders, and probably other browsers weren't showing background image/color. Doesn't appear to be a problem in today's browsers. Jroberson108 (talk) 18:46, 15 August 2023 (UTC)

Jroberson108. Thanks for the update, and for removing it from the article. --Timeshifter (talk) 20:21, 15 August 2023 (UTC)

Row moving over one cell. Table bug using Flagg template

Tracked in Phabricator
Task T344562

See:

• Wikipedia:Village pump (technical)#Row moving over one cell. Table bug using Flagg template (and others)
• Template talk:Flagg#Row moving over one cell. Table bug using Flagg template

--Timeshifter (talk) 23:06, 19 August 2023 (UTC)

Tool(s) for working with wikitables

Is there an external tool that can be used to split and move columns, and do similar work. I have a long table at List of Scottish clans that needs the blecherous column for crests and tartan split into two.

But in general, there must be some table-editing tools we should be listing somewhere. I find it hard to believe no one's developed any in all this time.  — SMcCandlish ☏ ¢ 😼  03:36, 26 August 2023 (UTC)

Wikipedia:VisualEditor has this functionality. Documentation is here: Help:VisualEditor#Editing tables. — Goszei (talk) 04:43, 26 August 2023 (UTC)

I don't see a way to quickly split the column for crests and tartan in Help:Table, nor in Help:VisualEditor#Editing tables.

Slow way is to duplicate the column. Then delete from each cell. --Timeshifter (talk) 05:31, 26 August 2023 (UTC)

@SMcCandlish: Doesn't sound like it will be easy with that tool since after adding a new column you will also have to manually move 100s of images to a new column. After some cleanup and fixes (already published), I was able to split them into two columns with some find-and-replaces that use regular expressions. It's not something people can easily learn, so I went ahead and published the changes. If someone objects, then they can just revert that one edit. Jroberson108 (talk) 05:46, 26 August 2023 (UTC)

Schweet. That saves a lot of time and trouble. It's been a long time since I've built regexes for something like that. :-)  — SMcCandlish ☏ ¢ 😼  06:00, 26 August 2023 (UTC)

@SMcCandlish: Ah, someone else who knows regex, nice. Well, you're welcome. Jroberson108 (talk) 06:13, 26 August 2023 (UTC)

Working on some more for cleaning up that article, but I'll take it to user talk since it's not about tables per se.  — SMcCandlish ☏ ¢ 😼  07:01, 26 August 2023 (UTC)

Tables with sticky headers. Discussions

Mostly pinging people participating in, or mentioned, in past sticky table header discussions: Jroberson108. TheDJ. Tol. Newslinger. Sdkb. Graeme Bartlett. Bawolff. GhostInTheMachine. Yair rand. Izno. Jts1882.

See Help:Table#Tables with sticky headers. Discussion can continue here below after the Village Pump discussion is archived. See

• Wikipedia:Village pump (technical)/Archive 208#Vector 2022. Sticky page title covers top 2 lines of sticky table headers.

See archived discussions:

• Wikipedia:Village pump (technical)/Archive 206#Vertical scrollable table with sticky headers.
• Wikipedia:Village pump (technical)/Archive 170#Sticky table headers.
• Wikipedia talk:Reliable sources/Perennial sources/Archive 3#Technical idea: make the header row of the table sticky.
• Help talk:Table#Scrolling tables and sticky headers Help talk:Table/Archive 8#Sticky table headers?.
• meta:Community Wishlist Survey 2021/Reading/Enable sticky table headers.

See Phab:T42763: "Implement repeated/fixed/floating/sticky table headers". Task started in 2012.

It would be nice in my opinion if a template dedicated solely to sticky table headers was created:

{{sticky header}}. With class=sticky-header

As opposed to the multi-tasking template: {{Import style}}. {{Import style|sticky}}

I would be happy with just sticky column headers for now in this new template.

Are there forums just for templates? --Timeshifter (talk) 12:32, 18 September 2023 (UTC)

Mostly pinging people participating in, or mentioned, in past sticky table header discussions: Jroberson108. TheDJ. Tol. Newslinger. Sdkb. Graeme Bartlett. Bawolff. GhostInTheMachine. Yair rand. Izno. Jts1882. Dinoguy1000.

{{sticky header}} is now working for all types of table headers:

{{sticky header}}
{| class="wikitable sortable sticky-header"

For more info see:

Help:Table#Tables with sticky headers

--Timeshifter (talk) 00:30, 5 October 2023 (UTC)

What the template is doing is clever, but for me, that combination of the sticky header and sorting row template on the help page renders differently with Gecko, Blink, and WebKit. With Blink (used by Chrome, Edge, Opera, Samsung Internet, Brave, Vivaldi, Amazon Silk, and UC Browser), I see the horizontal bars vanish when the table scrolls leaving narrow lines that flicker as content scrolls beneath the table (tested on Windows 10 with Edge and Chrome). Good luck working out the kinks! Rjjⁱⁱⁱ (talk) 00:28, 8 October 2023 (UTC)

Rjjiii. I think it is the same without the separate sort row. Could you check?

With sticky template

rowspan and colspan

Name	Data columns are below
	1	2	3
Name1	1-1	2-1	3-1
Name2	1-2	2-2	3-2
Name3	1-3	2-3	3-3
Name4	1-4	2-4	3-4
Name5	1-5	2-5	3-5
Name6	1-6	2-6	3-6

I see the transparent horizontal header lines in Edge, Chrome, and Opera. Windows 10 Pro on a PC. I see no internal header borders in Firefox.

I did not create the CSS code for this sticky template. I copied it from Tol's template, and changed the template and class names to make it more likely to be used by average editors.

The headers are not sticky on cell phones. There are sticky headers that work perfectly on desktop and cell phones. But they are for scrolling tables in boxes. See the advanced scrolling tables with sticky headers linked in the show/hide box here:

• Help:Table#Scrolling and sticky headers

--Timeshifter (talk) 04:14, 8 October 2023 (UTC)

Discussions about Template:Sticky header really should be moved to its talk page instead of this general table talk page. The same goes for most of the info in Help:Table#Tables with sticky headers about what it works with or doesn't, etc. Move it to the template page. Jroberson108 (talk) 06:24, 8 October 2023 (UTC)

It's the same without the sort row. Rjjⁱⁱⁱ (talk) 06:27, 8 October 2023 (UTC)

Rjjiii, Jroberson108, and all. Much has been moved to Template:Sticky header and Template talk:Sticky header. --Timeshifter (talk) 07:59, 8 October 2023 (UTC)

Expanded section issue

Hi Wikipedians. Hope you all are doing well. Can you tell me, How to solve the issue of expanded section in wikipedia articles? Look at this article, in mobile view all the sections are opened and it is hard to view even though I didn't enable Expand all the sections through my settings. Fade258 (talk) 17:21, 8 October 2023 (UTC)

@Fade258: It seems to have been broken with this edit. [1] I would need to look more into it to find out why. Jroberson108 (talk) 18:29, 8 October 2023 (UTC)

Jroberson108, In my opinion, I don't think that this brings that issue on page viewing in mobile because similar to this edit is presents in India at the 2018 Asian Games, Nepal at the 2022 Asian Games etc. Thank you! Fade258 (talk) 03:42, 9 October 2023 (UTC)

@Fade258: Since there is already a discussion open at Talk:India at the 2022 Asian Games#Drop-down Issue, I am responding there. Jroberson108 (talk) 21:14, 8 October 2023 (UTC)

Hi Jroberson108, Thanks for reaching it out. I will respond there. Thank you ! Fade258 (talk) 03:36, 9 October 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)

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)

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)

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)

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:

<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>

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)

(comment: see this for live example, this error's live case has been deactivated July 26, 2024)

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:

<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>

(comment: see this for live example, this error's live case has been deactivated July 26, 2024)

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:

<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>

(comment: see this for live example, this error's live case has been deactivated July 26, 2024)

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 wiki.riteme.site 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)

Previous three fostered content errors discussed have been deactivated. If a live example is needed, see previous page version for live example. Live errors do not need to be kept indefinitely. Zinnober9 (talk) 17:07, 26 July 2024 (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)

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)

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: [2] and [3]. 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://wiki.riteme.site/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)

"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)

Comment for others reading this. See Phabricator tasks:

T302426. ToC test "show all sub-sections" button

T333801. Vector 2022: consider showing closed sections of the TOC by default

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)