维基百科

维基百科:格式手册/列表

< Wikipedia:格式手册
格式手冊
內容
格式
圖片
排版
列表
特定主题
法律
文艺
地區
科學
相關方針指引
灰字链接非正式指引，僅供參考

维基百科常用列表组织信息。列表可在散文条目的正文找到，也可以在“出版物”或“作品”部分等附录找到，或作为独立条目。本指引解释了何时以及如何适当地使用列表。

格式和内容

列表的主题应该十分明确，通常应该通过列表的标题反映，例如“国旗列表”，如果列表的标题不能准确反映列表的内容，则应该在列表的起始段给出明确的说明，不要让其他编辑者和读者猜测一个列表应该包含什么内容。

标题

一个独立列表的标题就是该页面的名称，一个嵌入列表（作为一个段落依附在条目中的列表）的标题应该是段落的标题。列表一般应该以“列表”或者“表”为结尾，比如“国旗列表”。

列表概述

内容方针
核心内容方针
其他内容方針

一个独立的列表是一个条目，任何条目都应该有一个概述部分，列表也不例外。即使是内容非常明显的列表，也应该有概述，在概述中应该有对列举主题的简要的介绍，須說明合理的列表收錄準則，即內容的選擇標準或收錄範圍。存在爭議時，須依照可供查證的要求提供來源。[方針]如果标准复杂，则应该详细写明，以便让读者和其他编辑者明确了解该列表应该包含怎样的主题。同时，概述部分还应该表明一些含义不明显的符号和格式，例如“‘*’表明有争议”等。

嵌入列表没有概述的严格要求，但如果列表标准不明确时推荐在概述中加以说明。

内容

列表的主题内容无例外的要求满足Wikipedia:中立的观点和Wikipedia:可供查证原则。如果没有参考资料支持一个主题被列入某一个列表，则将其列入该列表就是“原创研究”；如果有参考资料支持一个主题列入，而不将其列入则是非中立观点（POV）。在编辑列表的时候应该特别注意其内容与一般条目内容的区别，以及在这种情况下维基百科各个方针指引的适用度。如果列表涉及在世人物，Wikipedia:生者传记方针则应该受到重视。條目名存在類似“傑出/著名人物”等可能模棱兩可、有失中立及原創研究等措辭时，须提供來源。

獨立列表存廢標準

内容方针
核心内容方针
其他内容方針

列表若有「同源條目」，可先考慮「篇幅容許」的情況下，置於同源條目中而不單獨成條。「同源條目」即“XX”和“XX列表”之關係。「篇幅容許」情況有：列表內條目本身極少；列表本身絕大多數為下級列表的連結。

列表不應僅單純地列出各項名稱，而應提供各項名称簡介或各項之間可比較的信息等其他資訊，即該列表不應該可簡單的由分類取代。而未改善的單純列出各項名稱的列表應經存廢討論刪除或改為分類。不應以列表包含红链作為列表不可由分类取代的原因；是否提供各項名称簡介或各項之間可比較的信息等其他資訊，應为区别列表与分类的唯一标准。

分类

每一个列表都应该被分类于包含列表的页面分类中，其根目录是Category:列表。

以地方劃分的人物列表的收錄標準

就以國家、政治實體、國籍、出生地或籍貫來劃分的人物列表來說，有以下規限：

  • 中文維基百科容許建立×國人列表，但是僅限於索引形式，例如這樣。因此，必須要有至少5篇下級列表才可以以×國人列表作為索引，否則不予創建。
  • 如果人物列表的收錄範圍可以預期將會或已經超過100人的話，應該再作細分至下下級列表，直至不超越100人為止。
  • 國籍、出生地或籍貫無可靠來源證實的人物不予收錄。
  • 每篇列表在創建時至少需要有50人，否則刪除。

条目内嵌入人物列表的收录标准

对于条目内人物嵌入列表，其存废标准可较独立列表更为宽松一些，具体情况可自行考量，如遇争议可到Wikipedia:互助客栈/方针寻求共识。以下罗列已达成共识的部分主题：

  1. 姓氏條目禁止嵌入「著名人物」等人物列表，此类信息应由“分类:×姓”或独立列表体现。
  2. 疾病條目禁止嵌入「知名患者」等人物列表，此類信息應由“分類:×疾病患者”或獨立列表體現。
  3. 一般而言，行政区划条目中禁止嵌入仅单纯列点之人物列表，此类信息应由“分类:××人”或独立列表体现。

列表形式

维基百科区分了主要由列表组成的条目（一般称为“列表”或“独立列表”）和主要由散文组成的条目（称为“条目”）。条目旨在主要由散文组成，尽管它们可能包含一些列表。

独立的列表条目

主页面：Wikipedia:独立列表
参见：Wikipedia:格式手冊/作品列表

列表条目是百科全书式的页面，由一个序言部分和一个列表组成（可以用标题划分，也可以不用）。这些列表上的项目包括与某一特定主题领域的条目的链接，并可能包括有关所列项目的额外信息。独立列表的标题通常以条目的主题开始，然后是列表的类型（列表、索引等），例如，植物油列表。它们可以按主题分类或按主题以平面或分层结构进行组织。

标题和符号的格式，或垂直格式，是独立列表的常见格式。这些维基百科条目遵循Wikipedia:独立列表的格式指引。

嵌入式列表

快捷方式

嵌入式列表是在条目中使用的列表，补充条目的散文内容。它们包含或附加在正文中，并可能是表格格式。维基百科使用几个标准的附录，通常是以列表的形式，以及导航模板。

只有在适当的时候才可以使用嵌入式列表；有时，列表中的信息最好以散文形式呈现。以列表形式呈现过多的统计数据可能违反方针。

“子项”（即缩进）

当列表中的项目是其前面段落的“子项”时，使用列表格式可能是合适的。这种“子项”在逻辑上有资格缩进到其父项的描述之下。在这种情况下，以列表形式缩进段落可能会使它们更容易阅读，特别是在段落很短的情况下。下面的例子在有和没有圆点的情况下都适用：

散文 列表
在二十世纪初，纽约市是美学建筑运动的中心，吸引了包括斯坦福·怀特、卡雷尔和黑斯廷斯等伟大建筑师的人才。随着本世纪的发展，更好的建筑和工程技术的出现，纽约成为世界上最高建筑竞争的焦点。

这个城市的天际线由无数不同的摩天大楼组成，其中许多是二十世纪建筑的标志。熨斗大廈高285英尺（87米），在1902年竣工时是该市最高的建筑之一，它的钢制骨架使之成为可能。它是第一批用钢架设计的建筑之一，用当时的其它建筑方法要达到这个高度是非常困难的。伍爾沃斯大樓是一座新哥特式的 "商业大教堂"，俯瞰市政厅，由卡斯·吉尔伯特设计。它的高度为792英尺（241米），在1913年建成后成为世界上最高的建筑，这一荣誉一直保持到1930年，当时它被華爾街40號所超越。同年，克萊斯勒大廈率先成为世界上最高的建筑，在1046英尺（319米）的高空划过。比它的高度更令人印象深刻的是该建筑的设计，由威廉·凡·阿伦设计。克莱斯勒大厦是一个装饰风艺术的杰作，其外观由砖块制成，至今仍是纽约人的最爱。

在二十世纪初，纽约市是美学建筑运动的中心，吸引了包括斯坦福·怀特、卡雷尔和黑斯廷斯等伟大建筑师的人才。随着本世纪的发展，更好的建筑和工程技术的出现，纽约成为世界上最高建筑竞争的焦点。这个城市的天际线由无数不同的摩天大楼组成，其中许多是二十世纪建筑的标志：
  • 熨斗大廈高285英尺（87米），在1902年竣工时是该市最高的建筑之一，它的钢制骨架使之成为可能。它是第一批用钢架设计的建筑之一，用当时的其它建筑方法要达到这个高度是非常困难的。
  • 伍爾沃斯大樓是一座新哥特式的 "商业大教堂"，俯瞰市政厅，由卡斯·吉尔伯特设计。它的高度为792英尺（241米），在1913年建成后成为世界上最高的建筑，这一荣誉一直保持到1930年，当时它被華爾街40號所超越。
  • 同年，克萊斯勒大廈率先成为世界上最高的建筑，在1046英尺（319米）的高空划过。比它的高度更令人印象深刻的是该建筑的设计，由威廉·凡·阿伦设计。克莱斯勒大厦是一个装饰风艺术的杰作，其外观由砖块制成，至今仍是纽约人的最爱。

作品列表和时间轴

参见：Wikipedia:格式手冊/作品列表和Wikipedia:年表
快捷方式

个人或团体的作品列表，如书目、唱片、电影、专辑人员和曲目列表，通常以简单的列表格式呈现，尽管预计这些信息将通过对要点的散文分析在条目的其它地方得到支持，如果列表变得难以处理，则按照WP:摘要格式将其拆分为独立的列表。时间线和年表可以作为现实世界历史的散文描述的有益补充。列表的内容受与散文相同的内容方针的约束，包括应有的比重和避免原创研究的原则。根据维基百科的方针和指引（包括WP:TRIVIA部分），确保列表项目对主题的重要性与该项目在条目正文中的要求相同。考虑一下散文是否更合适。关于时间线的具体建议在Wikipedia:年表标准中给出。

相关条目（导航列表）

快捷方式
参见：Wikipedia:格式手冊/版面佈局 § 相關條目和Wikipedia:导航模板

“参见”列表和“相关条目”列表是宝贵的导航工具，可以帮助用户找到相关的维基百科条目。当决定在任何给定的条目中添加哪些条目和条目列表时，试着把自己放在读者的头脑中是很有用的。问问自己，读者在读完这篇条目后可能想去哪里。一般来说，这将包括三种类型的链接：

  • 相关主题的链接 - 与条目中讨论的主题类似。
  • 高阶（即，更大体的）条目和列表--这可能包括人的列表、主权国家列表，等等。例如，印度语诗人列表应该同时链接到印度人列表和诗人列表。
  • 低阶（即更具体）的条目和列表--例如，企业页面导航列表包含小企业的链接，会计主题列表等。

对于在任何条目中应该放多少个条目链接和列表链接，存在一些争议。有些人把“条目链接”（放在“参见”部分）和“列表链接”（放在“相关主题”部分）分开，但这是没有必要的，除非有太多的链接需要单独放在一个部分。有些人认为，在任何一篇文章的结尾，应该包括的列表链接的最佳数量是0、1或2。另一些人则认为，一套更全面的列表会很有用。一般来说，在决定包括什么列表时，应该使用决定在“参见”部分包括什么条目的相同标准。编辑应该试着把自己放在读者的心态上，问“读完这篇条目后我可能想去哪里？”。一般来说，“参见”部分不应重复出现在条目正文中的链接。

参考资料和外部链接

参考资料列表展示了维基百科之外的信息来源。两种最常见的类型是：

  • “网络超链接” - 在“外部链接”标题下的维基百科以外的网址链接列表
  • “参考文献” - 在“参考资料”标题下的学术期刊文章或书籍列表

维基百科不是一个链接集，积极不鼓励只有外部链接的条目，但从互联网上引用更详细的资料是合适的。当你把一个网站作为重要的信息来源时，情况更是如此。

列表的特殊名称

维基百科上的大多数列表是项目列表，但不是全部。专门的列表类型包括：

  • 大纲 - 维基百科的大綱是一个分层排列的属于某一特定主题的主题列表。大纲是维基百科上两种类型的一般主题列表之一，另一种是索引。
  • 索引 - 维基百科上的索引是一个按字母顺序排列的关于某一特定主题的文章列表。
  • 时间轴 - 时间轴是按时间顺序排列的事件的图形表示。
  • 作戰序列 - 武装力量组成部分的代表，显示了层级组织和指挥结构。
  • 作品列表包括书目和唱片目录。书目是一个主题领域的相关参考文献列表，包括书籍、期刊文章和网络文章；唱片目录是一个音乐家或歌手的所有唱片的列表，也可以根据流派或唱片公司来编制。
  • 词汇表 - 词汇表是一个特定主题领域的术语列表，其中包括定义。
  • 同类索引条目 - 记录一组共享相同（或相似）名称的项目。它们与消除歧义的页面不同，因为它们是完整的条目，旨在记录多个主题，而消除歧义的页面仅用于导航目的。并非所有的同类索引条目都是列表。
  • 动态列表 - 动态列表是任何随着其涵盖的主题变化而变化的列表。因此，它可能永远不会被完成。任何类型的列表都可能是动态的。

列表用途

快捷方式

列表主要有三类用途：

提供资讯

列表可以提供有价值的资讯，尤其是结构化列表——例如按时间组织的列表、按主题分组的列表，或项目附带说明描述的列表。

辅助导航

项目包含内部链接时，列表可以自然成为维基百科的内容索引。如果读者对搜索目标有大致概念，但不知道具体术语，则可以浏览内容大纲（英语：WP:Contents/Outlines），它自上而下通向维基百科大部分（即使不是全部）列表，进而通向相关条目。首页可进入的主题空间中（部分主题）也列出了一些列表；此外，在列表条目（或其他条目）底部也通常有导航模板链往其他列表。

发展百科

一些列表有助于维基百科发展。一系列主题列表可以表明维基百科当前状态，尤其是标示已写条目和未写条目。然而，维基百科主要为读者而非编者优化，故主要为开发维护而存在的列表（如只含有红链且未提供有价值资讯的列表，特别是项目均为红链的主题列表）应该放在维基百科（“Wikipedia:”）或用户（“User:”）命名空间，而非主命名空间。

列表和分类

参见：WP:分類、列表與導航模板

列表和分类同时存在是有益的，因为这两种项目组织方式协同运作（《WP:分類、列表與導航模板》提及了相关原则）。与分类相同的是，列表可以使用链出更改功能来监视所列页面的更改；与分类不同的是，列表还能在编辑历史中显示其所含项目的变化，还允许在同一页面上显示大量项目。

列表命名

对于一个独立的列表，列表的标题是页面名称。对于嵌入式列表，列表的标题通常是一个章节的标题（例如，超人前传 (第一季)#各集列表），但它可以更短。列表的标题不应具有误导性，通常不应包括缩写词。此外，过于精确的列表标题可能不那么有用，而且会使列表难以找到；列表的精确收录标准应该在标题部分（见下文）阐明，而不是在标题中阐明。例如，像“完整”和“显著”这样的词通常不会出现在列表标题中。相反，标题应明确说明该名单是否完整，或者是否仅限于广为人知或著名的成员（即那些值得发表的条目）。请注意，“著名”一词被认为是一种不必要的宣传点缀，不应使用。

列表布局

快捷方式

在易于理解的地方使用散文

倾向于散文，因为一段话很容易被理解为普通的文字。条目中首选散文，因为它可以介绍细节和澄清背景，而简单的列表可能无法做到。它最适合于条目，因为其目的是解释。

快捷方式

{{prose}}可以用来表明一个可能更适合写成散文的列表。许多小作品条目可以通过将不必要的列表转换为百科全书式的散文而得到改进。参见：WP:格式手冊/瑣碎章節。

散文与列表的区别示例
散文 没有内容的列表
纽约市二十世纪的建筑包括众多的标志性建筑，最引人注目的是摩天大樓。在本世纪的头几十年里，该市成为以建筑师斯坦福·怀特、卡雷尔和黑斯廷斯为代表的美学运动的中心。纽约的新摩天大楼包括熨斗大廈（1902年），第五大道在麦迪逊广场与百老汇交叉的地方；卡斯·吉尔伯特的伍爾沃斯大樓（1913年），一个俯瞰市政厅的新哥特式“商业大教堂”；克萊斯勒大廈（1929年），纯粹的装饰风艺术；以及帝国大厦（1931）。第二次世界大战后，现代主义建筑师雷蒙德·胡德和利华大楼开始建造一系列“玻璃盒子”，改变了20世纪30年代的经典天际线，最终在世界贸易中心大厦（1973年）达到顶峰。 纽约市二十世纪的建筑

使用良好的标记

主页面：Wikipedia:格式手冊/親和力 § 列表

使用适当的标记：使用谨慎的wiki标记或基于模板的列表代码（见Help:列表的许多建议）。特别是不要在列表中的项目之间留下空行，因为这将导致MediaWiki软件误认为每項项目是一个新列表的开始。(有些HTML技术可以在列表项中插入断行或附加段落)。避免在条目中误用列表标记来设置非列表材料的视觉样式。

图片和列表

A（良好的） 
 [[File:Example.jpg|thumb|Caption text]]
 * Example 1
 * Example 2
 * Example 3
 * Example 4
B（不好的） 
 * Example 1
 * Example 2
 [[File:Example.jpg|thumb|Caption text]]
 * Example 3
 * Example 4
C（良好的） 
 * Example 1
 * Example 2
 * [[File:Example.jpg|thumb|Caption text]] Example 3
 * Example 4

为了将图片浮动到列表的右边，在大多数情况下应该将图片标记放在第一项之前，见例子“A”。再一次将图片标记作为单独的一行插入到列表中（如例子“B”），会将其分成两个半列表。

如果列表项的长度或所述图片的主题相关性使该图片不适合显示在顶角，可以考虑将其放在它所示的第一个列表项的星号之后（如例子“C”），以避免破坏无序列表（<ul>）元素的连续性。

注意：当把图片浮动到列表左侧时，请使用{{flowlist}}模板，以防止破坏圆点的缩进。

默认使用无序列表

默认情况下，使用带圆点（无序）的列表，特别是对于长列表。只有在需要按编号引用项目、项目的顺序很重要，或者在现实世界中存在编号的情况下（例如，专辑中的曲目），才使用编号（有序）的列表。

介绍性材料

快捷方式

列表中应该有介绍性材料；对于独立列表，这应该是序言章节。这个介绍性材料应该清楚地说明该列表的范围。它还应该为列表的非明显特征提供解释，如列表的结构。独立的列表可以将非显而易见的特征放在单独的介绍部分。

列表和它们的辅助材料必须是中立的。对主题互补的独立列表不应包含主题的内容。介绍性材料也应应该避免自我提及维基百科。

有些信息，如“著名人物”或“校友”，可能是为了了解背景或细察内容而阅读的，可根据大小，采用章节序言和描述性的、带圆点的列表，或散文格式。如果名单很长，无法总结，但又不适合拆分，那么，用一个章节序言，加上描述性的、带圆点的列表，可能比长的散文部分更合适。

组织结构

快捷方式

尽管列表可以用不同的方式组织，但它们必须始终是有组织的。最基本的组织形式包括按字母或数字排列，但如果项目有特定的日期，有时最好是按时间顺序排列（例如，白俄罗斯总理）。当使用更复杂的组织形式时，（按来源、按用途、按类型等），分类的标准必须明确和一致。就像读者或编辑可以很容易地假定标题A、B、C后面是D（而不是1903）一样，更复杂的系统也应该同样明确。如果一份国际监狱中的澳大利亚人列表包含阿根廷和柬埔寨的标题（按国家组织），那么编辑加上非法毒品貿易的标题（按罪行组织）就不合适了。如果一个列表条目在逻辑上属于两个或更多的类别（例如，一个澳大利亚人因贩毒而被关押在阿根廷监狱），这表明列表的分类可能存在缺陷，应该重新审查。

列表不应该包含“未分类”或“杂项”的标题，因为所有值得列入列表的项目都可按照某些标准分类，尽管完全有可能需要修改列表的格式以包括所有合适的项目。尚未分类的项目可以在确定其分类的时候列入列表的讨论页。

列表尺寸

快捷方式

就其目的和范围而言，列表和表格应尽量简短：列表中的资料应与条目的主题相关，而不涉及不必要的细节；统计数据应按方针保持在最低限度。

有些资料可能不适合用摘要式方法來缩减或总结。一个嵌入式列表可能需要完全拆分到一个列表条目中，留下一个{{See}}模板，产生：

更多信息：test

在某些情况下，列表格式可能比一个句子中的长序列更可取，比较：

散文 列表
哲学家们讨论了提供定义的意义、功能和可能性。典型的做法是（例如，在大学的逻辑课本中）区分一些不同种类和技术的定义，包括字典或詞法定義、延伸性定义、外延性定义、实指定义、規定性定義、操作定义、理論性定義、說服性定義以及從屬差異定義。 哲学家们讨论了提供定义的意义、功能和可能性。典型的做法是（例如，在大学的逻辑课本中）区分一些不同种类和技术的定义，包括：

向列表中添加单个项目

快捷方式
參見：Wikipedia:维基百科不是什么 § 维基百科不是词典及§ 維基百科不是不經篩選的資訊收集處
更多信息：Wikipedia:独立列表 § 選擇標準

列表，无论是独立列表（也称为列表条目）还是嵌入式列表，都是百科全书式的内容，就像仅有段落的条目或章节那样。因此，列表上的所有单项必须遵循维基百科的内容方针：核心内容方针是可供查证（通过项目的一个或多个参考资料中的良好来源）、非原创研究和中立的观点，另外还有其它内容方针。如果内容包含四种绝对需要引用的材料中的任何一种，则应在其出现的地方用内文引用注明来源。虽然列表的格式可能对每个主题的细节要求较低，但维基百科的方针和程序同样适用于类似事物的列表，以及列表中的单个事物可能被链接到的任何相关条目。

内容方针
核心内容方针
其他内容方針

在添加或编辑列表中的项目时要大胆，但也要在大胆与周到之间取得平衡，所有的内容方针都是为了帮助编辑者实现这一平衡。对于质量不确定的编辑，可以先在讨论页上讨论，以获得其它编辑的反馈。

除了对这种反馈有用之外，讨论页讨论也是一个很好的审查过程，可以在添加一个困难或有争议的项目之前达成共识，特别是那些对主题本身的定义有争议的项目。请注意，与本节提到的其它方针和程序一样，这个过程可以用于维基百科上任何类型的困难或有争议的百科全书式内容。

在编辑列表本身之前在讨论页上达成共识，不仅从长远来看可以节省时间，而且有助于确保列表上的每一项内容都有很好的参考价值，而且列表整体上代表了中立的观点。内容出现的地方要有来源，如果包含四种绝对需要有引证的材料，要提供内文引用。

当一个项目符合可供查证方针的要求时，列表中的读者可以检查一个项目的参考资料，以了解该信息是否来自可靠的来源。对于信息的可供查证，也意味着维基百科不发布原创研究：它的内容是由以前在一个好的来源中发布的信息决定的，而不是其编辑的信念或经验，甚至是编辑的解释超出了来源的实际内容。即使你确定一个项目与列表的主题有关，你也必须在添加到列表之前找到一个良好的来源来验证这一知识（尽管你可以在讨论页上建议），并在项目旁边的参考资料中添加该来源。

在涉及生者的列表中，适用生者傳記的方针。

当可靠的消息来源出现分歧时，保持中立观点的方针要求描述相互竞争的观点，而不支持任何特定的观点。编辑应该简单地介绍各种消息来源的内容，根据所发表的可靠消息来源中每种观点的突出程度来平衡报道，给予每一方应有的重视。

当添加到一个有其它条目链接的独立列表时，在添加你的项目时要遵循既定的格式，然后看看你是否能将该项目链接到关注该项目主题的条目。如果是这样的话，就考虑列表的格式是否允许在列表项目中容纳所有竞争性观点的细节，或者这些细节是否只应该在链接的、关于该主题的主要条目中涉及。无论哪种方式，如果主条目中没有这些内容，请确保将其添加到主条目中。

分类

你可以在包含一个可能具有独立百科全书意义的列表的页面底部，添加一个或多个合适的Category:列表子分类。如果有一个列表的重定向（例如，从“List of Presidents of Elbonia”到“President of Elbonia#List of Elbonian Presidents”），则将列表分类放在以“列表”命名的重定向上。

列表样式

参见：Help:列表和Wikipedia:格式手冊/親和力 § 列表

在维基百科上有几种呈现列表的方式。

带圆点的列表

快捷方式

这是维基百科上最常见的列表类型。列表中的每项内容通常是一个简单的单词、短语或单行文字，不适合用数字排序，或者是极其简短的列表，在这种情况下，一眼就能看出这些内容不是问题。它们不适合于大段的文字。简单的带圆点的列表是通过在一行中以*开头，然后添加列表项目的文本，每行*有一个项目来创建的。

列表项目的格式应一致。摘要：

  • 倾向于句子的情况。
  • 倾向于使用完整的句子，并避免将句子和片段混合作为同一列表中的项目。
  • 句子片段不使用结尾标点符号。
  • 列表项目之间不要放空行。
良好的示例
Wikitext HTML 显示 
== 列表名稱 ==
* 例子 1
* 例子 2
* 例子 3

<h2><span class="mw-headline" id="Title_of_list">列表名稱</span></h2>
<ul>
<li>例子 1</li>
<li>例子 2</li>
<li>例子 3</li>
</ul>
列表名稱
  • 例子 1
  • 例子 2
  • 例子 3

HTML格式化可以用来创建丰富的列表，包括有内部段落分隔的项目。在列表中使用图像需要注意一些问题。

对于信息框来说，可以用简单的模板将带圆点的列表转换为无圆点或水平样式，以抑制大圆点和缩进。

不要在列表后面留出空行，使列表的行数有双重空间。这样做会把列表分成多个列表，违背了使用列表标记的目的。这对可访问性有不利影响（屏幕阅读器会告诉视力受损的用户有多个列表）[1]，并干扰机器对内容的可解析性，以便重复使用。此外，在某些网络浏览器中，一个列表输出块和下一个列表输出块之间的额外空白可能会产生视觉上的干扰效果。

不好的示例
Wikitext HTML 显示 
== 列表名稱 ==
* 例子 1

* 例子 2

* 例子 3

<h2><span class="mw-headline" id="Title_of_list">列表名稱</span></h2>
<ul>
<li>例子 1</li>
</ul>
<ul>
<li>例子 2</li>
</ul>
<ul>
<li>例子 3</li>
</ul>
列表名稱
  • 例子 1
  • 例子 2
  • 例子 3

这样做实际上会产生三个列表，每个列表包含一个项目！请注意呈现的HTML，其中的<ul>标记与<li>标记一样多。

无圆点的列表

快捷方式

对于不带圆点的多达30个项目（以后可能会增加）的列表，请使用{{Plainlist}}或{{Unbulleted list}}模板。典型的用途是在信息框字段中，以及替换用<br />分隔的伪列表。模板会发出正确的HTML标记，并使用CSS（见Template:Plainlist § Notes）隐藏圆点。

Wikitext HTML 显示 
== 列表名稱 ==
{{Plainlist|
* 例子 1
* Example 2
* Example 3
}}

<h2><span class="mw-headline" id="Title_of_list">列表名稱</span></h2>
<div class="plainlist">
<ul>
<li>例子 1</li>
<li>例子 2</li>
<li>例子 3</li>
</ul>
</div>
列表名稱
  • 例子 1
  • 例子 2
  • 例子 3
== 列表名稱 ==
{{Unbulleted list
| 例子 1
| 例子 2
| 例子 3
}}

<h2><span class="mw-headline" id="Title_of_list">列表名稱</span></h2>
<div class="plainlist">
<ul>
<li>例子 1</li>
<li>例子 2</li>
<li>例子 3</li>
</ul>
</div>
列表名稱
  • 例子 1
  • 例子 2
  • 例子 3

{{Plainlist}}的一个好处是，它可以被包裹在已经存在的带圆点的列表中。{{Unbulleted list}}的一个特点是，对于一个短的列表，它可以放在一个单行上：{{Unbulleted list|例子 1|例子 2|例子 3}}.

编号列表

快捷方式

只有在以下情况下才使用编号（有序）的列表：

  • 有必要用编号来指代这些元素。
  • 项目的顺序是关键。
  • 编号有一些独立的意义，例如在一张专辑的音乐曲目列表中。

在一行的开头使用#符号来生成一个编号的列表项（除了本节中详细说明的以外，这与上面的*号列表的作用相同）。

列表项目的格式应一致。摘要：

  • 倾向于句子的情况。
  • 倾向于使用完整的句子，并避免将句子和片段混合作为同一列表中的项目。
  • 句子片段不使用结尾标点符号。
  • 列表项目之间不要放空行。

示例：

Wikitext HTML 显示 
== 列表名稱 ==
# 例子 1
# 例子 2
# 例子 3

<h2><span class="mw-headline" id="Title_of_list">列表名稱</span></h2>
<ol>
<li>例子 1</li>
<li>例子 2</li>
<li>例子 3</li>
</ol>
列表名稱
  1. 例子 1
  2. 例子 2
  3. 例子 3

编号列表中的项目之间的空行不仅会导致与项目列表中相同的断列问题，而且还会在“1”处重新开始编号。如果没有复杂的标记，这一点是无法解决的（违背了编辑便利性的期望），所以在编号列表中应该始终避免使用双行距。

HTML格式化可以用来创建丰富的列表，包括有内部段落分隔的项目。在列表中使用图像需要注意一些问题。

其它案例

快捷方式

有经验的编辑可以使用原始HTML来实现更复杂的结果，如使用数字以外的索引的有序列表，以及不从1开始的有序列表。

Wikitext 显示 
<ol type="a">
<li>this</li>
<li>list</li>
<li>uses</li>
<li>letters</li>
<li>as</li>
<li>indexes</li>
</ol>
  1. this
  2. list
  3. uses
  4. letters
  5. as
  6. indexes
<ol start="10">
<li>this</li>
<li>list</li>
<li>starts</li>
<li>from</li>
<li>10</li>
</ol>
  1. this
  2. list
  3. starts
  4. from
  5. 10
<ol type="I" start="50">
<li>this</li>
<li>list</li>
<li>uses</li>
<li>roman</li>
<li>numerals</li>
<li>and</li>
<li>starts</li>
<li>from</li>
<li>50</li>
</ol>
  1. this
  2. list
  3. uses
  4. roman
  5. numerals
  6. and
  7. starts
  8. from
  9. 50

列表类型（type）的有效值为：

  • 1（默认，数字）
  • a（小写拉丁字母）
  • A（大写拉丁字母）
  • i（小写罗马数字）
  • I（大写罗马数字）

起始值可以是负数，但只有在列表使用数字作为索引的情况下。否则，会产生奇怪的结果。

Wikitext 显示 
<ol type="a" start="-2">
<li>definitely</li>
<li><b>not</b></li>
<li>a</li>
<li>good</li>
<li>idea!</li>
</ol>
  1. definitely
  2. not
  3. a
  4. good
  5. idea!

描述（定义、关联）列表

快捷方式

一个描述列表包含“......术语和定义、元数据主题和值、问题和答案或任何其它的名-值数据组”。[2][3]在维基百科上，描述列表最常见的用途是用于词汇表，在那里它比其它样式更受欢迎。维基百科对描述列表有专门的标记：

代码 效果 
; 名称 1 : 值 1
; 名称 2 : 值 2
; 名称 3 : 值 3
名称 1
值 1
名称 2
值 2
名称 3
值 3

来源也可以在术语后的下一行布置描述值，像这样：

代码 效果 
; 名称 1
: 这是与第一个名称相关的值，可能相当长，但必须是来源中一行不间断的行。
; 名称 2
: 这是与第二个名称相关的值，也可能是长的。
名称 1
这是与第一个名称相关的值，可能相当长，但必须是来源中一行不间断的行。
名称 2
这是与第二个名称相关的值，也可能是长的。

这仍然使名称和值保持在一个单一的描述列表中，而且典型的短名称和长值的交替使独立的组件在编辑时容易被发现。由此产生的布局和HTML与单行语法所产生的布局和HTML是相同的。

无论哪种wikitext标记都是功能有限的，而且容易被破坏。这两种wikitext标记的一个主要弱点是，它们很容易被试图创建多行值的后期编辑破坏。这些问题在冗长的描述列表中最为突出。因此，有一些模板用于制作描述列表，如词汇表，其方式是提供更丰富、更复杂的内容，包括多段、块状引文、子列表等。

模板式结构的描述列表的基本格式是：

标记 渲染为

{{glossary}}
{{term |名称 1}}
{{defn |值 1}}
{{term |名称 2}}
{{defn |值 2}}
{{term |名称 3}}
{{defn |值 3}}
{{glossary end}}

名称 1
值 1
名称 2
值 2
名称 3
值 3

在描述列表中使用wikitext或上述模板，而不是其它捏造的格式，因为其它格式可能会让读者和编辑都感到意外，妨碍维基百科内容的重用性，使自动处理更加困难，并带来可用性和可访问性问题。(其它格式可能会占用较少的垂直空间，但会使读者更难扫描）。也就是说，一个描述包含超过一段的项目列表可能作为独立的列表条目中的章节呈现得更好，而表格比描述列表更适合于关联内容，特别是当每个项目有多个值的时候。

与无序（带圆点）和有序（编号）列表一样，描述列表中的项目之间不应该有空行，因为这会导致每个条目在输出中成为自己的假“列表”，从而使将项目放在列表标记中的意义消失。

当维基标记的冒号仅仅用于视觉缩进时，它们也会在HTML中被呈现为描述列表，但没有“;”--限定的术语，而这些术语适用于“:”--缩进的材料，也没有列表的开始和结束标记，这将产生破碎的标记（详见WP:格式手冊/親和力#缩进）。可以使用更方便的缩进模板，例如，{{in5}}或其变体用于一行，{{block indent}}用于多行（即使讨论页上的描述列表标记的滥用已经根深蒂固，目前无法改变）。

即使描述列表术语不是标题，它们在某些方面也像标题。然而，至少在一个方面，它们不是：描述列表术语wikitext（;）不应该被用来划分大的章节。应使用副标题（例如，===副标题===）。

以散文和描述列表的形式比较内容
散文 列表


疾病是指任何损害正常功能的异常状况，尤其是感染病，它是由致病微生物制剂的存在而导致的临床明显的疾病。病症通常是疾病的同义词，除非用来特指病人对其疾病的个人体验。医疗状况是一个宽泛的术语，包括所有疾病和紊乱，但也可以包括可能影响个人健康、受益于医疗援助或对医疗有影响的創傷和正常健康状况，如怀孕。

疾病
指任何损害正常功能的异常状况，尤其是感染病，它是由致病微生物制剂的存在而导致的临床明显的疾病。
病症
通常是疾病的同义词，除非用来特指病人对其疾病的个人体验。
医疗状况
一个宽泛的术语，包括所有疾病和紊乱，但也可以包括可能影响个人健康、受益于医疗援助或对医疗有影响的創傷和正常健康状况，如怀孕。

表格

主页面：Wikipedia:格式手冊/表格

表格是一种以行和列形式呈现链接、数据或信息的方式。它们是一种复杂的列表形式，特别是当每个列表项感兴趣的信息超过2条时，它们非常有用。表格需要一个更复杂的符号，应该仔细检查其可及性。可以考虑合并散文中所涉及的信息的折叠表。

表格可用于呈现数学数据，如乘法表、比较数字或体育成绩。它们也可用于呈现两种或更多语言的等价词，用于按类型和年份划分的奖项，以及复杂的唱片谱系。

水平列表

快捷方式

在诸如信息框的情况下，水平列表可能是有用的。示例：

做法 输出 代码
用逗号列出 事项 1，事项 2，事项 3 只是纯文本
用{{Hlist}}列出
  • 事项 1
  • 事项 2
  • 事项 3
 {{hlist|事项 1|事项 2|事项 3}}
用{{Flatlist}}列出
  • 事项 1
  • 事项 2
  • 事项 3

{{flatlist|
* 事项 1
* 事项 2
* 事项 3
}}

{{Flatlist}}的一个好处是，它可以被包裹在一个已经存在的带圆点的列表中。{{Hlist}}的一个特点是，对于一个简短的列表，它可以被放在一个单行上。

时间轴

参见：Wikipedia:年表标准
快捷方式

对于日期事件的列表，或时间轴，每个事件使用一个{{Timeline-event}}实例，因此： 

* {{Timeline-event|date={{Start date|1904|11|18|df=y}}|event=发生了一件事}}
* {{Timeline-event|date={{Start date|1905}}|event=没有发生什么事}}
* {{Timeline-event|date={{Start date|1906|01|21}}|event=发生了其它事情}}

渲染为：

  • 1904年11月18日 (1904-11-18)：发生了一件事
  • 1905年 (1905)：没有发生什么事
  • 1906年1月21日 (1906-01-21)：发生了其它事情

（注意可选的df=y（日期优先）参数--日期格式在个别条目中应该是一致的）。

按时间顺序排列的列表，如时间轴，应按从早到晚的时间顺序排列。

换行

主页面：Wikipedia:格式手冊/無障礙 § 列表
快捷方式

代码 效果 
cake<br />
cheese<br />
chocolate<br />

cake
cheese
chocolate

这种“伪列表”方法已被废弃，因为它不符合Web标准，并可能导致可访问性问题。取而代之的是，使用上面定义的更多格式化的列表样式之一。

模板文本

在一个不完整的列表前，插入{{incomplete list}}，这将把以下内容嵌入该页：

參见

注释

  1. ^ 空行对螢幕閱讀器的用户造成特别的问题。上面那个格式不好的例子被大声读出来是这样的。“1个项目的列表：例1，列表结束。1个项目的列表：例2，列表结束。1个项目的列表：例3，列表结束。”不恰当的格式化会使阅读列表的时间增加三倍以上。
  2. ^ HTML5: A Vocabulary and Associated APIs for HTML and XHTML – W3C Recommendation, World Wide Web Consortium, "4.4.8 The dl element", 2014年10月28日 .
  3. ^ 描述列表在HTML4中被称为定义列表，在HTML5早期被称为关联列表。
检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia:格式手册/列表&oldid=84757366”