Wikipedia:Manual of Style/Tables
Manual of Style (MoS) |
---|
Tables are a way of presenting information in rows and columns. They can be useful for a variety of content presentations on Wikipedia, but should be used only when appropriate; sometimes the information in a table may be better presented as prose paragraphs or as an embedded list. Tables can also make a page much more complicated and difficult to edit, especially if some of the more complex forms of table coding are used, so even if a table is used some consideration needs to be given to the table structure.
Avoid referring to tables as being located on the left or right of a display page. Placement of page content is different in mobile view compared to desktop view of Wikipedia, and is meaningless to people having pages read to them by assistive software. Instead, use captions to identify tables.
Formatting
It is recommended that wikitables be used in place of HTML tables, as they are easier to customize and maintain. A standard wikitable style is available by adding class="wikitable"
to the table. A sorting feature can be enabled by adding class="sortable"
to the table. To use both classes, combine them as class="wikitable sortable"
.
Captions and headers
Table captions and column and row headers should be succinct and self explanatory and used on all data tables. In most cases, individual words or sentence fragments should be used, and thus articles (a, an, the) and sentence-ending punctuation are unnecessary. Only the first word in the caption or header should be capitalized (except for proper nouns), in keeping with Wikipedia's conventions for capital letters. In some rare cases, judicious use of soft hyphens may be helpful .
Much of WP:Manual of Style § Article titles, headings, and sections also pertains to table headers: Use sentence case; avoid redundantly including the subject's name in a header; do not put images in the header (including flag icons), unless this is the best way to present tabular information in a particular case; and do not use questions as headers. Title headers are often suitable places for reference citations (e.g., to source a specific row or column of data). Unlike section headings, they often begin with or consist entirely of numbers (such as model numbers, dates, version numbers, etc.). Table headers do not automatically generate link anchors the way section headings do; use the {{vanchor}}
template to turn a header's text (or part of it) into an anchor.
Appearance
In general, styles for tables and other block-level elements should be set using CSS classes, not with inline style attributes. This is because the site-wide CSS is more carefully tested to ensure compatibility with a wide range of browsers; it also creates a greater degree of professionalism by ensuring a consistent appearance between articles. Deviations from standard conventions are acceptable where they create a semantic distinction (for instance, the infoboxes and navigational templates relating to The Simpsons formerly used a yellow color-scheme instead of the customary mauve, to tie in with the dominant color in the series) but should not be used gratuitously.
See WP:Deviations and Wikipedia talk:Consensus/RfC for guidance on use of coloring or non-standard formatting, and for when MoS and WikiProjects guidance is at variance.
Consideration may be given to collapsing tables which consolidate information covered in the prose.
Wikipedia tables are set flush-left, and allowed to grow rightward, not centered on the page.
Accessibility
Screen readers and other web browsing tools make use of specific table tags to help users navigate the data contained within tables. Use the correct wikitable pipe syntax to take advantage of all the features available.
See MOS:COLOR for information about restrained use of color in tables, to avoid creating accessibility problems for color-blind as well as normal-vision readers.
Do not separate items by leaving blank lines between them, even when using unordered or definition lists. The Wikipedia list templates explicitly identify lists for readers, rather than relying on visual formatting to indirectly imply the presence of a list.
Size
Splitting lists and tables per summary style is advised against. Among other problems, arbitrarily splitting a wikitable effectively disables the powerful and useful sorting feature from working across the entire table.
On the other hand, overloading tables with too much detailed statistical data is against policy. Careful thought should be given to how a reader would use a table, and what level of detail is appropriate.
For very long tables, manageability and maintenance of the page may be better served by breaking information up into several smaller tables instead of one extremely long one. For example, a literary or film award that has been presented for several decades may be better presented through a separate table for each decade rather than one long mega-table, because one long unified table may be much more difficult for future users to edit or update properly.
Sortability
While tables can be made sortable so that they can be rearranged to display the entries in different sort orders, there is no rule that tables must always be sortable in all cases—sortable tables are useful in some instances and not in others. In some tables, for example, the order of display may itself be important information in its own right, such that a reader would not benefit from resorting the table on another column to alter the display order, and in some tables there may sometimes be features or undetected coding errors that actively break sortability.
The various adjustments that may need to be made to the table's content, such as using special {{sort}}
or {{sortname}}
templates to impose an alternate sort order, may also create excessive complication in the table coding which can make it much harder to edit with any new information. If there's a column for individual people's names, for example, then consistent use of sortname templates will be necessary across the board in that column to ensure that the entries sort correctly by surname. Accordingly, if such special code will be necessary, then carefully consider whether there's actually any reader benefit to making the table sortable on alternate criteria at all before forcing sortability.
Where sortability is desired, ensure that the sort system is transparent and straightforward. Do not, for instance, use sequential numbers to enumerate a desired sort order on a column whose content is not actually numbers, such that an editor would have to manually renumber the entire table every time there's a new entry to add to it.
In some tables, it may also be beneficial to make some columns sortable and other columns not sortable at the same time; for instance, if the table directly contains a dedicated "References" column for the footnotes, it is virtually never useful for that column to be directly sortable. Per Help:Sortable tables, this is done by creating a sortable table, but adding class="unsortable"
to the header attributes of the column where sortability is not desired.