Help talk:Table

Row split in two

This song reached number 6 on the Easy Listening chart two years in a row, so I put in rowspan=2 for both of those cells. It's only giving me one row that is split in two.

Chart performance for "The Little Drummer Boy" by The Harry Simeone Chorale (1958—2025)

Holiday season	Chart	Peak position
1958	US Billboard Hot 100	13
1959	UK Singles (Official Charts)	13
	US Billboard Hot 100	15
1960		24
1961		22
	US Billboard Easy Listening	6
1962
	US Billboard Hot 100	28

{| class="wikitable" style="text-align:center"
|+ Chart performance for "The Little Drummer Boy" by The Harry Simeone Chorale (1958—2025)
! scope="col"| Holiday<br/>season
! scope="col"| Chart
! scope="col"| Peak<br />position
|-
| style="text-align:center;"|1958
|align="left"|US [[Billboard Hot 100|''Billboard'' Hot 100]]<ref name = WhitburnHSC/>
| style="text-align:center;"|13
|-
| rowspan=2|1959
| style="text-align:left"{{singlechart|UKsinglesbyname|13|artist=Harry Simeone Chorale |artistid=6867}}
|-
| rowspan=3 align="left"|US ''Billboard'' Hot 100<ref name = WhitburnHSC/>
| style="text-align:center;"|15
|-
| style="text-align:center;"|1960
| style="text-align:center;"|24
|-
| rowspan=2 style="text-align:center;"|1961
| style="text-align:center;"|22
|-
| rowspan=2 align="left"|US ''Billboard'' [[Adult Contemporary (chart)|Easy Listening]]<ref name = WhitburnHSC/>
| rowspan=2 style="text-align:center;"|6
|-
| rowspan=2 style="text-align:center;"|1962
|-
|align="left"|US ''Billboard'' Hot 100<ref name = WhitburnHSC/>
| style="text-align:center;"|28
|-
|}

Danaphile (talk) 21:01, 19 January 2026 (UTC)

@Danaphile: Complicated, had to clean it up some first, then flatten it and start over with the spans. Seems to be some issues if the spanning is complex like this one. Removing the span on "6" seems to make it work, otherwise I can't span 1961. At least now 6 matches the above unspanned 13.

Chart performance for "The Little Drummer Boy" by The Harry Simeone Chorale (1958—2025)

Holiday season	Chart	Peak position
1958	US Billboard Hot 100	13
1959	UK Singles (Official Charts)	13
	US Billboard Hot 100	15
1960		24
1961		22
	US Billboard Easy Listening	6
1962		6
	US Billboard Hot 100	28

Jroberson108 (talk) 22:05, 19 January 2026 (UTC)

Thinking more about it, having rowspan of 2 on both "US Billboard Easy Listening" and "6" is the same as 1 row, so that might be the issue. Jroberson108 (talk) 22:13, 19 January 2026 (UTC)

This is another manifestation of this "bug" report from almost a year ago; see in partcular my post of 20:33, 4 February 2025. --Redrose64 🌹 (talk) 22:52, 19 January 2026 (UTC)

Using the original table, added more to 1961 and 1962. That rendering bug seems to be the issue.

Chart performance for "The Little Drummer Boy" by The Harry Simeone Chorale (1958—2025)

Holiday season	Chart	Peak position
1958	US Billboard Hot 100	13
1959	UK Singles (Official Charts)	13
	US Billboard Hot 100	15
1960		24
1961 more		22
	US Billboard Easy Listening	6
1962 more
	US Billboard Hot 100	28

Jroberson108 (talk) 23:12, 19 January 2026 (UTC)

It's not a rendering bug, but expected behaviour, as I described in February 2025. --Redrose64 🌹 (talk) 09:31, 20 January 2026 (UTC)

Interesting, Firefox renders it correctly. Maybe some other engines do to? Layout algorithm differences? Jroberson108 (talk) 23:45, 20 January 2026 (UTC)

References

Exceeding double precision

Note: Moved here from Help talk:Sortable tables (which now redirects here).

Since numerical data sort values are stored in double-precision floating-point format, I had the idea of writing a section about limitations of double precision. In particular, I found that passing a numeric string that parses as +∞ would allow numeric sorting at positive infinity. –LaundryPizza03 (dc̄) 06:13, 20 January 2026 (UTC)

Okay, I have an example now (based on Isotopes of bromine). I don't think we have a section on tables with mixed units yet, and the final draft might use a different subset of the table.

Isotopes of bromine

{| class="wikitable sortable"
|+ Isotopes of bromine
|-
! Isotope
! Half-life 
|-
| <sup>75</sup>Br
| data-sort-value = 5802 | 96.7&nbsp;min <!--Sorted in seconds for compatibility of units-->
|-
| <sup>76</sup>Br
| data-sort-value = 58320 | 16.2&nbsp;h
|-
| <sup>77</sup>Br
| data-sort-value = 205344 | 57.04&nbsp;h
|-
| <sup>78</sup>Br
| data-sort-value = 387 | 6.45&nbsp;min
|-
| <sup>79</sup>Br
| data-sort-value = 1e309 | stable <!--Exceeds upper limit of double precision-->
|-
| <sup>80</sup>Br
| data-sort-value = 1060.8 | 17.68&nbsp;min
|-
| <sup>80m</sup>Br
| data-sort-value = 15913.8 | 4.4205&nbsp;h
|-
| <sup>81</sup>Br
| data-sort-value = 1e309 | stable <!--Exceeds upper limit of double precision-->
|-
| <sup>82</sup>Br
| data-sort-value = 127015.2 | 35.282&nbsp;h
|-
| <sup>83</sup>Br
| data-sort-value = 8546.4 | 2.374&nbsp;h
|}

Isotopes of bromine

Isotope	Half-life
75Br	96.7 min
76Br	16.2 h
77Br	57.04 h
78Br	6.45 min
79Br	stable
80Br	17.68 min
80mBr	4.4205 h
81Br	stable
82Br	35.282 h
83Br	2.374 h

–LaundryPizza03 (dc̄) 06:50, 20 January 2026 (UTC) I propose putting this in #Default data type of a column and creating a new section on data with mixed units:

The wiki software uses double-precision floating-point format, which offers approximately 15 significant digits of precision and can represent numbers ranging in absolute value from approximately 4.9×10⁻³²⁴ to 1.7×10³⁰⁸. While tables with extremely large or extremely small values may not sort correctly, the numerical sort value of +∞ (plus infinity) can be encoded by a number that exceeds the upper limit of double precision.

–LaundryPizza03 (dc̄) 07:12, 20 January 2026 (UTC)

Calling in some help since I don't have the time now: Jroberson108, Redrose64, sapphaline. --Timeshifter (talk) 14:01, 20 January 2026 (UTC)

Help with what? –LaundryPizza03 (dc̄) 15:37, 20 January 2026 (UTC)

LaundryPizza03. I moved this discussion here so that it is more likely to get noticed. --Timeshifter (talk) 11:20, 22 January 2026 (UTC)

How can I link up the archive subpages for the original talk page that got redirected? –LaundryPizza03 (dc̄) 11:31, 22 January 2026 (UTC)

They will eventually be copied to the main talk page archives. This has been done with other talk page archives for table talk pages that are not well watched. That will allow them to be found by the main talk page search engine.

For now they are here:

Help talk:Sortable tables/Archive 5

--Timeshifter (talk) 11:47, 22 January 2026 (UTC)

LaundryPizza03. I (and apparently others) are just not finding the time to help here. It might also have to do with that fact that it is advanced-math related. :) Feel free to add info to Help:Sortable tables. Hopefully someone will correct any errors.

For those who are interested, I moved the sortable table talk archives (Help talk:Sortable tables/Archive 5, etc.) to Help talk:Table archives. Archives 11 through 14 here are strictly sortable table archives. Archive 15 begins with the last of those talk threads, and then finishes with the latest Help talk:Table threads that have been archived. --Timeshifter (talk) 21:12, 2 February 2026 (UTC)

I just added this to the page. I have also added a subsection about sorting dimensional quantities. –LaundryPizza03 (dc̄) 22:10, 2 February 2026 (UTC)

Dark Mode issue: Tables with "style=background: none" are difficult to read.

When viewing tables with the background set to transparent/none, the text is made a dark grey (#202122) on a black background, making it difficult to read. This can be seen on the Help page under the "Non-rectangular tables" section in "Workarounds":

Help:Table#Non-rectangular tables

Notably, this behavior is different depending on if the background is set to "transparent" or "none": transparent has links be in their usual blue/purple colors, while none has links also be set to that gray color.

I'm sorry if this isn't the right place to report this; There were many places that seemed like they could be viable candidates. Dinjoralo (talk) 14:11, 20 March 2026 (UTC)

@Dinjoralo: See: Help:Advanced table features#Avoid background:none or transparent.

There are multiple sections on color starting here:

Help:Advanced table features#Colors in tables.

--Timeshifter (talk) 17:34, 20 March 2026

@Dinjoralo: I see the problem in dark mode. I removed that section from the help page until someone can fix it. I don't have the time right now. Here it is:

Cell borders can be hidden by adding border: none; background: none; to the style attributes of either the table or the cell, though this may not work in older browsers. Another use case for this is for implementing aligned multi-column tables: Wikitext {| class=wikitable style="border: none; background: none;" ! colspan=2 rowspan=2 style="border: none; background: none;" | [[File:Pfeil_SO.svg |none|link=|20px]] ! colspan=3 | To |- ! Solid !! Liquid !! Gas |- ! rowspan=3 | From ! Solid | Solid–solid transformation || Melting || Sublimation |- ! Liquid | Freezing || {{sdash}} || Boiling/evaporation |- ! Gas | Deposition || Condensation || {{sdash}} |} Produces To Solid Liquid Gas From Solid Solid–solid transformation Melting Sublimation Liquid Freezing — Boiling/evaporation Gas Deposition Condensation — The removal of the link on an image is dependent on it being purely decorative (as it will be ignored by assistive devices). Wikitext {| class=wikitable style="border: none; background: none;" ! scope=col | Year ! scope=col | Size | rowspan=5 style="border: none; background: none;"| ! scope=col | Year ! scope=col | Size | rowspan=5 style="border: none; background: none;"| ! scope=col | Year ! scope=col | Size |- | 1990 || 1000<br>(est) || 2000 || 1357 || 2010 || 1776 |- | 1991 || 1010 || 2001 || 1471 || 2011 || 1888 |- | colspan=2 style="text-align: center;"|⋮ | colspan=2 style="text-align: center;"|⋮ | colspan=2 style="text-align: center;"|⋮ |- | 1999 || 1234 || 2009 || 1616 || 2019 || 1997<br>(est) |} Produces Year Size Year Size Year Size 1990 1000 (est) 2000 1357 2010 1776 1991 1010 2001 1471 2011 1888 ⋮ ⋮ ⋮ 1999 1234 2009 1616 2019 1997 (est)

--Timeshifter (talk) 16:28, 21 March 2026 (UTC)

Understood. I saw a table like this in an article, and didn't know if the original had a specific reason for using those styles. I'll go ahead and edit that article to remove the background color from the table. Dinjoralo (talk) 16:55, 25 March 2026 (UTC)

Potential glitch

For a while now, I’ve had an issue where I can’t select a large range of cells that requires scrolling down without the page forcing me to scroll back up. For example, at Foreign relations of Palau, if I try to select all the countries under the “Country” column in the table, I would normally click on “Australia,” hold the button, and scroll down to “Trinidad and Tobago.” However, I’m no longer able to do this because the page keeps scrolling back up. Is anyone else experiencing this? Semsûrî (talk) 09:10, 30 March 2026 (UTC)

I've never done that. But if I want to copy a column I go into the visual editor. Then I click on the top cell of what I want to copy. Then shift-click on the bottom cell of what I want to copy. Then ctrl-c to copy the selected cells. --Timeshifter (talk) 14:10, 30 March 2026 (UTC)

I did not know of that trick. Thank you. Semsûrî (talk) 15:19, 30 March 2026 (UTC)

@Semsûrî: You're welcome. See also: Help:Creating tables#Insert blank row/column and the following sections on moving, deleting, and copying columns. And: Help:Table#Column operations. --Timeshifter (talk) 15:32, 30 March 2026 (UTC)

Help. Collapsible tables

Note: Catcus_DeMeowwy. Discussion has been moved here from Help talk:Collapsing tables and more. See: Help:Collapsing tables and more.

Hi folks. Not expecting much because I get that people are busy. I am confused with the template: is it possible to format a table so that rows after a certain point are hidden until you click [show], basically a wikitable mw-collapsible innercollapse class inside of the table, so that the section below is hidden? My attempts all broke the table. Table WIP is at User:Catcus_DeMeowwy/Chinese_herbology#Usage_of_some_Chinese_herbs for reference.

Other talk topics asking the same have no replies/solution. I have left other attemps (template:hidden_begin) in tact to show my working. Catcus DeMeowwy (talk) 11:49, 1 May 2026 (UTC)

Bumping topic at 21:24, 3 May 2026 (UTC) ~ ~Catcus DeMeowwy (talk)

~ ~Catcus DeMeowwy (talk) 21:24, 3 May 2026 (UTC)

@Catcus DeMeowwy: See Help:Collapsing tables and more#Collapsible tables. The class is added to the table, not a row. Trying to add markup around specific rows is going to break the table markup. Jroberson108 (talk) 05:00, 4 May 2026 (UTC)

Need numbers with ~ in front to sort correctly

Need option for ~ which is often used in front of numbers in tables. For example in this table:

• Casualties of the Gaza war#Civilian to combatant ratio

See Template talk:Circa/doc/sortable and:

• Help:Sortable tables#c. for circa

Need a version of this template for when ~ is used in front of numbers in tables.

Or better yet the mediawiki software needs to ignore ~ if data-sort-type=number is used in the column head.

See Help:Sortable tables#Forcing a column to have a particular data type. --Timeshifter (talk) 18:56, 5 May 2026 (UTC)

@Timeshifter: On that cell, set data-sort-value="" to the same numeric value excluding the tilde. Jroberson108 (talk) 05:42, 6 May 2026 (UTC)

@Jroberson108: Thanks. I created this section:

Help:Sortable tables#~ for approximately --Timeshifter (talk) 21:49, 6 May 2026 (UTC)

Making two table the same layout?

@Noleander In Special:Permalink/1353013986#Water sources and sinks, there's two tables that ideally should be rendered with the same width columns without resorting to ugly hacks like fixed pixel widths (which I'm not willing to sink to). The biggest variation is in the first column, with the longest cell being 9 Mouth of Atbarah River in the second table. Is there some way to say (in both tables) Make this column the correct width to contain "9 Mouth of Atbarah River"? That should get both of them layed out the same while still allowing the formatting to adapt to whatever local fonts and screen-size are in use. RoySmith (talk) 17:18, 7 May 2026 (UTC)

Or, more generally, is there some way to say "Make these two tables have the same width columns, whatever that turns out to be at render time?" RoySmith (talk) 17:20, 7 May 2026 (UTC)

I'm not enough of a table-smith to know how to accomplish that. I'm sure the table rendering software dynamically sets column widths based on a variety of factors. Forcing table columns to a specific width (even if it is only "match that other table") may run contrary to the spirit of "rely on the table rendering software to set the column widths." But maybe some table guru knows a way. Noleander (talk) 17:58, 7 May 2026 (UTC)

I don't know why one would want the 2 tables to have the exact same column widths.

And why are you linking to an old version of the page? When I look at the latest version (Nile#Water sources and sinks) the 2 tables are fairly similar in column widths. Except for the first column on the left.

You could force the width in various ways. See

• Help:Width of tables, columns, and cells

--Timeshifter (talk) 21:33, 7 May 2026 (UTC)

I want them to have the same widths because the two table display the same type of information and I want to make it easy for a reader to visually follow a column from one to the other. RoySmith (talk) 21:41, 7 May 2026 (UTC)

OK, though I don't think it is that hard to follow down. Dig around that help page I linked to. --Timeshifter (talk) 22:02, 7 May 2026 (UTC)

Hello, RoySmith. Your desire to have at least the left-most columns of similar, vertically stacked tables is a worthy one. I know of many music-related articles which take care to do this. See, for example, the Year-end charts tables for Rihanna's Rated R album. The upper table (2009 year-end chart performance for Rated R) uses the same width as the lower table (2010 year-end chart performance for Rated R). It does this (I may have done it myself, years ago, but I don't care to check) by previewing the similar tables, and determining the widest natural cell in the first column. By trying style="width:24em;", style="width:18em;", style="width:19em;", etc., you can find the smallest width that comfortably holds the content. Then you can add that constraint to all the matching columns of parallel tables.

We made similar suggestions when trying to work out a manual of style for discographies; see these examples. Or (more Rihanna again) Rihanna albums discography, Rihanna singles discography, and Eminem singles discography, etc. We constrained the left-most column or two artificially, but the Year column (on singles tables) is automatically always the same width, and after that the number of columns can vary, but the reader isn't struggling to parse the rows so much. See?

Also check out the code for the individual chart columns, e.g., style="width:2.8em;font-size:90%;". Here, it's extremely useful to have the columns all the same size, even though some headings like "SWI" need more space than others, like "US". Just use a uniform width (in ems, of course) that suits the page.

You don't have to (and IMHO shouldn't) try to constrain all of the columns, nor the table width, because it's okay for the right-most column(s) to be a bit "ragged". The human eye is happy to match the orderly-looking items at the left, and figure out the variable details to the right. The user agent (browser) is doing the rendering for you; let it. And you mentioned ugly hacks like fixed pixel widths which is, I agree, a Bad Thing^TM. But by using em units, you flexibly constrain the table (a bit) depending on the font size. If you use px units, you don't know what the reader will see, because you can't know their standard font size or zoom rate, etc.

I hope this helps, even months after your query. — JohnFromPinckney (talk / edits) 14:23, 15 October 2026 (UTC)

@JohnFromPinckney Thanks for the reply. That got me thinking on this some more and I came to the realization that I might be able to do exactly what I want by adding an invisible data row which contains the longest string in that column of either table. I asked Claude and he came up with essentially the same idea :-) I'm not sure how to implement that concept in wiki markup, but I've been playing around in my sandbox.

Technically, what I want is "the string that renders the widest". Depending on the end-user's fonts, may not be "the string with the most characters", but that should be a reasonable approximation and at worst I could include multiple invisible rows with the various candidates for "widest". RoySmith (talk) 15:10, 15 October 2026 (UTC)

No, I hope I didn't imply that you should look for the cell with the most characters. I meant to use the one that takes up the most space when rendered.

And I would like to counsel against adding extra invisible rows (and I wouldn't know how to do that either). To what end? What HTML do you hope to end up with, and what will screen readers and other user agents do with that result? Why not just use the single style constraint as I suggested? Try adding ! scope="col" style="width:11em"| to the first column of both tables, and see what you think.

I have taken the liberty of mucking around in your sandbox (I hope you don't mind), but I have immediately reverted my changes. See what you think of this version. By the way, I don't know why you are starting your tables at font-size: 85%; but that's really the lower limit of readability (cf. MOS:SMALL) and makes your superscripts and footnotes even smaller. And the caption(s) should be simple; it might be better all around to move the legend to a spot after the table(s). Those centered bullet items look a little funny.

Finally, I don't see why you have two tables; they look identical, just with different data rows (for whatever reason). The difference between the tables should be reflected in the captions. Of course, maybe this is just a dummy example you worked up by splitting an existing, larger table. Yes? If so, carry on. :-)

Please take a look, and accept my apologies if I have barged in unwantedly. Hoping this helps, — JohnFromPinckney (talk / edits) 15:56, 15 October 2026 (UTC)

Playing in my sandbox is perfectly fine. As for the font size 85%, I just grabbed the existing markup from Nile as a starting point for my exploration. RoySmith (talk) 16:11, 15 October 2026 (UTC)

The only reason I have the two different tables in the sandbox was just to play around with. I've lost track of the original revision that prompted me to ask about this during WP:FAC, so I just took the one table that currently exists and split it up into two, one with longer entries, the other with shorter ones, just to give me something to experiment on. At this point, it's really become an academic exercise in trying to figure out how to make this work. Your point about my idea not playing well with screen readers is completely valid. RoySmith (talk) 16:14, 15 October 2026 (UTC)

@JohnFromPinckney and RoySmith: If the goal is to match the column widths on multiple table stacked vertically, then I would agree with JohnFromPinckney's approach. Find the widest width for each column and apply the style to each respective column. Consider removing the nowrap class and <br> use in headers, and use ! scope="col" style="max-width:11em"| instead so it can wrap naturally on smaller devices where you usually can't see multiple tables at the same time. Also, for sortable tables, consider using {{sort under}} to move those sort buttons under the header text to narrow those columns some, especially the numeric ones, since it looks like all the headers have more text than their data cells. Jroberson108 (talk) 17:10, 15 October 2026 (UTC)

The link to {{sort under}} was purple, so I must have seen it before, and then forgotten. It's too bad, too, because that's a handy little template. Thanks, Jroberson108, for the reminder (and the work implementing it). — JohnFromPinckney (talk / edits) 20:53, 15 October 2026 (UTC)

Thinking about it, maybe max-width won't work if one column is normally narrower than another that has wider data cell text. It would have to be width, unless the headers remain uniform and the widest part. Jroberson108 (talk) 17:25, 15 October 2026 (UTC)

See also: Help:Advanced table features#Side-by-side columns of tables, images, lists and the related sections before and after it. You could place divs around the 2 tables, and then mark each div with a maximum width using the units of your choice.

<div style="display:inline-table; max-width:Xem;">
-- first table --
</div>
<div style="display:inline-table; max-width:Xem;">
-- second table --
</div>

This has the added advantage that if the screen is wide enough, the tables will go side-by-side.

Or you could put both tables in the same div and keep them in the same column. You could try adding more columns too. Another column will be below the first column unless the page is wide enough to allow 2 side-by-side columns. --Timeshifter (talk) 20:06, 15 October 2026 (UTC)

Obsolete attributes

8rz, at Help:Table#Cell content indenting and padding, why are we encouraging the use of cellpadding= and cellspacing=? These have been obsolete since HTML 5 (2014). --Redrose64 🌹 (talk) 14:06, 23 September 2026 (UTC)

I am aware of their obsoleteness. Having been editing on Wiki for years, I found about the difference between spacing and padding yesterday, so I added their definition to help future editors distinguish between the two.

One example I've come across is in {{tennis bar}} which uses cellpadding=0; cellspacing=0 in its code. Replacing cellpading with style=padding:0 (example) fixes 1/2 of the deprecated code, but because there is no replacement for cellspacing= (as listed in Wikipedia:HTML5#Table attributes), it leaves whitespace between the cell (276) and the text (Sampras) after it.

Pinging @Timeshifter: who have done the most editing on table-related help pages recently to chime in. 8rz (talk) 15:02, 23 September 2026 (UTC)

I noticed a couple uses of this phrase, or a variation: "Allowed, obsolete but rarely used" on Wikipedia:HTML5#Table attributes. I also notice multiple breakdowns at Wikipedia:HTML5#Scope of what HTML 5 alone has difficulty with.

For Help:Table, other table help pages, I suggest explaining what HTML 5 will do, and then why deprecated stuff may be better at times. --Timeshifter (talk) 16:41, 23 September 2026 (UTC)

@8rz: In cellpadding=0; cellspacing=0 the semicolon is invalid - if a tag has two or more attributes, they are delimited with whitespace, nothing else.

style=padding:0 is also invalid; any attribute value that contains a colon must be quoted, as in style="padding:0"

The replacement for cellspacing=0 is style="border-spacing:0" but that should not be necessary, since zero is the initial value. More at the CSS 2.1 spec, section 17.6 Borders. --Redrose64 🌹 (talk) 22:18, 23 September 2026 (UTC)

Fixed the aforementioned template. Many outdated "tables" use the above attributes. They would need to be changed as they are encountered. 8rz (talk) 23:49, 23 September 2026 (UTC)

@Redrose64: In wikitext style=padding:0 works fine without the semicolon or the double quotes. If you add more styles, then the semicolon is needed to separate them: style=padding:0;margin:2px, but the double quotes are not necessary unless there is a space: style="padding:0; margin:2px". Also, when the parser hits the closing quotation mark, it knows the style declaration has ended, even without a trailing semicolon. And units are not needed for the zero in style=padding:0 since zero is zero regardless of unit. --Timeshifter (talk) 04:30, 24 September 2026 (UTC)

Please read what I wrote. My only mention of a semicolon was its non-validity between two attributes - of course they're required between declarations. I never said they were required after the last declaration, either. I also never said anything at all about units. --Redrose64 🌹 (talk) 18:33, 24 September 2026 (UTC)

I was just providing additional info for all. My main point was that style=padding:0 is not invalid. Also, style=border-spacing:0 is valid without the double quotes. Because wikitext has its own rules, and does not follow all HTML or CSS rules. --Timeshifter (talk) 20:29, 24 September 2026 (UTC)

I was just providing additional info for all You replied to me, specifically. --Redrose64 🌹 (talk) 17:02, 25 September 2026 (UTC)

Accessibility standards for tables

Hi all! Does Wikipedia follow (or strive to follow) WCAG guidelines?

WCAG 2.0 AA guidelines suggest avoiding merged cells in tables, however they are all over the place. Just curious if we are 1) aiming to follow said guidelines, or 2) using the correct markup to make these tables accessible. With a mission of accessible information for all, it seems like that would align with Wikipedia values. Ads Augs (talk) 22:07, 10 October 2026 (UTC)

@Ads Augs: Can you link to the specific guideline? And please link to an example table with the problem. --Timeshifter (talk) 01:19, 11 October 2026 (UTC)

Merge Help:Table and Help:Basic table markup

There is a lot of duplicate info on Help:Basic table markup and Help:Table. Seems like a lot of this was done during the last cleanup and restructuring of Help:Table a few years ago? The former seems less developed, so I would suggest gutting any remaining useful parts or better instructional methods, then deleting that page.

Table wikitext syntax explanation is repeated in:

• Help:Basic table markup#Introduction (main description) / Help:Basic table markup#Using double marks with tables.
• Help:Table#Wikitext markup. More flushed out.

Table wikitext syntax example is repeated in:

• Help:Basic table markup#Example table.
• Help:Table#Wikicode syntax tutorial (table/caption/rows/cells sub-sections).

The latter, I feel, is overly basic being divided into steps, and takes up too much vertical space due to the repeat wikitext examples. The former's approach seems better with a single wikitext/render example followed by its prose dissection. Help:Basic table markup#Cell contents on new lines info is also repeated, though its approach is not as concise as Help:Table#Wikitext markup and Help:Table#Adding cells.

HTML attribute syntax explanation is repeated in:

• Help:Basic table markup#HTML attributes (main description) / Help:Basic table markup#Common attributes.
• Help:Table#HTML attributes. More flushed out.

HTML attribute syntax example is repeated in:

• Help:Basic table markup#HTML attributes ("Adding ..." sub-sections).
• Help:Table#Adding attributes.

The latter, I feel, reads better with its concise info and prose dissection of the wikitext/render example as opposed to the former's "sectioned" approach that takes up too much vertical space just to explain syntax.

Table wikitext versus HTML is repeated in:

• Help:Basic table markup#How tables are formed
• Help:Advanced table features#Other table syntax

Repeated in different formats, where I feel the former is easier to read with its prose dissection of the wikitext/HTML/render example that maintains the table structure. Although MOS discourages HTML tables because wikitables are easier to customize and maintain, they exist on:

• 15,053 user pages
• 4,425 "Wikipedia" pages
• 1,120 template pages
• 559 other (non MOS/Help/Talk) pages (some may be HTML explanations)

Thoughts and opinions on the merge? Jroberson108 (talk) 17:31, 16 October 2026 (UTC)

@Jroberson108: Whatever you want to do is fine. Getting rid of duplicate or bad info is a good idea. --Timeshifter (talk) 18:10, 16 October 2026 (UTC)