# Ordered vs Unordered List **URL:** \ **Category:** Spec\ **Created:** [December 24, 2015, 5:33am UTC](https://talk.commonmark.org/t/ordered-vs-unordered-list/1945 "2015-12-24T05:33:25Z")\ **Posts on this page:** 6\ **Page:** 2
**Author:** ![chrisalley](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/chrisalley/32/906_2.png) [@chrisalley](https://talk.commonmark.org/u/chrisalley)\ **Post date:** [January 2, 2016, 1:05pm UTC](https://talk.commonmark.org/t/ordered-vs-unordered-list/1945/21 "2016-01-02T13:05:32Z")
I think that whatever is decided should reflect the output more than the input. It is the intention of the writer which matters most - if the writer is intending to write a list, the writer is going to search the Help page with that intention in mind. Bullet lists imply a certain presentational output, as @Dmitry pointed out. Lists may be rendered without bullets, for example a list may be rendered a grid. The presentation of ordered and unordered lists can be completely swapped around too. Consider this CSS: ```css ol { list-style-type: disc; } ul { list-style-type: decimal; } ``` In this case, decimal numbers will show up in order next to the unordered list items, but this is purely presentational; the numbers don’t carry semantic meaning. Similarly, if the order of your list matters in any way, for example the intention that the “Home” list item in a navigation list should always appear first, then it’s arguably clearer to use an ordered list, styled without numbers if you don’t want these to be visible (e.g. `list-style-type: none`). ---
**Author:** ![tin-pot](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/tin-pot/32/810_2.png) [@tin-pot](https://talk.commonmark.org/u/tin-pot)\ **Post date:** [January 2, 2016, 3:58pm UTC](https://talk.commonmark.org/t/ordered-vs-unordered-list/1945/22 "2016-01-02T15:58:28Z")
Wow—21 posts already! The _[bike shed effect](http://tribune.com.pk/story/201969/the-bike-shed-effect/)_ seems to be in full flight … [And yes, I know I have my share in this 😉] * * * @chrisalley: I’m a bit confused by you stating whatever is decided should reflect the output more than the input and then going on to—correctly and instructively—pointing out that the _output rendering_ is completely out of the author’s hands. So I assume that should reflect the output does in fact mean _the parsing result_ (aka AST, aka _[CommonMark DTD](https://raw.githubusercontent.com/jgm/CommonMark/master/CommonMark.dtd)_ element structure). * * * With which I agree completely, and would thus prefer names which allude to the “two kinds of list” usually found in target document types like HTML, DocBook, “general document”, LATEX and so forth. So far I have only seen these alternative names in common use: 1. “unordered” and “ordered”: In the [ISO 8879 “general document”](https://www.cs.tut.fi/~jkorpela/sgml/general.html) and [HTML](https://www.scss.tcd.ie/misc/15445/15445.html#DTD) DTDs; 2. [“itemized”](http://docbook.org/tdg/en/html/itemizedlist.html) and [“ordered”](http://docbook.org/tdg/en/html/orderedlist.html): In [DocBook](http://docbook.org/tdg5/en/html/ch02.html#s.block); 3. “itemized” and “enumerated”: In [LATEX](https://en.wikibooks.org/wiki/LaTeX/List_Structures). In addition, one might take the following “prior art” into account; but I don’t make any claim of completeness for this collection of references. * * * In contrast to using two (or more) _element types_ for various kinds of lists, the [ANSI/NISO _Journal Article Tag Set_](http://jats.niso.org/) and the (related) [ISO _Standards Tag Set_ (ISOSTS)](http://www.iso.org/schema/isosts/v1.1/doc/index.html) both conflate the two kinds of list into a single element type, ``, and distinguish them using an attribute `list-type` with predefined values like `"order"`, `"alpha-lower"`, or “`bullet`” (sic!). The explanation for “`bullet`” however reads: > Unordered or bulleted list. Prefix character is a bullet, dash, or other symbol. So there: “unordered” again. 🙂 * * * And just for completeness: The [ISO 12083](http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=20866) _Electronic manuscript preparation and markup_ [DTD](http://xml.coverpages.org/iso12083xmlarticledtd19990125.html) seems to use the same approach when it comes to lists, but simply employs _numbers_ to indicate the “list type”, together with vague “suggestions” (but note the word “bullet” here again!): ``` ``` [Although the ATTLIST declaration for the `` element type does not declare the `type` attribute using NUMBER as the _declared value_, but references the above parameter entity as a _name token group_.] * * * And another one, this time from [ISO/IEC 26300-1:2015](http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66363), aka _[OASIS OpenDocument](http://opendocument.xml.org/overview)_: there’s only _one_ element type for list, unsurprisingly named `` (this is XML!). Pretty much all _rendering_ properties of such a list seem to be specified in an associated “list style”: > Lists may be numbered. The numbering may be restarted with a specific numbering at each list item. Lists may also continue numbering from other lists in order to merge lists into a single, discontinuous list. Whether list numbering is displayed or not depends on the list style being used. [ISO 26300-1:2015, clause 5.3.1] This “list style” is determined by the attribute `style:name` in ``, which may be missing. In this case, clause 5.3.2 gives the following advice: > If a list does not have a `style:name` attribute and therefore no list style is specified, one of the following actions is taken: > > - If the list is contained in another list, the list style defaults to the style of the surrounding list. > > - If there is no list style specified for the surrounding list, but the list contains paragraphs that have paragraph styles attached that specify a list style, that list style is used. > > - An implementation-dependent default is applied to the list. > > To determine which formatting properties are applied to a list, the list level and its style name are taken into account. 16.30. The “16.30” above refers to clause “16.30 ``”, which explains what kind of “style elements” the `` element may contain for each “list level”. — I’m too lazy to go into that. (Let alone to dig into _Microsoft_’s “Office Open XML” stuff …) * * * To conclude: it really is a mess, and it really does not matter much 😉 But if one _useful_ thing can be gleamed from these examples, it probably is the approach to use only **one** element type for lists, and to “customize” all list properties using attributes; and it seems that _newer_ document types tend to go into this direction. Note that this is also the approach taken in the _CommonMark_ DTD, which has a single `` element type. ---
**Author:** ![chrisalley](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/chrisalley/32/906_2.png) [@chrisalley](https://talk.commonmark.org/u/chrisalley)\ **Post date:** [January 3, 2016, 5:35am UTC](https://talk.commonmark.org/t/ordered-vs-unordered-list/1945/23 "2016-01-03T05:35:35Z")
> [@tin-pot](#): > > @chrisalley: I’m a bit confused by you stating whatever is decided should reflect the output more than the input and then going on to—correctly and instructively—pointing out that the output rendering is completely out of the author’s hands. So I assume that should reflect the output does in fact mean the parsing result (aka AST, aka CommonMark DTD element structure). My point is that once you take away the entirely mallable presentational aspects of the output (the default being a bulleted list in web browsers, in the case of unordered lists), we’re just left with the semantic structure - that could be HTML elements or some other format. So, the meaning behind that structure is what is important when describing it. The term “Unordered list” is suitable, I think, for describing such a structure, since the order of the list items is not important. If the order of the list is important in some way, it would be clearer markup to use an ordered list (even if, in practice, the order of unordered lists often is intended to have some relevance). ---
**Author:** ![tin-pot](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/tin-pot/32/810_2.png) [@tin-pot](https://talk.commonmark.org/u/tin-pot)\ **Post date:** [January 3, 2016, 10:04am UTC](https://talk.commonmark.org/t/ordered-vs-unordered-list/1945/24 "2016-01-03T10:04:15Z")
> [@chrisalley](#): > > My point is that once you take away the entirely mallable presentational aspects of the output (the default being a bulleted list in web browsers, in the case of unordered lists), we’re just left with the semantic structure - that could be HTML elements or some other format. So, the meaning behind that structure is what is important when describing it. I couldn’t agree more! > The term “Unordered list” is suitable, I think, for describing such a structure, since the order of the list items is not important. If the order of the list is important in some way, it would be clearer markup to use an ordered list (even if, in practice, the order of unordered lists often is intended to have some relevance). I’m not convinced that “unordered” and “ordered” list is the _best_ terminology, I’m just saying that it is the _usual_ terminology in the—fuzzy delineated—field of “structured document models”, mostly because of the `UL` and `OL` list _element types_ in (X)HTML (which date back, as I pointed out, a loooong time). Regarding the “semantic” difference between these two, and attempts to define them, the in my view most practical description I came about so far is from ISO/IEC/TR 9573:1988 (as I quoted [above](http://talk.commonmark.org/t/ordered-vs-unordered-list/1945/5) in my little historical excursion); it goes like this: > - “ordered” list, where there may be a need to refer to each item in the list. Typically the list items are numberred by the text-formatter. > > - “unordered” list, where there is no need to refer to any item in the list, but where each item should be clearly standing out. Typically the list items are indicated by bullets, stars, or dashes by the text-formatter. Note that there is no discussion whether the _order_ of items is important, or whether the “meaning” of the document changes should this order be _changed_ (as HTML5 does [in the description](http://www.w3.org/TR/html5/grouping-content.html#attr-ol-start) of `
    ` vs `
      `, which is IMO _very_ silly, to put it mildly). Talking about the “need to refer to each item” seems to be a suitable way to convey the difference between these two list types—after all, the _individual markers_ (ie, numerals) in front of the items in an “ordered” list provide the means to do so (one could say, it is their main purpose), and in a printed document without links to click on: the _only_ generally suitable way to refer to “each item in the list” (other than having the reader _count_ the items by himself when referring to “the 27th item in this unordered list” …). Note also that these descriptions only talk about presentations that are “typically” employed by a “text-formatter”, taking into account that these _element types_ do not or can not enforce a specific rendering. ---
      **Author:** ![Crissov](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/crissov/32/1455_2.png) [@Crissov](https://talk.commonmark.org/u/Crissov)\ **Post date:** [January 3, 2016, 11:00am UTC](https://talk.commonmark.org/t/ordered-vs-unordered-list/1945/25 "2016-01-03T11:00:41Z")
      If “referenceability” was the distinguishing feature, “ordered”/“unordered” would clearly not be the best labels. They’re the best labels if reordering does matter for one but not the other, as in HTML5 (although that semantic was probably informed by the preexisting names and mnemonics `ol`/`ul`). List items that can be referenced by a human reader need a visible and (at least locally) unique label. Most often this will be numeric (incl. alphabetic), because that’s easily automated, but explicit labels are also common, e.g. `\item[label]` in Latex. Many languages have a dedicated list type for that, e.g. `dl` in HTML. The mechanism is employed for more than list items, of course: formulas and equations, figures, tables, code listings, definitions, lemmas, theorems, examples (most of these frequently have a caption) and headings (which are basically captions for chapters and sections). Possible appropriate name pairs for the semantic distinction in ISO 9573, as quoted, would have been _labeled/unlabeled_, _named/anonymous_, _numbered/bullet_, _numbered/itemized_ etc. Anyhow, does that really teach us how to choose fitting names for the Commonmark specification? The output language is out of control of the spec. It can be as presentational or as structural as you can imagine. The only thing we know for sure is that (at least currently) one kind of list needs a number and a punctuation character (`)`/`.`) for each item, the other kind needs just a punctuation character (`-`/`+`/`*`). To an author, _numbered_ or _enumerated list_ would come natural for the first kind and the second kind could be a _unnumbered_, _itemized_ or _bullet list_. The final one applies if authors considered at least `+` and `*` ASCII approximations of a bullet character like `•` – Unicode also has `‣`, `◦` and `⁃`(!) bullets, so the hyphen `-` could probably be considered a “bullet” replacement character as well. There may be even better names in English that I’m not aware of. ---
      **Author:** ![tin-pot](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/tin-pot/32/810_2.png) [@tin-pot](https://talk.commonmark.org/u/tin-pot)\ **Post date:** [January 3, 2016, 11:39am UTC](https://talk.commonmark.org/t/ordered-vs-unordered-list/1945/26 "2016-01-03T11:39:34Z")
      > [@Crissov](#): > > Possible appropriate name pairs for the semantic distinction in ISO 9573, as quoted, would have been “labeled/unlabeled”, “named/anonymous”, “numbered/bullet”, “numbered/itemized” etc. Well, yes, maybe this _would have been_ more appropriate names. But somehow I see no point in second-guessing the commonly used terminology: and in practice, I have never seen “anonymous list” for example (and I think “labeled” or “unlabeled” or “named” list either). As I said, I don’t deem “ordered” and “unordered” the _best_ or even the _most appropriate_ names, but only pretty common _in the context at hand_, which is: “abstract” document structures in the parsed output. When it comes to—at least equally good—alternatives in “common use”, I have so far only seen “itemized” vs “enumerated” (like in LaTeX, but “itemized” is also used in DocBook); and these would be fine with me, too. But “bullet”, “named” (I’d rather keep _definition lists_ out of the discussion, as they aren’t available in _CommonMark_ anyway) and “numbered” are inferior terms IMO, primarily for their pretty strong _presentational_ connotations. > [@Crissov](#): > > Anyhow, does that really teach us how to choose fitting names for the _CommonMark_ specification? The output language is out of control of the spec. It can be as presentational or as structural as you can imagine. There we go! In my point of view, the “output language” in the _CommonMark_ specification is not just “out of control”, but is rather _lacking_: right now, all the examples show the result of converting the _CommonMark_ input into HTML—and for good reasons that I don’t deny: 1. Generating HTML **is** the most common use case for _CommonMark_, and 2. without doubt HTML **is** by far the most popular and well-known _document description language_, and 3. last not least has _Markdown_ **explicitly** been designed as a tool to generate HTML content. So including many examples of output HTML in the specification for instructional (or even: testing) purposes is certainly a good idea. However, and this is indeed my personal opinion or taste, and I don’t claim too much universal validity for it, however in my opinion a _specification_ should not _rely_ on examples, in the sense that the specification’s meaning should not change or vanish if some or all examples are removed from it. And this is clearly not the case with the _CommonMark_ specification as it is right now. To remedy this situation, the specification could describe the _parsed result_ (aka “AST”, aka “element structure”, aka “document model instance”) in a way _independent of any concrete “output language”_ (to nitpick, I would call the latter “output document type” in the case of XML output, or “output document format” in the general case, eg when converting to LaTeX or RTF). As far as I can see, the only _practical_ (and generally understandable) way to do so would be to refer to the _CommonMark_ DTD, with the understanding that it is **not** an XML-marked-up text what a _CommonMark_ processor is required to produce, but rather the “abstract content” of a _document instance_ of that DTD: as long as it produces information or an “information set” (which could well be just a sequence of implementation-defined callback invocation!) that is _equivalent_ to this “abstract content”, the processor is conforming. If this seems puzzling: there _are_ precise meanings of the terms “abstract content”, “document instance”, “information set”, and “equivalent”. [Previous page](https://talk.commonmark.org/t/ordered-vs-unordered-list/1945.md?page=1)