This page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.Wikipedia HelpWikipedia:Help ProjectTemplate:Wikipedia Help ProjectHelp
Material from Help:Table was split to Help:Tables and locations on 9 December 2023 from this version. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted so long as the latter page exists. Please leave this template in place to link the article histories and preserve this attribution.
A year ago I started a discussion on whether scope=row should be used for the bottom row or use |-style="background-color:#EAECF0; font-weight:bold; text-align:center" to get the same result. In the meantime, a scrolling table template was created: {{sticky table start}}, which makes the col headers sticky and solves the need for a scoped bottom row as a copy of the top row...on smaller screens, for the most part, and on mobile but NOT for wider screens. In my case (table 1 and table 2), the col headers are not sticky when scrolling vertically, which would then need a copy of the top row in the bottom.
Which leads me to this question: do I/should I use scope=row or only visually mimic bolded/gray color appearance that scope produces using the above wiki markup in the aforementioned tables or leave them as is? Qwerty284651 (talk) 21:52, 13 August 2024 (UTC)[reply]
Something is flaky with that table. The sticky top header row comes and goes as I move my mouse or scroll. I would remove all the unnecessary stuff, one-by-one, to see what is causing it:
Remove style="height:3em" from the header row. This may be causing the problem because sticky templates are tuned to the headers.
Some of the above 4 may be the problem. Some may work together to cause the problem. The top 3 are totally unnecessary. Nowrap is useful for keeping the lines from wrapping. But that means people will be scrolling horizontally more.
Scope=col and scope=row are probably not part of this problem, at least not by themselves. They are unnecessary, though, for simple tables. As this table is.
I usually scope in all table headers regardless of the table's complexity to be on the safe side with accessibility-compliance. I am still wrapping my head around when to use scope and when not. Help:Table#Scope is provided in an example of a simple table, so I assume it should be used everywhere.
Removing scope="row" would cause accessibility issues. In tables, generally speaking, header cells are implicitly column scope unless the scope= attribute is provided. For a header cell at the top of a column of data cells, you can use an explicit scope="col" but don't need to. For header cells at the left of a row of data cells, such as the years in the Table 1 example, scope="row". --Redrose64 🌹 (talk) 18:49, 14 August 2024 (UTC)[reply]
Help:Table#Scope is a generalization, because going into the specifics baffles many new table editors. And because it is based on a very old MOS guideline written in the days of yore before the many improvements of screen readers. Experienced table editors read the actual WCAG, etc. guidelines, and see that on simple tables it serves no purpose. But I don't want to argue about it. Read the links for yourself and decide. It certainly doesn't hurt anything to add more rather than less scopes. --Timeshifter (talk) 21:08, 14 August 2024 (UTC)[reply]
How do you stop rowspans and background colours interacting?
i.e.
Normally this would happen:
How do I make the table so row two's colour is all across row two but I still have a cell that spans from row one into row two while keeping the colour of row one? Mn1548 (talk) 15:13, 4 September 2024 (UTC)[reply]
Well, you don't, as such. You need to provide the search parameters in a supported way. There's a lot there, but taking them one by one...
offset=0
That's the default, you don't need to specify that
limit=50
Is it really necessary to pre-decide on a limit value? That's probably also the default, anyway.
ns12=1
You have the namespaces param already
search=intitle%3Atable
That's searchfilter=intitle:table, to an <inputbox>...</inputbox>. However, the docs seem to imply that it only works with type=search, not type=fulltext, so you may have to switch types.
I don't think you can set up an advanced search with the <inputbox>...</inputbox>, but those params look redundant with the searchfilter args so hopefully it'll work without them.
The ** suffix doesn't really do anything unless you have at least two namespaces specified. Then, it shows checkboxes directly in the form, and ** decides which one(s) is/are pre-checked. So, for example, if I add ,Wikipedia to the definition above...
It may need to wrap if necessary in portrait view in mobile view. Though I notice that the search form shrinks as needed, as I narrow my browser window. So maybe it does not need to wrap. Will look at it in mobile phone.
And is it possible to get it to open the results in a new tab? I have the gadget preference enabled for "Open search results in a new tab or window when holding down the Ctrl key".
I requested the move because I am seeing a sticky header. I don't know why, but I figured someone at Template talk:Sticky header would. And that WikiAlliance09 might want to use the standard sticky header templates. --Timeshifter (talk) 21:07, 7 November 2024 (UTC)Oops. I had the sticky gadget turned on.[reply]
@WikiAlliance09: They are, but background color is behind the text color, so colors can't be too similar so it's readable. Header cells have a background-color set from the "wikitable" class, but not the data cells. Jroberson108 (talk) 17:35, 8 November 2024 (UTC)[reply]
Also, making tables taller is usually preferred over wider due to width constraints on the desktop version (visible on wider tables). The "Time period" row header cell could be moved up above the year and quarter headers and fill that blank space as a column header. After the move, the extra background and border styles can be removed. Jroberson108 (talk) 17:45, 8 November 2024 (UTC)[reply]
2-Cells in one row in one column
Hi I would like to know how to have 2 column cells put under one column. I've been looking through this article but I just can't figure out how.
Example table
Col 1
Col 2
Col 3
Row 1
Text here
Split this into one column | and another column
Row 2
Other text
But this is still one column
Row 3
Some more text
This one too
If you notice in Col 3, Row 1; I would like to split that column for that specific row by that vertical line, but I'm unsure how.
If anyone has a solution, please show me the wikitext and what it produces
Thanks,
Closercamera901 (talk) 00:39, 16 November 2024 (UTC)[reply]
This help page has a lot of useful information, but after years of slow, organic accretion and lack of attention to the overall structure, it has become bloated and somewhat incoherent, with content about related subtopics spread all over the place. I am doing a re-org without rewriting much of anything (except brief portions for clarity), mostly just putting like stuff with like, and renaming existing section headers to better represent what they are really about, and occasionally adding new section headers for better organization clarity.
For example: formerly, we had almost nothing about row operations, except for the brief, desultory section in § Row operations (rev. 1271174926). There was already a fair amount about rows on the page, you just couldn't find it; or if you did, it was not near other stuff about rows, so all very haphazard. Now, section § Row operations has six subsections, almost all of it just by juggling things around. In a couple of cases, subsections were added there by duplicating text already in the (horribly bloated) § Pipe syntax tutorial section, but that redundancy is temporary, and will get de-duped or trimmed after the basic re-org to rationalize the page is mostly completed. Thanks, Mathglot (talk) 23:14, 24 January 2025 (UTC)[reply]
I* should add that currently the subpage is not linked from the Help page. Should it be? I don't see a pressing need for it, but I wouldn't object if someone sees value in linking it. Mathglot (talk) 06:27, 30 January 2025 (UTC)[reply]
Done with re-org for now. Hardly anything new was added, with the exception of a brief intro sentence to a few sections that didn't have one, and one new subsection: § Link directly to a row, which is covered (barely) on some other page, but needs a brief explanation here. The major piece left untackled is the § Colors in tables section, which, like other sections before it, is rather bloated and covers a bunch of different scopes; that is still t.b.d.; also, section § Wikicode syntax tutorial still has a lot of bloat and needs work. But this looks a lot cleaner now, and is easier to navigate to content that was always there before, but buried. Mathglot (talk) 01:39, 25 January 2025 (UTC)[reply]
'Scope' section needs a rewrite
The § Scope subsection of section § Wikicode syntax tutorial probably needs a rewrite. The problems include misleading claims, a mix of row and column explanations, and poorly done examples. For example, this is the first sentence of § Scope:
Column headers are identified by ! scope="col" | instead of |.
Most people think of column headers as the descriptive label sitting in a row above the first data row, and may be highlighted by bold font and shaded background, or other highlight style. By that definition, this first sentence is inaccurate, because column headers can be as simple as this:
{| class=wikitable
|+ Table caption
! Last !! First !! Street
|-
| Doe || John || Main
|}
Table caption
Last
First
Street
Doe
John
Main
which only requires exclamation points, and no scope attributes at all. If we do say anything about scope at all (as opposed to moving it to the Advanced table help, where imho it more properly belongs), then we should not confuse the reader by implying that they need to use it to create column headers, because that is not true, it is much simpler than that.
I think what we need to say, if we keep the section, is something about how scope attributes may be used to define style for all cells in a column, typically one of the width elements, but could be colors, weight, alignment, and so on.
Imho, all the stuff about "colgroup" and "rowgroup" should be left out, possibly replaced with a link to the advanced table page. (It's also probably a good place for a "Tip"—possibly in an explanatory note—that even for hardcore wikitext editors, complex tables is one of the few areas where Visual Editor really shines, and is just plain superior to the wikicode editor. Building complex table arrangements with multiple colspan and rowspans are just way easier in VE, and maybe we could also add a quick how-to showing the wikicode user how to switch from wikicode editing to VE while in the middle of an edit, and back again after they finished adjusting the table.)
I don't have time for any of this just now unfortunately, but I hope to get back to it eventually; or maybe someone will pick this up and run with it. If someone wants to move the whole scope subsection out of this page and into Help:Advanced table formatting (which says nothing about scope !!) with a link from here explaining briefly what it's about, you've got my support. Mathglot (talk) 08:05, 30 January 2025 (UTC)[reply]
The scope section could be moved to either of the advanced pages:
