維基百科:格式手冊/列表

維基百科,自由的百科全書

維基百科常用列表組織信息。列表可在散文條目的正文找到,也可以在「出版物」或「作品」部分等附錄找到,或作為獨立條目。本指引解釋了何時以及如何適當地使用列表。

格式和內容

列表的主題應該十分明確,通常應該通過列表的標題反映,例如「國旗列表」,如果列表的標題不能準確反映列表的內容,則應該在列表的起始段給出明確的說明,不要讓其他編輯者和讀者猜測一個列表應該包含什麼內容。

標題

一個獨立列表的標題就是該頁面的名稱,一個嵌入列表(作為一個段落依附在條目中的列表)的標題應該是段落的標題。列表一般應該以「列表」或者「表」為結尾,比如「國旗列表」。

列表的概述

一個獨立的列表是一個條目,任何條目都應該有一個概述部分,列表也不例外。即使是內容非常明顯的列表,也應該有概述,在概述中應該有對列舉主題的簡要的介紹,須說明合理的列表收錄準則,即內容的選擇標準或收錄範圍。存在爭議時,須依照可供查證的要求提供來源。[方針]如果標準複雜,則應該詳細寫明,以便讓讀者和其他編輯者明確了解該列表應該包含怎樣的主題。同時,概述部分還應該表明一些含義不明顯的符號和格式,例如「『*』表明有爭議」等。

嵌入列表沒有概述的嚴格要求,但如果列表標準不明確時推薦在概述中加以說明。

內容

列表的主題內容無例外的要求滿足Wikipedia:中立的觀點Wikipedia:可供查證原則。如果沒有參考資料支持一個主題被列入某一個列表,則將其列入該列表就是「原創研究」;如果有參考資料支持一個主題列入,而不將其列入則是非中立觀點(POV)。在編輯列表的時候應該特別注意其內容與一般條目內容的區別,以及在這種情況下維基百科各個方針指引的適用度。如果列表涉及在世人物,Wikipedia:生者傳記方針則應該受到重視。條目名存在類似「傑出/著名人物」等可能模稜兩可、有失中立及原創研究等措辭時,須提供來源。

獨立列表之存廢標準

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

列表不應僅單純地列出各項名稱,而應提供各項名稱簡介或各項之間可比較的信息等其他資訊,即該列表不應該可簡單的由分類取代。而未改善的單純列出各項名稱的列表應經存廢討論刪除或改為分類。不應以列表包含紅鏈作為列表不可由分類取代的原因;是否提供各項名稱簡介或各項之間可比較的信息等其他資訊,應為區別列表與分類的唯一標準。

分類

每一個列表都應該被分類於包含列表的頁面分類中,其根目錄是Category:列表

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

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

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

條目內嵌入人物列表的收錄標準

對於條目內人物嵌入列表,其存廢標準可較獨立列表更為寬鬆一些,具體情況可自行考量,如遇爭議可到Wikipedia:互助客棧/方針尋求共識。以下羅列已達成共識的部分主題:

  1. 姓氏條目禁止嵌入「著名人物」等人物列表,此類信息應由「分類:×姓」或獨立列表體現。
  2. 行政區劃條目禁止嵌入「本地出身人物」等人物列表,此類信息應由「分類:××人」或獨立列表體現。
  3. 疾病條目禁止嵌入「知名患者」等人物列表,此類信息應由「分類:×疾病患者」或獨立列表體現。

列表的形式

維基百科區分了主要由列表組成的條目(一般稱為「列表」或「獨立列表」)和主要由散文組成的條目(稱為「條目」)。條目旨在主要由散文組成,儘管它們可能包含一些列表。

獨立的列表條目

列表條目是百科全書式的頁面,由一個序言部分和一個列表組成(可以用標題劃分,也可以不用)。這些列表上的項目包括與某一特定主題領域的條目的連結,並可能包括有關所列項目的額外信息。獨立列表的標題通常以條目的主題開始,然後是列表的類型(列表、索引等),例如,植物油列表。它們可以按主題分類或按主題以平面或分層結構進行組織。

標題和符號的格式,或垂直格式,是獨立列表的常見格式。這些維基百科條目遵循Wikipedia:獨立列表的格式指引。

嵌入式列表

嵌入式列表是在條目中使用的列表,補充條目的散文內容。它們包含或附加在正文中,並可能是表格格式。維基百科使用幾個標準的附錄,通常是以列表的形式,以及導航模板

只有在適當的時候才可以使用嵌入式列表;有時,列表中的信息最好以散文形式呈現。以列表形式呈現過多的統計數據可能違反方針

「子項」(即縮進)

當列表中的項目是其前面段落的「子項」時,使用列表格式可能是合適的。這種「子項」在邏輯上有資格縮進到其父項的描述之下。在這種情況下,以列表形式縮進段落可能會使它們更容易閱讀,特別是在段落很短的情況下。下面的例子在有和沒有圓點的情況下都適用:

散文 列表
在二十世紀初,紐約市美學建築運動的中心,吸引了包括斯坦福·懷特、卡雷爾和黑斯廷斯等偉大建築師的人才。隨着本世紀的發展,更好的建築和工程技術的出現,紐約成為世界上最高建築競爭的焦點。

這個城市的天際線由無數不同的摩天大樓組成,其中許多是二十世紀建築的標誌。熨斗大廈高285英尺(87米),在1902年竣工時是該市最高的建築之一,它的鋼製骨架使之成為可能。它是第一批用鋼架設計的建築之一,用當時的其它建築方法要達到這個高度是非常困難的。伍爾沃斯大樓是一座新哥德式的 "商業大教堂",俯瞰市政廳,由卡斯·吉爾伯特設計。它的高度為792英尺(241米),在1913年建成後成為世界上最高的建築,這一榮譽一直保持到1930年,當時它被華爾街40號所超越。同年,克萊斯勒大廈率先成為世界上最高的建築,在1046英尺(319米)的高空划過。比它的高度更令人印象深刻的是該建築的設計,由威廉·凡·阿倫設計。克萊斯勒大廈是一個裝飾風藝術的傑作,其外觀由磚塊製成,至今仍是紐約人的最愛。

在二十世紀初,紐約市美學建築運動的中心,吸引了包括斯坦福·懷特、卡雷爾和黑斯廷斯等偉大建築師的人才。隨着本世紀的發展,更好的建築和工程技術的出現,紐約成為世界上最高建築競爭的焦點。這個城市的天際線由無數不同的摩天大樓組成,其中許多是二十世紀建築的標誌:
  • 熨斗大廈高285英尺(87米),在1902年竣工時是該市最高的建築之一,它的鋼製骨架使之成為可能。它是第一批用鋼架設計的建築之一,用當時的其它建築方法要達到這個高度是非常困難的。
  • 伍爾沃斯大樓是一座新哥德式的 "商業大教堂",俯瞰市政廳,由卡斯·吉爾伯特設計。它的高度為792英尺(241米),在1913年建成後成為世界上最高的建築,這一榮譽一直保持到1930年,當時它被華爾街40號所超越。
  • 同年,克萊斯勒大廈率先成為世界上最高的建築,在1046英尺(319米)的高空划過。比它的高度更令人印象深刻的是該建築的設計,由威廉·凡·阿倫設計。克萊斯勒大廈是一個裝飾風藝術的傑作,其外觀由磚塊製成,至今仍是紐約人的最愛。

作品列表和時間軸

個人或團體的作品列表,如書目、唱片、電影、專輯人員和曲目列表,通常以簡單的列表格式呈現,儘管預計這些信息將通過對要點的散文分析在條目的其它地方得到支持,如果列表變得難以處理,則按照WP:摘要格式將其拆分為獨立的列表。時間線和年表可以作為現實世界歷史的散文描述的有益補充。列表的內容受與散文相同的內容方針的約束,包括應有的比重避免原創研究的原則。根據維基百科的方針和指引(包括WP:TRIVIA部分),確保列表項目對主題的重要性與該項目在條目正文中的要求相同。考慮一下散文是否更合適。關於時間線的具體建議在Wikipedia:年表標準中給出。

相關條目(導航列表)

「參見」列表「相關條目」列表是寶貴的導航工具,可以幫助用戶找到相關的維基百科條目。當決定在任何給定的條目中添加哪些條目和條目列表時,試着把自己放在讀者的頭腦中是很有用的。問問自己,讀者在讀完這篇條目後可能想去哪裏。一般來說,這將包括三種類型的連結:

  • 相關主題的連結 - 與條目中討論的主題類似。
  • 高階(即,更大體的)條目和列表--這可能包括人的列表主權國家列表,等等。例如,印度語詩人列表應該同時連結到印度人列表和詩人列表。
  • 低階(即更具體)的條目和列表--例如,企業頁面導航列表包含小企業的連結,會計主題列表等。

對於在任何條目中應該放多少個條目連結和列表連結,存在一些爭議。有些人把「條目連結」(放在「參見」部分)和「列表連結」(放在「相關主題」部分)分開,但這是沒有必要的,除非有太多的連結需要單獨放在一個部分。有些人認為,在任何一篇文章的結尾,應該包括的列表連結的最佳數量是0、1或2。另一些人則認為,一套更全面的列表會很有用。一般來說,在決定包括什麼列表時,應該使用決定在「參見」部分包括什麼條目的相同標準。編輯應該試着把自己放在讀者的心態上,問「讀完這篇條目後我可能想去哪裏?」。一般來說,「參見」部分應重複出現在條目正文中的連結。

參考資料和外部連結

參考資料列表展示了維基百科之外的信息來源。兩種最常見的類型是:

  • 「網絡超連結」 - 在「外部連結」標題下的維基百科以外的網址連結列表
  • 「參考文獻」 - 在「參考資料」標題下的學術期刊文章或書籍列表

維基百科不是一個連結集,積極不鼓勵只有外部連結的條目,但從互聯網上引用更詳細的資料是合適的。當你把一個網站作為重要的信息來源時,情況更是如此。

列表的特殊名稱

維基百科上的大多數列表是項目列表,但不是全部。專門的列表類型包括:

  • 大綱 - 維基百科的大綱是一個分層排列的屬於某一特定主題的主題列表。大綱是維基百科上兩種類型的一般主題列表之一,另一種是索引。
  • 索引 - 維基百科上的索引是一個按字母順序排列的關於某一特定主題的文章列表。
  • 時間軸 - 時間軸是按時間順序排列的事件的圖形表示。
  • 作戰序列 - 武裝力量組成部分的代表,顯示了層級組織和指揮結構。
  • 作品列表包括書目唱片目錄。書目是一個主題領域的相關參考文獻列表,包括書籍、期刊文章和網絡文章;唱片目錄是一個音樂家或歌手的所有唱片的列表,也可以根據流派或唱片公司來編制。
  • 詞彙表 - 詞彙表是一個特定主題領域的術語列表,其中包括定義。
  • 同類索引條目 - 記錄一組共享相同(或相似)名稱的項目。它們與消除歧義的頁面不同,因為它們是完整的條目,旨在記錄多個主題,而消除歧義的頁面僅用於導航目的。並非所有的同類索引條目都是列表。
  • 動態列表 - 動態列表是任何隨着其涵蓋的主題變化而變化的列表。因此,它可能永遠不會被完成。任何類型的列表都可能是動態的。

列表的用途

列表有以下幾個用途:

提供資訊

列表可能是一個有價值的資料來源。對於結構化的列表來說,情況更是如此。這方面的例子包括按時間順序排列的列表,按主題分組的列表,或有註釋的列。

導航

包含內部連結術語(即維基連結)的列表總的來說可以作為維基百科的自然內容表和索引。如果用戶對他們要找的東西有一些大致的概念,但不知道具體的術語,他們可以瀏覽基本主題的列表和更全面的主題列表,這些列表反過來會通向維基百科的大部分(如果不是全部)列表,進而通向相關條目。沒有具體研究目標的用戶可能也會發現條目中的「參見」部分所列出的條目很有用。入口站點中也提供了列表,以幫助瀏覽他們的主題,而且列表通常通過使用系列框和其它導航模板放在條目中。

有特定研究目標(用一兩個詞描述)的用戶可能會發現維基百科的搜索框很有用。

發展

一些列表對維基百科的發展是很有用的。相關主題列表可以說明維基百科的狀況、已寫的條目和尚未寫的條目。然而,由於維基百科是為讀者而非編輯而優化的,任何主要為開發或維護目的而存在的列表(例如,一個完全由紅色連結組成的列表,並不具有信息目的;特別是一個缺失主題的列表)應該放在項目(「Wikipedia:」)或用戶(「User:」)命名空間,而不是主命名空間中。

列表和分類

列表和分類的冗餘是有益的,因為這兩種格式可以一起工作;這一原則在準則Wikipedia:分類、列表與導航模板中有所涉及。像分類一樣,列表可以使用鏈出更改功能來跟蹤所列頁面中的更改。與分類不同的是,列表還允許保留其內容的歷史;列表還允許在一個頁面上出現大量的條目。

列表命名

對於一個獨立的列表,列表的標題是頁面名稱。對於嵌入式列表,列表的標題通常是一個章節的標題(例如,超人前傳 (第一季)#各集列表),但它可以更短。列表的標題不應具有誤導性,通常不應包括縮寫詞。此外,過於精確的列表標題可能不那麼有用,而且會使列表難以找到;列表的精確收錄標準應該在標題部分(見下文)闡明,而不是在標題中闡明。例如,像「完整」和「顯著」這樣的詞通常不會出現在列表標題中。相反,標題應明確說明該名單是否完整,或者是否僅限於廣為人知或著名的成員(即那些值得發表的條目)。請注意,「著名」一詞被認為是一種不必要的宣傳點綴,不應使用。

列表佈局

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

傾向於散文,因為一段話很容易被理解為普通的文字。條目中首選散文,因為它可以介紹細節和澄清背景,而簡單的列表可能無法做到。它最適合於條目,因為其目的是解釋。

{{prose}}可以用來表明一個可能更適合寫成散文的列表。許多小作品條目可以通過將不必要的列錶轉換為百科全書式的散文而得到改進。參見:WP:格式手冊/瑣碎章節

散文與列表的區別示例
散文 沒有內容的列表
紐約市二十世紀的建築包括眾多的標誌性建築,最引人注目的是摩天大樓。在本世紀的頭幾十年裏,該市成為以建築師斯坦福·懷特、卡雷爾和黑斯廷斯為代表的美學運動的中心。紐約的新摩天大樓包括熨斗大廈(1902年),第五大道在麥迪遜廣場與百老匯交叉的地方;卡斯·吉爾伯特的伍爾沃斯大樓(1913年),一個俯瞰市政廳的新哥德式「商業大教堂」;克萊斯勒大廈(1929年),純粹的裝飾風藝術;以及帝國大廈(1931)。第二次世界大戰後,現代主義建築師雷蒙德·胡德和利華大樓開始建造一系列「玻璃盒子」,改變了20世紀30年代的經典天際線,最終在世界貿易中心大廈(1973年)達到頂峰。 紐約市二十世紀的建築

使用良好的標記

使用適當的標記:使用謹慎的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}}模板,以防止破壞圓點的縮進。

默認使用無序列表

默認情況下,使用帶圓點(無序)的列表,特別是對於長列表。只有在需要按編號引用項目、項目的順序很重要,或者在現實世界中存在編號的情況下(例如,專輯中的曲目),才使用編號(有序)的列表。

介紹性材料

列表中應該有介紹性材料;對於獨立列表,這應該是序言章節。這個介紹性材料應該清楚地說明該列表的範圍。它還應該為列表的非明顯特徵提供解釋,如列表的結構。獨立的列表可以將非顯而易見的特徵放在單獨的介紹部分。

列表和它們的輔助材料必須是中立的。對主題互補的獨立列表不應包含主題的內容。介紹性材料也應應該避免自我提及維基百科

有些信息,如「著名人物」或「校友」,可能是為了了解背景或細察內容而閱讀的,可根據大小,採用章節序言和描述性的、帶圓點的列表,或散文格式。如果名單很長,無法總結,但又不適合拆分,那麼,用一個章節序言,加上描述性的、帶圓點的列表,可能比長的散文部分更合適。

組織結構

儘管列表可以用不同的方式組織,但它們必須始終是有組織的。最基本的組織形式包括按字母或數字排列,但如果項目有特定的日期,有時最好是按時間順序排列(例如,白俄羅斯總理)。當使用更複雜的組織形式時,(按來源、按用途、按類型等),分類的標準必須明確和一致。就像讀者或編輯可以很容易地假定標題ABC後面是D(而不是1903)一樣,更複雜的系統也應該同樣明確。如果一份國際監獄中的澳大利亞人列表包含阿根廷柬埔寨的標題(按國家組織),那麼編輯加上非法毒品貿易的標題(按罪行組織)就不合適了。如果一個列表條目在邏輯上屬於兩個或更多的類別(例如,一個澳大利亞人因販毒而被關押在阿根廷監獄),這表明列表的分類可能存在缺陷,應該重新審查。

列表不應該包含「未分類」或「雜項」的標題,因為所有值得列入列表的項目都可按照某些標準分類,儘管完全有可能需要修改列表的格式以包括所有合適的項目。尚未分類的項目可以在確定其分類的時候列入列表的討論頁。

列表尺寸

就其目的和範圍而言,列表和表格應儘量簡短:列表中的資料應與條目的主題相關,而不涉及不必要的細節;統計數據應按方針保持在最低限度。

有些資料可能不適合摘要式方法來縮減或總結。一個嵌入式列表可能需要完全拆分到一個列表條目中,留下一個{{See}}模板,產生:

在某些情況下,列表格式可能比一個句子中的長序列更可取,比較:

散文 列表
哲學家們討論了提供定義的意義、功能和可能性。典型的做法是(例如,在大學的邏輯課本中)區分一些不同種類和技術的定義,包括字典或詞法定義、延伸性定義、外延性定義、實指定義、規定性定義操作定義理論性定義說服性定義以及從屬差異定義 哲學家們討論了提供定義的意義、功能和可能性。典型的做法是(例如,在大學的邏輯課本中)區分一些不同種類和技術的定義,包括:

向列表中添加單個項目

列表,無論是獨立列表(也稱為列表條目)還是嵌入式列表,都是百科全書式的內容,就像僅有段落的條目或章節那樣。因此,列表上的所有單項必須遵循維基百科的內容方針:核心內容方針可供查證(通過項目的一個或多個參考資料中的良好來源)、非原創研究中立的觀點,另外還有其它內容方針。如果內容包含四種絕對需要引用的材料中的任何一種,則應在其出現的地方用內文引用註明來源。雖然列表的格式可能對每個主題的細節要求較低,但維基百科的方針和程序同樣適用於類似事物的列表,以及列表中的單個事物可能被連結到的任何相關條目。


在添加或編輯列表中的項目時要大膽,但也要在大膽與周到之間取得平衡,所有的內容方針都是為了幫助編輯者實現這一平衡。對於質量不確定的編輯,可以先在討論頁上討論,以獲得其它編輯的反饋。

除了對這種反饋有用之外,討論頁討論也是一個很好的審查過程,可以在添加一個困難或有爭議的項目之前達成共識,特別是那些對主題本身的定義有爭議的項目。請注意,與本節提到的其它方針和程序一樣,這個過程可以用於維基百科上任何類型的困難或有爭議的百科全書式內容。

在編輯列表本身之前在討論頁上達成共識,不僅從長遠來看可以節省時間,而且有助於確保列表上的每一項內容都有很好的參考價值,而且列表整體上代表了中立的觀點。內容出現的地方要有來源,如果包含四種絕對需要有引證的材料,要提供內文引用

當一個項目符合可供查證方針的要求時,列表中的讀者可以檢查一個項目的參考資料,以了解該信息是否來自可靠的來源。對於信息的可供查證,也意味着維基百科不發佈原創研究:它的內容是由以前在一個好的來源中發佈的信息決定的,而不是其編輯的信念或經驗,甚至是編輯的解釋超出了來源的實際內容。即使你確定一個項目與列表的主題有關,你也必須在添加到列表之前找到一個良好的來源來驗證這一知識(儘管你可以在討論頁上建議),並在項目旁邊的參考資料中添加該來源。

在涉及生者的列表中,適用生者傳記的方針。

當可靠的消息來源出現分歧時,保持中立觀點的方針要求描述相互競爭的觀點,而不支持任何特定的觀點。編輯應該簡單地介紹各種消息來源的內容,根據所發表的可靠消息來源中每種觀點的突出程度來平衡報道,給予每一方應有的重視

當添加到一個有其它條目連結的獨立列表時,在添加你的項目時要遵循既定的格式,然後看看你是否能將該項目連結到關注該項目主題的條目。如果是這樣的話,就考慮列表的格式是否允許在列表項目中容納所有競爭性觀點的細節,或者這些細節是否只應該在連結的、關於該主題的主要條目中涉及。無論哪種方式,如果主條目中沒有這些內容,請確保將其添加到主條目中。

分類

你可以在包含一個可能具有獨立百科全書意義的列表的頁面底部,添加一個或多個合適的Category:列表子分類。如果有一個列表的重定向(例如,從「List of Presidents of Elbonia」到「President of Elbonia#List of Elbonian Presidents」),則將列表分類放在以「列表」命名的重定向上。

列表樣式

在維基百科上有幾種呈現列表的方式。

帶圓點的列表

這是維基百科上最常見的列表類型。列表中的每項內容通常是一個簡單的單詞、短語或單行文字,不適合用數字排序,或者是極其簡短的列表,在這種情況下,一眼就能看出這些內容不是問題。它們不適合於大段的文字。簡單的帶圓點的列表是通過在一行中以*開頭,然後添加列表項目的文本,每行*有一個項目來創建的。

列表項目的格式應一致。摘要:

  • 傾向於句子的情況。
  • 傾向於使用完整的句子,並避免將句子和片段混合作為同一列表中的項目。
  • 句子片段不使用結尾標點符號。
  • 列表項目之間不要放空行。
良好的示例
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(;)不應該被用來劃分大的章節。應使用副標題(例如,===副標題===)。

以散文和描述列表的形式比較內容
散文 列表


疾病是指任何損害正常功能的異常狀況,尤其是感染病,它是由致病微生物製劑的存在而導致的臨床明顯的疾病。病症通常是疾病的同義詞,除非用來特指病人對其疾病的個人體驗。醫療狀況是一個寬泛的術語,包括所有疾病和紊亂,但也可以包括可能影響個人健康、受益於醫療援助或對醫療有影響的創傷和正常健康狀況,如懷孕。

疾病
指任何損害正常功能的異常狀況,尤其是感染病,它是由致病微生物製劑的存在而導致的臨床明顯的疾病。
病症
通常是疾病的同義詞,除非用來特指病人對其疾病的個人體驗。
醫療狀況
一個寬泛的術語,包括所有疾病和紊亂,但也可以包括可能影響個人健康、受益於醫療援助或對醫療有影響的創傷和正常健康狀況,如懷孕。

表格

表格是一種以行和列形式呈現連結、數據或信息的方式。它們是一種複雜的列表形式,特別是當每個列表項感興趣的信息超過2條時,它們非常有用。表格需要一個更複雜的符號,應該仔細檢查其可及性。可以考慮合併散文中所涉及的信息的摺疊表。

表格可用於呈現數學數據,如乘法表、比較數字或體育成績。它們也可用於呈現兩種或更多語言的等價詞,用於按類型和年份劃分的獎項,以及複雜的唱片譜系。

水平列表

在諸如信息框的情況下,水平列表可能是有用的。示例:

做法 輸出 代碼
用逗號列出 事項 1,事項 2,事項 3 只是純文本
用{{Hlist}}列出
  • 事項 1
  • 事項 2
  • 事項 3
{{hlist|事项 1|事项 2|事项 3}}
用{{Flatlist}}列出
  • 事項 1
  • 事項 2
  • 事項 3

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

{{Flatlist}}的一個好處是,它可以被包裹在一個已經存在的帶圓點的列表中。{{Hlist}}的一個特點是,對於一個簡短的列表,它可以被放在一個單行上。

時間軸

對於日期事件的列表,或時間軸,每個事件使用一個{{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(日期優先)參數--日期格式在個別條目中應該是一致的)。

按時間順序排列的列表,如時間軸,應按從早到晚的時間順序排列。

換行

原始碼 效果
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早期被稱為關聯列表。