Help talk:Table/Archive 9

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 5

←

Archive 7

Archive 8

Archive 9

Line breaks

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

Yo, I noticed you just changed two   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)

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

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 

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

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

  is recommended. Using an XHTML tag (ex.  ) 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

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.

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 ..., 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   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.T v x1 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.T v x1 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
2024	February 16–18	Melbourne Cricket Ground	Australia	Biggest virtual queue in Australian history, with four million customers.
	February 23–26	Accor Stadium
	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
2024	February 16–18	Melbourne Cricket Ground	Australia	Biggest virtual queue in Australian history, with four million customers.
	February 23–26	Accor Stadium
	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 " ". It doesn't enforce one viewpoint.

 , , , 

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   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 Two Three Four Five Six Seven Eight

Rendered result

One
Two
Three
Four
Five
Six Seven 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   over another. I think you were part of the minority   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.

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   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  . 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://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 . 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   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   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   or . 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 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:

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

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

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)

Name	Data columns are below
Name	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