Help talk:Table/Archive 9

Line breaks

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

Yo, I noticed you changed   to  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  or ) 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 is very common. Anderjef (talk) 16:07, 4 February 2023 (UTC) '' even if  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)
 * . Help:Line-break handling is not a Wikipedia guideline or policy.
 * Please see Help talk:Line-break handling
 * Most people in that thread want  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 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: '' vs
 * See also Wikipedia talk:Line breaks usage and the section titled: '' vs
 * See also Wikipedia talk:Line breaks usage and the section titled: '' vs
 * 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

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

David Göthberg noted in 2008: "Also up until recently all documentation listed  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   or even the  ." --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  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   and disallowing , 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  , 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:
 * is recommended. Using an XHTML tag (ex. ) is acceptable.
 * is recommended. Omitting spaces around the markup (ex. ) is acceptable.
 * is recommended. Omitting spaces around parameters (ex. ) is acceptable.
 * is recommended. Omitting the quotes (ex. ) is acceptable except when there are multiple classes, which requires the use of spaces and quotes.
 * is recommended. Omitting the space, quotes, and semicolon (ex. ) 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: Consider that as our more recent RFC. It got many replies. There is no MOS guideline that says we should be using . I don't think there is any official policy or guideline page that says that.
 * Help talk:Line-break handling

I especially like this example from David Göthberg in 2008: In my opinion anything but the standard Mediawiki method  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. ) 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 , or the template . 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  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. &mdash; Cheers, Steelpillow (Talk) 18:08, 3 April 2023 (UTC)
 * 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.
 * See: Help:Table.
 * 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  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! &mdash; 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. &mdash; 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  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. &mdash; Cheers, Steelpillow (Talk) 04:45, 4 April 2023 (UTC)
 * . 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)
 * 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)
 * . 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 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)


 * 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)
 * Assuming that the portion in question is this
 * {| class="wikitable plainrowheaders" style="text-align:center;"

! scope="col" |Year ! scope="col" style="width:16em;" |Dates ! scope="col" style="width:17em;" |Venue ! scope="col" style="width:8em;" |Country ! scope="col" style="width:46em;" |Description ! scope="col" class="unsortable" |Ref.
 * +List of venue-based achievements, showing year, dates, venue, country and description
 * rowspan="4" |2024
 * February 16–18
 * Melbourne Cricket Ground
 * rowspan="3" | Australia
 * style="text-align: left;" rowspan="2" | Biggest virtual queue in Australian history, with four million customers.
 * rowspan="2" |
 * rowspan="2" | February 23–26
 * rowspan="2" | Accor Stadium
 * style="text-align: left;" | First act in history to schedule four shows on a single tour.
 * March 2–4 and 7–9
 * Singapore National Stadium
 * Singapore
 * style="text-align: left;" |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:
 * {| class="wikitable plainrowheaders" style="text-align:center;"
 * Singapore
 * style="text-align: left;" |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:
 * {| class="wikitable plainrowheaders" style="text-align:center;"
 * 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:
 * {| class="wikitable plainrowheaders" style="text-align:center;"

! scope="col" |Year ! scope="col" style="width:16em;" |Dates ! scope="col" style="width:17em;" |Venue ! scope="col" style="width:8em;" |Country ! scope="col" style="width:20em;" |Description ! scope="col" class="unsortable" |Ref.
 * +List of venue-based achievements, showing year, dates, venue, country and description
 * rowspan="4" |2024
 * February 16–18
 * Melbourne Cricket Ground
 * rowspan="3" | Australia
 * style="text-align: left;" rowspan="2" | Biggest virtual queue in Australian history, with four million customers.
 * rowspan="2" |
 * rowspan="2" | February 23–26
 * rowspan="2" | Accor Stadium
 * style="text-align: left;" | First act in history to schedule four shows on a single tour.
 * March 2–4 and 7–9
 * Singapore National Stadium
 * Singapore
 * style="text-align: left;" |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. -- Red rose64 &#x1f339; (talk) 22:10, 29 June 2023 (UTC)
 * Singapore National Stadium
 * Singapore
 * style="text-align: left;" |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. -- Red rose64 &#x1f339; (talk) 22:10, 29 June 2023 (UTC)
 * }
 * Basically, browsers don't make a row any taller than it needs to be to hold its contents. -- Red rose64 &#x1f339; (talk) 22:10, 29 June 2023 (UTC)


 * Thanks for your help. Shuipzv3 (talk) 00:36, 30 June 2023 (UTC)
 * 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)
 * . 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 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, 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. &mdash; 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 or . I can tell you that it really does not matter. The value of the   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   param of the  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. -- Red rose64 &#x1f339; (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  and   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   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   attribute will always be quoted, e.g.  . As for , 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.   and   both need to be quoted, but   does not. -- Red rose64 &#x1f339; (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, Help:Table, and Help:HTML in wikitext, which all link to the HTML attribute article page for further reading. The help page sections only discuss double-quoted attribute values, 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 . 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. 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
 * https://css-tricks.com/problems-with-unquoted-attributes

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

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.

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. &mdash; JohnFromPinckney (talk / edits) 11:10, 11 May 2023 (UTC)


 * I was . 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 '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 Manual of Style/Tables that also has 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:,  , etc.
 * Help:Table:
 * Help:HTML in wikitext:, 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), 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  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, 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: Jroberson108 (talk) 04:15, 13 May 2023 (UTC)
 * 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 ...


 * 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 "  ". It doesn't enforce one viewpoint.

''' camp after discussion spread to this talk page too. I kind of pushed    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 ''' ''' since that was what you were used to. Redrose64 and I edited the final draft to mutual satisfaction, I believe. My initial insistence that    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.
 * 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). 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    over another. I think you were part of the minority '''
 * 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,  and   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  . -- Red rose64 &#x1f339; (talk) 00:56, 14 May 2023 (UTC)

.''' Once there was a comprehensive discussion that rule was thrown out. . Otherwise, it has no relevance here and it doesn't help us find clarity for you to bring it up.
 * , I was never involved in a "months" long discussion about  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 '''
 * 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://en.wikipedia.org/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
 * 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 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, 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. &mdash; 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 in this section breaks the indent on the rest of the page. This post should be hard left, but it isn't. -- Red rose64 &#x1f339; (talk) 21:54, 29 June 2023 (UTC)
 * It is hard left for me in Firefox in Win 10 Pro. is found in the     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. &mdash; JohnFromPinckney (talk / edits) 23:19, 29 June 2023 (UTC)
 * I should have been clearer. I don't remember adding the template to the    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 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  as you would expect; but the presence of the table and the  as well as the indent means that those two tags are unterminated, they persist to the end of the page content. -- Red rose64 &#x1f339; (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). -- Red rose64 &#x1f339; (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)
 * . 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 &amp;nbsp; or &amp;#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)
 * . Can you link to the section in question in Help:Table? --Timeshifter (talk) 17:19, 15 August 2023 (UTC)
 * There's one mention in Help:Table and another for nbsp only in Help:Table. -- Beland (talk) 17:43, 15 August 2023 (UTC)

. I changed Help:Table. 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  in one of the cells. That is what is done here:
 * Help:Sortable tables

Help:Table. 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)
 * 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)
 * . 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
See: --Timeshifter (talk) 23:06, 19 August 2023 (UTC)
 * Village pump (technical)
 * Template talk:Flagg

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)
 * VisualEditor has this functionality. Documentation is here: Help:VisualEditor. — 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.
 * Slow way is to duplicate the column. Then delete from each cell. --Timeshifter (talk) 05:31, 26 August 2023 (UTC)
 * 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)
 * 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:. . . . . . . . . ..

See Help:Table. Discussion can continue here below after the Village Pump discussion is archived. See
 * Village pump (technical)/Archive 208.

See archived discussions: See T42763: "Implement repeated/fixed/floating/sticky table headers". Task started in 2012.
 * Village pump (technical)/Archive 206.
 * Village pump (technical)/Archive 170.
 * Wikipedia talk:Reliable sources/Perennial sources/Archive 3.
 * Help talk:Table Help talk:Table/Archive 8.
 * Community Wishlist Survey 2021/Reading/Enable sticky table headers.

It would be nice in my opinion if a template dedicated solely to sticky table headers was created:
 *  . With class=sticky-header

As opposed to the multi-tasking template: Import style.

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: . . . . . . . . . . ..
 * sticky header is now working for all types of table headers:
 * For more info see:
 * Help:Table
 * --Timeshifter (talk) 00:30, 5 October 2023 (UTC)
 * --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! Rjjiii  (talk) 00:28, 8 October 2023 (UTC)

. I think it is the same without the separate sort row. Could you check? With sticky template

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: --Timeshifter (talk) 04:14, 8 October 2023 (UTC)
 * Help:Table
 * 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 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. Rjjiii  (talk) 06:27, 8 October 2023 (UTC)

,, 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)
 * It seems to have been broken with this edit. I would need to look more into it to find out why. Jroberson108 (talk) 18:29, 8 October 2023 (UTC)
 * , 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)
 * Since there is already a discussion open at Talk:India at the 2022 Asian Games, I am responding there. Jroberson108 (talk) 21:14, 8 October 2023 (UTC)
 * Hi, 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, 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 (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. —Th e DJ (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. -- Red rose64 &#x1f339; (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: There is also:
 * 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
 * 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)
 * 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. House Blaster 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. House Blaster 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. 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: That help section makes it a lot easier, if people choose to use it.
 * Help:Table. "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.

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: --Timeshifter (talk) 01:16, 9 December 2023 (UTC)
 * User:Timeshifter/Sandbox227.
 * 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. House Blaster 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 Splitting. 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). House Blaster talk 06:09, 9 December 2023 (UTC)
 * I returned those 2 sections. See edit summaries. I also explained things more in Help:Table. 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. House Blaster talk 17:38, 9 December 2023 (UTC)

Information overload is a problem on this page. Read the "Content" section on 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)

. 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: Readable prose size: --Timeshifter (talk) 00:40, 10 December 2023 (UTC)
 * Prosesize
 * Article size - < 6,000 words < 40 kB. "Length alone does not justify division or trimming."
 * 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).

Prevent top table headers from "following" the reader (in visually "pinned" manner) when scrolling down
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)
 * . 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:
 * 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)
 * . 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)
 * 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)
 * 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, , , , and a custom new template or CSS class just for indenting tables. — SMcCandlish ☏ ¢ 😼  03:11, 26 August 2023 (UTC)
 * . Please see Wikipedia talk:Manual of Style/Accessibility. Scroll down to the part about tables on talk pages.
 * Also, see the latest version of Help:Table. 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 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)
 * . Feel free to rewrite/rename Help:Table, but please do not delete the section: Help:Table. 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


 * Help:HTML in wikitext

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

From Help:Table:

From Help:Table:

--Timeshifter (talk) 21:05, 15 August 2023 (UTC) 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. -- Red rose64 &#x1f339; (talk) 22:32, 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 it looks like this:

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:

Rendered result:

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 . -- Red rose64 &#x1f339; (talk) 19:01, 16 August 2023 (UTC)
 * . 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. -- Red rose64 &#x1f339; (talk) 22:01, 16 August 2023 (UTC)
 * . 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)
 * 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 -  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". -- Red rose64 &#x1f339; (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)
 * Why would you think that? The current HTML 5 spec is here, and I see no such deprecation. -- Red rose64 &#x1f339; (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:

,, , , and 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:

Rendered by W3Schools Tryit Editor:

Rendered by MediaWiki:

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: Others find errors. --Timeshifter (talk) 03:36, 18 August 2023 (UTC)
 * http://cerebrumcontorquet.debun.nl/brainwaves/tablecheck/index.php
 * 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>,, 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 tag.
 * The  attribute is obsolete in HTML 5 except for the special value   as described here. The   attribute is entirely obsolete in HTML 5. -- Red rose64 &#x1f339; (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  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 after the, not before the . -- Red rose64 &#x1f339; (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 tag before the  tag, you have made the tfoot element a child of the tbody element, where it is not permitted. -- Red rose64 &#x1f339; (talk) 17:26, 19 August 2023 (UTC)
 * OK. You are right. Thanks. I was thinking of the  tag instead of the  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. -- Red rose64 &#x1f339; (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, , , ; using any of these in a table results in fostered content lint errors and such markup appearing above the table. Unfortunately, that means that this page now has 3 fostered content lint errors that should not be fixed. —Anomalocaris (talk) 07:05, 2 October 2023 (UTC)
 * To respond to the OP, I have to object to the notion that our documentation should contain "this element is deprecated, but still supported by Mediawiki" stuff, as an obvious WP:BEANS problem. We (at least all editors involved in WP:LINT cleanup) already know for a fact that editors who are lazy or have ingrained habits from the 1990s will continue to use deprecated markup that they happen to prefer if they don't think it's going to outright destroy anything, and getting them to stop is very difficult. We have absolutely no reader-facing interest in promoting this behavior, and a very strong editor-/maintenance-facing interest in discouraging it. If someone wants to do a buttload of testing to figure out what deprecated elements and attributes do not cause MW to barf, and to maintain such a list every time MW is upgraded, they can perhaps do that in their own time in their userspace, though honestly a strong WP:MFD argument could be made to delete that as non-pertinent to building en.wikipedia. I.e., if anyone is hell-bent on this idea, they should do it in their userspace at MediaWiki.org or maybe Meta.Wikimedia.org. Creating and maintaing such a list is absolutely outside the scope of en.Wikipedia.org documentation, which exists to record and advise best practices for working on the English-language Wikipedia, so such cruft does not belong in en:Help:Table or any similar page here.  — SMcCandlish ☏ ¢ 😼  04:06, 4 January 2024 (UTC)
 * . 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)