MarioWiki:Table style guide

This page is about the wiki policy on how to format tables in mainspace pages. For a full technical guide on table syntax, see Help:Table.

Tables are an integral part of many pages, used for listing groups of elements in a concise manner. The Super Mario Wiki has a preferred format for how tables should be structured, both for the readers viewing them, and for the users writing them. The goal when writing a table is to make sure it is both fully-functional for the reader's needs, and that the syntax written to create it is clean and concise for editors that need to modify their contents.

For a style guide on how to write body text, refer to the Manual of Style. Do not use generative AI to create tables, as it results in messy, sub-optimal syntax for other editors to comb through.

Creating a table

The following section explains how to create a table fitting the specifications showcased in the example listed below. Most tables will not be as complex as the example below, which is written to showcase as many edge-cases that you can be expected to face as possible.

Example

This table, while largely a hybrid of other elements from the pages for Super Mario Bros., Super Mario Bros. Special, and Super Mario 64, contains fully-cohesive syntax for a table, containing plenty of edge-cases and syntax dedicated to handling them. Below it is a collapsible, containing the table's full syntax.

Character	Description	Debut Year
Mario	Mario serves as the main protagonist of the game. Luigi, Mario's brother, appears only as the second player and plays identically to Mario. While Luigi is differentiated by his colors, both Fiery Mario and Fiery Luigi have the same palette.	1981
Luigi		1983
Bowser	The villain, he appears in every castle level (those ending in -4). In Worlds 1-5 he only breathes fire, in Worlds 6 and 7 he only throws hammers, and in World 8 he does both. He can be hitting him with five fireballs, a hammer, or by breaking the bridge with the axe. None of the Bowsers are fake Bowsers; in each world, when defeated with fireballs, Bowser simply disappears.	1985
MIPS	Princess Peach's pet rabbit. He is found in the castle's basement and flees if approached. He gives Mario a Power Star if caught. While captured, MIPS claims to be late for tea.	1996
Bob-omb Buddies	Friendly Bob-ombs that lack fuses. They reside on the Bob-omb Battlefield, where they are at war with the Big Bob-omb and his army. A Bob-omb Buddy is hidden away in nearly all subsequent courses. If spoken to, it prepares a cannon for Mario to use. The cannon remains open and accessible for all subsequent revisits.	1996

{|class="wikitable mario sm col2left sortable" style="text-align:center;--bg1:#fff;--darkbg1:#000" width=100%
|-
!width=100px|Character
!class=unsortable|Description
!width=10%|Debut Year
|-
|data-sort-value=Ma|[[File:SMB Super Mario Sprite.png|32px]]<br>[[Mario]]
|rowspan=2|Mario serves as the main protagonist of the game. Luigi, Mario's brother, appears only as the second player and plays identically to Mario. While Luigi is differentiated by his colors, both [[Fire Mario|Fiery Mario]] and Fiery Luigi have the same palette. 
|1981
|-
|data-sort-value=L style="background:#ccc"|[[File:SMB Super Luigi Sprite.png|32px]]<br>[[Luigi]]
|style="text-align:center"|1983
|-
|data-sort-value=Bow style="background:#000"|[[File:SMBS-Bowser-SharpX1.png|64px]]<br>{{color link|cyan|Bowser}}
|The villain, he appears in every castle level (those ending in -4). In Worlds 1-5 he only breathes fire, in Worlds 6 and 7 he only throws hammers, and in World 8 he does both. He can be  hitting him with five fireballs, a hammer, or by breaking the bridge with the [[axe]]. None of the Bowsers are [[Impostor Bowser|fake Bowser]]s; in each world, when defeated with fireballs, Bowser simply disappears.
|1985
|-
|data-sort-value=Mi|[[File:SM64 Asset Model MIPS.png|x100px]]<br>[[MIPS]]
|Princess Peach's pet [[rabbit]]. He is found in the castle's basement and flees if approached. He gives Mario a Power Star if caught. While captured, MIPS claims to be late for tea.
|1996
|-style="background:#FDD;--darkbg:#300"
|data-sort-value=Bom|[[File:Bob-OmbBuddySM64.png|100x100px]]<br>[[Bob-omb Buddy|Bob-omb Buddies]]
|Friendly [[Bob-omb]]s that lack fuses. They reside on the [[Bob-omb Battlefield]], where they are at war with the [[King Bob-omb|Big Bob-omb]] and his army. A Bob-omb Buddy is hidden away in nearly all subsequent courses. If spoken to, it prepares a [[cannon]] for Mario to use. The cannon remains open and accessible for all subsequent revisits.
|1996
|}

Classes and styles

Tables are formatted internally using two important parameters; classes and styles. Classes are individual parts of the wiki's own CSS, whereas styles are individual CSS properties. Everything, from individual cells to the whole table, operates under classes and styles.

X classes/properties

One set of classes and styles, made for use when initializing a table, are designed to affect specific columns of a table. These are referred to as the X classes, as each of them contain an X that is replaced with the desired column's number. Each of these classes should be used whenever possible, as each of them aids in the readability of the table's code. In many cases, a table's entire style can be handled with clever use of the X classes/properties. A full list of relevant X classes and properties can be found below, though the most common ones are as follows.

• class="colXleft" & class="colXcenter": Classes which align the text in a given column to either left-aligned or center-aligned. For example, to left-align the text in column 2, one would use class="col2left".
• style="--bgX:COLOR" & style="--darkbgX;COLOR": Style properties which colorize the cells in a given column. style="--bgX" impacts exclusively light mode, whereas style="--darkbgX" impacts exclusively dark mode. For example, to give the column 1 a white color on light mode, one would use either style="--bg1:#FFF" or style="--bg1:white".

Take, for example, this table from World 1-4 (Super Mario Bros. Special) § Items, which is styled entirely using X classes and properties:

Sprite	Item	Count	Notes
	Coin	33	All in open air in the secret area.
	Magic Mushroom/Fire Flower	2	1 in a ? Blocks, 1 in a Hidden Block.

{|class="wikitable col4left" style="text-align:center;--bg1:#000;--darkbg1:#000"
!Sprite
!Item
!Count
!Notes
|-
|[[File:SMBSpecial-Coin.png]]
|[[Coin]]
|33
|All in open air in the secret area.
|-
|[[File:SMBSpecial-SuperMushroom-SharpX1.png]][[File:SMBSpecial-FireFlower-SharpX1.png]]
|[[Super Mushroom|Magic Mushroom]]/[[Fire Flower]]
|2
|1 in a [[? Block]]s, 1 in a [[Hidden Block]].
|}

Structure

As specified in Help:Table § Usage, tables can be formatted internally in two separate ways. In one method, every row is on one line of text, initiated with either a ! for a header or a | for an ordinary cell, and are separated by sets of either  !! for headers and  || for ordinary cells, both with spaces between the pairs. In the latter method, every cell is listed on their own line, with a single leading ! for headers and | for ordinary cells. The former method is what is generated if using the editor's toolbar to generate a table by navigating to Advanced > Insert Table > Insert.

• The former method is best suited for when the table is lightweight, or can be easily adjusted with parameters such as the X classes/properties (see their section), or otherwise do not require any additional formatting beyond what is specified in the table's header. Tables such as track lists like on Donkey Kong Goes Home § Tracklist are most suited for these same-row approaches.
• If a table requires any more precision, such as with cell-specific formatting, it should instead be written with the latter method, with each cell being given its own row on the table. This is the format you will most frequently encounter on the wiki, being used on Game pages, most List pages, and most subject pages, as while it is larger in terms of line count, it is far easier to read the information associated with individual cells.

Tables should, whenever possible, be on a per-row basis, written such that the headers are on the top. While some tables will naturally require a column of headers, such as when the information is a grid of two elements like the one used on Badge § Mario & Luigi: Dream Team, this will usually not always be the case. Regardless of the contents, however, when writing a table, the left-most column (the first one written) should be given to the field that identifies the rest of the row. For instance, a character table would have the first column be for the character's name. For instance, in the sample table, the first column is the one given to characters.

Table initialization

At the start of a table, when {| is used to initialize it, three things may follow it on the same line. These three items should appear, as necessary, in the order of top to bottom:

1. class, which specifies the on-site classes the table will use. Tables should, at minimum, contain class="wikitable". If a table contains multiple classes, they must be separated with a space.
2. style, which specifies more general CSS properties. If a table contains multiple styles, they must be separated with a semicolon.
3. width, which serves as an alternative method to specify a table's width without using the width style parameter. In most cases, the width style parameter should be used instead, however, using width as a separate parameter is occasionally used for code readability. There is never a scenario in which you need to specify multiple widths.

A table should, at minimum, begin with {|class=wikitable if it does not need a specified style nor a specified width. If multiple CSS classes or style properties are being used on the table, the classes and properties must be enclosed in a pair of " quotation marks. Each of these fields should be separated by a space, though the elements within may be spaced according to their specifications. Note that if a width is not specified, the table will attempt to size itself automatically. As a result, width does not need to be specified, though it may still be specified manually as necessary.

Take, for example, the following excerpt from the sample table, ignoring the specifics of what each of the classes and style properties mean:

{|class="wikitable mario sm col2left sortable" style="text-align:center;--bg1:#fff;--darkbg1:#000" width=100%

• Class is listed first, with the classes enclosed in quotation marks and separated by spaces.
• Style is listed second, with the properties enclosed in quotation marks and separated by semicolons.
• Width is listed third, and does not require quotation marks, nor has any additional parameters to separate.

Significant classes

For a full list of classes, refer to Help:Table § Standard table. For classes specific to individual cells, refer to the "Row and cell values" section below. The preferred order of which is listed below.

1. wikitable: The baseline for every table. All standard tables should have this class.
2. Series coloration: A pair of classes that are used on Game pages, based on the game's series, in order to colorize the table. A list of every series coloration can be found at Help:Table § Color chart. In the example provided earlier, the colors specified are mario sm, correlating to the Super Mario series in the Super Mario franchise. Series coloration may be used on subpages for a specific game's tables by the editor's discretion (such as Recording or List of Mario Party DS collectibles), though it should not be used for tables on pages for subjects that span multiple series (such as Fire Flower or Shy Guy). Reception and Award tables should never be given series coloration classes. As of present, series coloration does not apply to alternative (non-video game) media.
3. alt: Specified immediately after the series coloration, this can be used to give cells an alternating color, as specified by the color chart. By default, Tables lack alternating colors, those tables that are long and dense with text or elements should be given the alt parameter if possible. Tables which either do not use series coloration, or make use of rowspan within the table, should not be given the alt parameter, as the rowspan feature breaks the alternating colors.
4. colXleft and colXcenter Aligns every element on a given column to either be left-aligned, or center-aligned. X stands in for the number of column. Descriptions should be left-aligned whenever possible. Be wary if the table contains colspan, as the table may end up adjusting the column after the one specified under select conditions, requiring specifying the alignment in the cell's own parameters. For more information, refer to the "X classes/properties" section.
5. sortable: Allows the table to be sorted on a by-column basis. Tables should be made sortable if they are long, or feature many elements that would benefit from being organized alphabetically or numerically. Do not use the sortable class on tables with multiple rows of headers, or separating subheaders, as it breaks under those conditions. In addition, note that if a table has rowspan cells, it will split the cells for the sake of sorting it.
6. sticky-header: When scrolling down, the first row "sticks" to the top of the page and follows the reader's display. Should be used when a table is particularly lengthy height-wise, or is dense with many sortable values. Do not use if the header row utilizes rowspan, as it will not be able to stick the whole header.
7. scrollable: Allows the table to be scrolled horizontally if it does not otherwise fit the display. Should be used only when necessary, such as if there are too many images such that it would not fit on a 720p display (at 1280 pixel width) on a desktop computer.

Significant styles

There are many distinct CSS properties, with a full list being available on w3schools. For properties specific to individual cells, refer to the "Row and cell values" section below. For a list of frequently-used styles by tables on-wiki, however, in their preferred order:

1. text-align:: Specifies the alignment of the text for the table as a whole when listed in the header, or for one specific when listed with a cell. Should be used for the most commonly-used alignment on the table, with the colXleft and colXcenter classes used to align specific columns to another direction when necessary. Many old tables will manually specify alignments for each individual cell, and removing these and replacing them with clever usages of the colX CSS classes is an easy way to both decrease page size, and make code easier to read.
2. display: Determines how a table is displayed, whether on its own, or in-line with the text. While tables that utilize display are infrequent, as the default is normally adequate for our purposes, any instances of the parameter are placed early in the style parameter, as they usually come in groups and require attention when they appear. Examples of in-line tables would be the courses on Golf § Holes.
3. --bgX & --darkbgX: Specifies the color of every cell in a given column, where X is the column's number from left-to-right, akin to the colXleft and colXcenter classes. --bgX is for Light Mode, whereas --darkbgX is for Dark Mode.
4. --borderX: Specifies the color of the bottom border of a cell in a given column, where X is the column's number from left-to-right. Primarily used on tables which, in light mode, have cells with solid black backgrounds, such as various tables on Donkey Kong. Does not have a Dark Mode variant, as, in Dark Mode, tables have multi-colored borders, while on Light Mode, they all have solid black.
5. width: Specifies width, when not using the width parameter. If using a value that is not 100%, it is recommended to use the style instead of the width parameter, for code readability's sake.

Row and cell formatting

In order to apply either a specific format to either a full row or cell, a similar technique is applied to when a table is initialized.

• Rows: When using |- to denote a new row, immediately afterwards, specify either class or style. Rows should not specify width.
• Cells: When using ! to denote a header cell or | to denote a standard cell, immediately afterwards, specify either class, style, width or other valid parameters. Once done, separate them from the cell's contents with a |, regardless of if the cell is a header or standard cell.

Observe these two examples from the example table:

|-style="background:#FDD;--darkbg:#300"
|data-sort-value=Bom|[[File:Bob-OmbBuddySM64.png|100x100px]]<br>[[Bob-omb Buddy|Bob-omb Buddies]]

• To alter the cells in the following row, the style is specified after the |- declaring a new row. Note that X classes will override any colors specified on a per-row basis, though those will be overridden by any classes specified.
• To alter an individual cell, the data-sort-value is specified, before the cell's actual contents are specified after a |.

Row and cell values

Classes

• banner, subbanner, header, & subheader: When used on a header cell, gives that cell the colors of a banner, subbanner, header, or subheader, according to the colors on the color chart. If using these cells, make sure that the cell it is used on is a header (leading with !), as it is unstable if used on a normal cell.
• unsortable: When used on a header cell, prevents its column from being sorted. Primarily for use with descriptions or image-only columns.

Styles

• text-align: When used on a row or cell, changes the text alignment for the cells. This has a higher priority than both the alignment specified in the table's initializing, and the alignment from the X-classes. This parameter primarily appears in outdated tables, before the introduction of the X classes, though it can be used in the event the alignment from an X class de-synchronizes due to an instance of colspan.

1. background & --darkbg: Specifies the color of either every cell when listed in the header, or for one specific cell when listed with a cell. background is for Light Mode, whereas --darkbg is for Dark Mode. While this parameter can be specified in the initialization, it is almost never used for this, and should primarily be reserved for either a by-row basis, or for single cells.
2. border-DIRECTION-color: Specifies the color of one of the cell's borders, with DIRECTION being either top, right, bottom, or left. Used for the same circumstances as --borderX, but on a single-cell basis.

Miscellaneous

• rowspan & colspan: Merges cells together, either by rows (vertically) or by columns (horizontally). Helpful for groups of items, though caution should be used when using it on a table with sortable, or if the table uses any of the X classes, as colspan can cause a de-synchronization in what counts as the given column, requiring some values to be specified manually for the impacted rows(s). If the table uses the alt class, rowspan should be avoided.
• width: Specifies a width for a cell, and attempts to apply it to all cells below it. Best used on a header cell. Can be either percentage based or pixel-based. Percentage widths are preferred, though pixel widths are valid so long as they are kept within reason. If the table is difficult to read on a mobile device, it should probably be switched from pixel widths to percentile widths.
• data-sort-value: When used on a cell in a sortable column, uses the specified value to determine how to sort it (either alphabetically or numerically). Try to use as few letters as possible, though if necessary, additional letters can be included for the sake of code readability. Formatted as data-sort-value=VALUE. The value can, optionally, be enclosed within quotation marks. If there are multiple parameters within the cell, such as a class or style, it is recommended to enclose the value accordingly.
• align: A smaller alternative to the style property text-align. However, since it is lower-priority than the X classes' alignments, it is largely recommended to use text-align. This parameter primarily appears in outdated tables, before the introduction of the X classes.

Formatting

Contents

As the contents of table is very dependent on the subject matter and section of the page itself, table contents can vary between games. Tables should have, at minimum, two columns. One for the subject, and one for content explaining the subject (usually a Description). Additional columns may be added, depending on the subject matter. The column for the subject itself should be the left-most column, with the description close to either the center or right. For older games, sprites are given a separate column from names, for readability's sake. For polygon-based games, however, images should share a column with the subject, and be separated with a <br> as a line break.

By default, it should be assumed that only one image is necessary to represent a subject within a table. Multiple images are permissible if the same subject has multiple distinct visual appearances, though consideration should be given if it would be more suited for a gallery.

If it is necessary to link to a specific section on a table, {{Anchor}} may be used. The anchor template creates an invisible HTML anchor (effectively, a section header that has no visible header, nor appears in the Table of Contents), allowing for linking to a specific section. More complete usage instructions for the {{Anchor}} template can be found on its page, though for using it on cells, it should be placed at the start of the contents of the first cell of the row.

Design

Columns should be centered by default, with text-heavy parameters such as descriptions being made left-aligned, using colXleft if possible. Text-dense tables can, on occasion, be made left-aligned by default, using colXcenter to center valid columns if possible. All tables within mainspace, including ones used by templates, should be compliant with the WCAG 2.1 standards for web accessibility.

The header class is automatically given to headers as specified with a leading !. If a header has a colspan that spans the entire table, it is automatically given the banner class.

It is possible to adjust which classes are used accordingly by manually specifying the banner, subbanner, header, and subheader classes. Which classes should be used depends on how many layers of headers the table has.

1. With only one header, the table should use only the header class. (Most tables will only have one header.)
2. With two layers of headers, the table should use either banner or header classes by default (Like with Donkey Kong Country § Controls, or header or subheader classes if the additional layer is in order to sub-divide a concept without re-iterating the categories (Like with Super Mario Bros. 2 § Objects)
3. With three layers of headers, the table should use the banner, header, or subheader classes. (This quantity of layers is mostly reserved for dense level-overview tables, such as Yoshi's Island DS § Worlds and levels.)
4. Tables with four or more layers should be avoided, though the subbanner class exists to accommodate tables with exactly four layers. If a table has more than four layers, it should likely be split into multiple tables.

Remember that, if giving a cell a header class, the cell must be a header cell (leading with !) itself. Giving the header classes to ordinary cells leads to unstable results that can even look differently depending on browser.

Colorization

In addition to the series coloration classes, tables may use colors to add clarity and delineation to the contents of tables. Outside of the series coloration colors, colors should not be done strictly for aesthetic reasons that do not actively benefit the contents or the table's readability. Colors and context-less images should not be the sole distinguishing factor in the contents of a table, and an alternative of some form (e.g. text, giving the image(s) alt text) should be present within the cell.

The column featuring the subject's image should be given a background color. White, black, and shades of gray are the preferred method of displaying sprites for being a neutral way to present the images, with the subheader class being a permissible alternative. 3D Models should always be displayed with either pure white or pure black as a neutral background color for them. Individual exceptions can be made for certain games depending on their art style, such as with Super Mario Bros. Special.

Any colors not stemming from headers should be written as a hex color code when possible, and if possible, should use shorthand hexadecimal form, being written with three digits (e.g. #FFF, #000, or #00F). Three-digit hex color codes will render as though the color has two of the same digit in one of the color values (e.g. #FFF renders as #FFFFFF, #00F renders as #0000FF).

If a cell's background is sufficiently dark on light mode (or sufficiently light on dark mode), either the {{color}} or {{color link}} templates should be use to retain text readability. When using color link, remember to avoid using the color red so as to distinguish between redlinked pages.

Updating out-of-standard tables

Layout tables (and de-layouting tables)

Layout tables are tables which are, as the name would suggest, created as form-over-function. Diagnosing a table as being a "layout table" is tricky. However, things such as tables nested within tables, repeating header columns for aesthetic purposes, and bullet-pointed lists of the same core concepts crammed into the "Description" section, form the bases for what most would consider a "layout table". A good rule of thumb is that, if you could not use the table as a spreadsheet, nor could you reasonably add the sortable CSS class without fundamentally re-working the table (regardless of the practicality in doing so), without there being separating subheaders involved, chances are, it is a layout table.

In almost all scenarios, layout tables should be avoided. At present, World sections and Level sections, such as the ones used on Super Mario 64 § Table, are permitted to have these less tabular designs due to their unique role in gameplay, though this may be subject to change in the future. In addition, if the table is created to house non-tabular information in of themselves, such as the tables responsible for listing the courses on Golf § Holes, a non-standardized layout is more excusable.

Rewriting a layout table is difficult, and in some extreme cases, it may be easier to simply write a new table from scratch and copy the information over accordingly. However, so long as the format specified above is followed, and there are no cases of unjustifiable data loss between revisions, it is almost always considered preferable to convert a layouted table to one with a more tabular design.

Updating tables without wikitable class

Plenty of the oldest tables on-site pre-date the requirement of the wikitable class. Tables that do not use the wikitable class must be updated to use the class. Plenty of tables that lack a wikitable class hard-code a lot of things that the wikitable class already handles. For instance, if a table manually specifies things such as border, cellspacing, cellpadding, or border-collapse:collapse, those should universally be removed, as the wikitable class already handles these automatically.

In addition, if a table specifies margin, it should be checked if its usage is redundant to the wikitable class. Some tables written before the introduction of the center CSS class may be using the margin parameter in order to center the table. Others still may surround the table with a pair of <center></center> HTML tags. In these cases, make sure to remove either the margin style parameter or <center></center> HTML tag, and add the center CSS class. Caution should be taken when removing a margin parameter outside of these circumstances, as some tables (such as the ones set to display in-line with the display:inline-block style parameter, such as the ones used on Golf § Holes) require the margin parameter to properly display in-line. In these cases, the margin parameter should be retained.

Tables that aren't

Occasionally, table syntax is used for things that are outwardly not meant to be viewed as tables. These are easily spotted, as they usually lack either the wikitable class, nor any parameters after initialization whatsoever outside of, in some cases, width. In most cases, these are a hold-over from before other elements of the wiki were implemented. These should be replaced with their more modern, non-table equivalents. For example, if a table is used to divide a bullet-pointed list into columns, the template {{Columns}} should be used instead, replacing the table entirely.

Tables in templates

In addition to the standard tables that this page is referring to, internally, infoboxes and navboxes utilize table syntax. If writing a new infobox or navbox template, table syntax will be used to comprise the body of the template itself. In lieu of wikitable, two specialized classes are used for these, in the form of infobox and navbox. These classes fulfill a similar function to the wikitable class, and should only be used for infoboxes and navboxes respectively.