# Mixed-marker bullet lists **URL:** \ **Category:** Extensions\ **Created:** [January 2, 2016, 11:16am UTC](https://talk.commonmark.org/t/mixed-marker-bullet-lists/1952 "2016-01-02T11:16:15Z")\ **Posts on this page:** 17\ **Page:** 1
**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 2, 2016, 11:16am UTC](https://talk.commonmark.org/t/mixed-marker-bullet-lists/1952/1 "2016-01-02T11:16:15Z")
Although [most current markdown implementations](http://johnmacfarlane.net/babelmark2/?normalize=1&text=-+Apples%0A*+Oranges%0A%2B+Bananas) allow arbitrary mixes of the supported list markers `-`, `*` and `+` to generate a single uniform list in the output, the[Commonmark specification](http://spec.commonmark.org/0.23/#list-items) now requires that each change in marker starts a new list: > A **list** is a sequence of one or more list items of the same type. (…) > > Two list items are **of the same type** if they begin with a list marker of the same type. > Two list markers are of the same type if > (a) they are bullet list markers using the same character (`-`, `+`, or `*`) or > (b) they are ordered list numbers with the same delimiter (either `.` or `)`). (Please note that some implementations do weird things: Cebe treats a change in list item marker as a new _nested_ list and Gambas uses plus `+` for _ordered_ lists.) I believe there are some valid, existing use cases of mixed-marker lists. Supporting these would require a slight change in philosophy: Lists that **mix the bullet types** are considered to associate special meaning with them. If all three markers are being used, the list can be treated like a **change log** or diff. Empty items are ignored except that they take part in determining the kind of list. Plus `+` designates a new feature, minus `-` a removed or deprecated one and asterisk `*` is for general informational changes. It’s a matter of philosophy whether bug fixes belong into the `-` or `*` category. These conventions are followed more or less by many plain-text change logs already, even if they do not use markdown explicitly. ```auto + New feature, addition - Deprecated feature, removal, (bug fix) * Other change, informational, (bug fix) ``` If only plus `+` and hyphen-minus `-` are mixed, the list is treated as a comparison of **pros and cons**. As you can see below, the code highlighter used here recognizes that convention (because it auto-guesses the code to be a diff, not markdown): ```auto + Pro - Con ``` If hyphen `-` is mixed with asterisk `*`, this makes an **agenda** , i.e. a to-do, shopping or task list. The hyphen `-` introduces unfinished entries (“open”), the asterisk `*` ones that already have been ticked off (“closed”). Most existing flavors that support something like this use different syntax with square brackets `[+]` or parentheses `( )` to mock checkboxes and radio buttons. ```auto * breakfast - lunch - supper ``` If we anticipated an extension to support such advanced lists, would it be better to keep the current phrasing of the spec to make separate lists or would the universal existing practice of making it a single list be better suited? ---
**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, 4:15pm UTC](https://talk.commonmark.org/t/mixed-marker-bullet-lists/1952/2 "2016-01-02T16:15:30Z")
I do agree that the _CommonMark_ rule, that is “splitting” the list whenever the marker character used in the input text varies, seems a bit arbitrary—and non-portable. If _two_ adjacent, unordered (or “bullet”) lists are really what is wanted, maybe an intervening _comment declaration_ could be used to mark up the splitting point. However, I’d even prefer to require an intervening _paragraph_, since adjacent lists feel somewhat “degenerate”, and I think they aren’t even possible in some document formats. (The “splitting” paragraph could be empty in any case, making the _kludge_ character of the adjacent lists more visible, while increasing the chance that this can be mapped into a wider variety of target document formats.) The _CommonMark_ text for two such lists would then look like this: ``` * breakfast - lunch - supper

+ spring - summer * autumn ``` Alternatively, use a _comment declaration_ like `` in place of the empty `

` element, or maybe even a `
` would do. Using _comment declarations_ in _CommonMark_ text for purposes like this would be much nicer if an _empty_ comment `` were available1), but that’s not covered by the current _CommonMark_ rules … \_\_\_\_\_\_ 1. The syntax “``” is defined in SGML, but not in XML or HTML; which does not matter or is even fortunate, because `` would be “used up” by the _CommonMark_ processor and never occur in the parsed result. * * * Furthermore, to convey the “meaning” of using different marker characters in your proposal, the _CommonMark_ `` element (into which every list item is parsed) would need some attribute to hold the marker string, like this (currently `` has _no_ attributes at all): ``` ``` So the “`+`”, “`-`”, “`*`” characters in your example would be represented in this `marker` attribute, ready for an application to base decisions on it. ---

**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 2, 2016, 4:39pm UTC](https://talk.commonmark.org/t/mixed-marker-bullet-lists/1952/3 "2016-01-02T16:39:30Z")
Two consecutive blank lines would split two adjacent lists already, so no empty comment or paragraph needed. ---
**Author:** ![Dmitry](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/dmitry/32/849_2.png) [@Dmitry](https://talk.commonmark.org/u/Dmitry)\ **Post date:** [January 2, 2016, 5:06pm UTC](https://talk.commonmark.org/t/mixed-marker-bullet-lists/1952/4 "2016-01-02T17:06:36Z")
Cancelling the two blanks rule has been [suggested](http://talk.commonmark.org/t/reconsidering-two-blank-lines-breaks-out-of-lists/934/1) (on the grounds of different markers breaking a list, no less), and a “list break” syntax has been [proposed](http://talk.commonmark.org/t/reconsidering-two-blank-lines-breaks-out-of-lists/934/10), which would be consistent with hard line breaks: ```auto Two lists: 1. item 2. item \ 1. item 2. item ``` (although those are ordered lists, the particular list type is unimportant). > [@tin-pot](#): > > ```auto > marker CDATA #IMPLIED > > > > ``` [CommonMark.NET](http://CommonMark.NET) already holds these (as well as other) data as part of the syntax tree and its (non-XML ATM) AST format. ---
**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, 5:20pm UTC](https://talk.commonmark.org/t/mixed-marker-bullet-lists/1952/5 "2016-01-02T17:20:01Z")
One more reason to ditch the “changing marker character implies splitting the list” rule in _CommonMark_, I would say. (I’m not too fond of the “two blank lines split the list” rule either, but so be it.) ---
**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, 5:23pm UTC](https://talk.commonmark.org/t/mixed-marker-bullet-lists/1952/6 "2016-01-02T17:23:51Z")
Good to know. Do you know the “attribute name” (or whatever it is called in “non-XML ATM”) for the corresponding data element? Is it “`marker`” already? Does it hold a single character, or a Unicode string, or something else? So that **if** this gets added to the _CommonMark_ `` element, it can at least be done consistently. ---
**Author:** ![Dmitry](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/dmitry/32/849_2.png) [@Dmitry](https://talk.commonmark.org/u/Dmitry)\ **Post date:** [January 2, 2016, 6:05pm UTC](https://talk.commonmark.org/t/mixed-marker-bullet-lists/1952/7 "2016-01-02T18:05:36Z")
This is currently part of the `list` elment, not `item` element, so I see no way of it being forwards-compatible with “mixed-marker bullet lists”. The format is text (although I suppose it could be formalized as SGML), and a “bullet list” node has the form ``` list (type=bullet tight={0} bullet_char={1}) ``` where - `{0}` is replaced with either `True` or `False` and - `{1}` is replaced with a code point. ---
**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, 6:16pm UTC](https://talk.commonmark.org/t/mixed-marker-bullet-lists/1952/8 "2016-01-02T18:16:58Z")
Thank you for the information! This looks indeed quite like the [current definition](https://github.com/jgm/CommonMark/blob/master/CommonMark.dtd#L16) of the _CommonMark_ `` element: ``` ``` Regarding “mixed-marker bullet lists”, the only kind-of “forwards-compatible” way to have “mixed” markers transmitted I can come up with is again using an attribute _per item_, eg in the _CommonMark_ `` element, like my `marker` attribute above. This could be declared `#IMPLIED`, and only explicitly output by the _CommonMark_ processor if the marker character (or string) and hence the `marker` attribute value _differs_ from the one in the _first element_ in the list (which is, I suppose, what ends up being the `bullet_char` value?), in other words: if it differs from the value of `bullet_char` (rsp `delimiter` attribute) in the `` element. ---
**Author:** ![Dmitry](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/dmitry/32/849_2.png) [@Dmitry](https://talk.commonmark.org/u/Dmitry)\ **Post date:** [January 2, 2016, 7:01pm UTC](https://talk.commonmark.org/t/mixed-marker-bullet-lists/1952/9 "2016-01-02T19:01:22Z")
`delimiter` isn’t quite the same, since it can only be `period` or `paren` (so adding support for e.g. `(1)` lists would require adding a new value). `start` and `delimiter` are both `#IMPLIED` since `start` is present iff `type == ordered` and `delimiter` is present iff `type == bullet`. It would be much better IMO to have two separate list elements (or three, if definition lists are to be accounted for). Changing `bullet_char` to `marker` might be a good idea. A similar attribute could be present in a definition list, where `:` or `~` would serve as definition markers. BTW should `~ definition2` after `: definiton1` start a new list? ---
**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, 7:50pm UTC](https://talk.commonmark.org/t/mixed-marker-bullet-lists/1952/10 "2016-01-02T19:50:16Z")
> [@Dmitry](#): > > delimiter isn’t quite the same, since it can only be period or paren (so adding support for e.g. (1) lists would require adding a new value). Yes and no: the `delimiter (period | paren) #IMPLIED` declaration makes (more or less) sense in the current DTD, as it is only used in “ordered” lists, and these can only use these two alternatives (at least in the current _CommonMark_ syntax). * * * > It would be much better IMO to have two separate list elements (or three, if definition lists are to be accounted for). I’m not sure about that (we _do_ still talk about the elements defined in the _CommonMark_ DTD, do we?). The “one ``, various attributes” approach is in fact somewhat more flexible and easier to extend (putting the “marker string” into an `marker` attribute is an example of this!). This “dichotomy” between _elements_ and _attributes_ is very common design problem, and in the exact context of these two approaches to define list elements (ie multiple _element types_ vs _discerning attributes_) this is discussed in some depth in [ISO/IEC/TR 9573:1988](http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=17319) (see _how old_ these questions are!). Let me—assuming this is “fair use”—quote from the pertaining section [the “first approach” here means the one with multiple element types for lists, the second being the use of attributes]: > **4.2.3.3 Discussion of the two approaches to lists** > > The first design approach has the advantage of fewer keystrokes, and may be appropriate in a very well-defined or bounded application. The second approach is more suited to general, or evolving, applications: > > - Treating the attributes of the lists as true SGML attributes gives flexibility. For example, if one were to provide the option of a glossary in which the items were numbered, then the markup: > > - If a document is being edited without the aid of an SGML syntax-directed editing system […] > > On the other hand this approach implies that in implementing an SGML syntax-directed editing system it is not sufficient to use the DTD to “prompt” and verify valid sub-elements, since certain combinations of attributes imply that only a subset of the sub-elements permitted by the DTD are actually valid. In a `` element only the `
  • ` sub-elements are valid whereas the DTD also permits `` [_for “list term” – tin-pot_] sub-elements to occur. Without going into much detail here, I think it is obvious that _CommonMark_ falls squarely into the more suited to general, or evolving, applications camp, and saving keystrokes is pretty irrelevant in _parser-generated XML output_ … * * * The character (or string?) in the “bullet” role in an (item of an) “unordered” list would go into two places: 1. In an attribute of the `` element (which—you’re right—should probably **not** be a redefined `delimiter`, not the least because a “`+`” marker is not a “delimiter”); 2. In an attribute of each `` in the list. It seems to me quite reasonable to use the same name, and the same declared value, for this attribute, like so: ``` ``` So a “missing” `marker` attribute value specification in an `` element could be “inherited” from the value given in the enclosing `` element; and vice versa if the `` element _does_ have a value specified for `marker`, this would “override” the value given in the enclosing ``. * * * > [@Dmitry](#): > > A similar attribute could be present in a definition list, where : or ~ would serve as definition markers. _Definition list_? Did I miss something and _CommonMark_ suddenly has _definition lists_—would be great! ---
    **Author:** ![Dmitry](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/dmitry/32/849_2.png) [@Dmitry](https://talk.commonmark.org/u/Dmitry)\ **Post date:** [January 2, 2016, 9:04pm UTC](https://talk.commonmark.org/t/mixed-marker-bullet-lists/1952/11 "2016-01-02T21:04:37Z")
    > [@tin-pot](#): > > `` I’d suggest ``` ``` Since the processing agent would be required to inspect the `list` marker anyway, `marker` should be required for unordered lists and for list items of both types (numerals normally serve as markers in ordered lists). I believe OOD wan’t very popular back in 1988. In 2016 an abstract `list` type along with `ordered_list` and `unordered_list` specializations seems more fitting IMO. > [@tin-pot](#): > > Definition list? Did I miss something and CommonMark suddenly has definition lists—would be great! CommonMark doesn’t, but hopefully [CommonMark.NET](http://CommonMark.NET) will soon. Had it had a DTD, that would need to be extended to ``` ``` ---
    **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, 9:21pm UTC](https://talk.commonmark.org/t/mixed-marker-bullet-lists/1952/12 "2016-01-02T21:21:02Z")
    > [@Dmitry](#): > > ``` > > ``` > > Since the processing agent would be required to inspect the list marker anyway, marker should be required for unordered lists and for list items of both types (numerals normally serve as markers in ordered lists). Well, there **is** no `unordered_list` in _CommonMark_, at least right now. And as tried to convince you, there probably **should** not, but instead only one `` element type. You mean providing in the `marker` attribute of the `` and/or `` element - either the “bullet” character, ie “`-`”, “`+`”, “`*`”, etc (in “unordered” `` and `` elements); - or the “number style” or “picture” or “format” (resembling old HTML use), ie “`1.`”, “`a.`”, “`1)`”, “`a)`” in ``, and - the same, but with `1` or `a` replaced by the appropriate numeral in the value specified for `marker` in `` attributes. That’s a whole lot of changes here … * * * > I believe OOD wasn’t very popular back in 1988. I guess you weren’t around back then: it was _the_ new and hot topic in programming languages, AFAIR. > In 2016 an abstract list type along with ordered\_list and unordered\_list specializations seems more fitting IMO. Whatever jargon floats your boat (in “_[CommonMark.NET](http://CommonMark.NET)_”)—but XML it ain’t. And certainly the _current year_ is the last thing a specification is supposed to fit to, IMO. [And you _do_ know that OO models with classes can well and cleanly be defined _extensional_ rather than _nominal_, do you? That was even the case back then in the 80ies!] ---
    **Author:** ![Dmitry](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/dmitry/32/849_2.png) [@Dmitry](https://talk.commonmark.org/u/Dmitry)\ **Post date:** [January 2, 2016, 9:52pm UTC](https://talk.commonmark.org/t/mixed-marker-bullet-lists/1952/13 "2016-01-02T21:52:17Z")
    1. I don’t own [CommonMark.NET](http://CommonMark.NET); I’m a mere contributor. 2. [CommonMark.NET](http://CommonMark.NET) is **not** object-oriented in its current state (although I _am_ working on changing that). 3. The first OOP language was [Simula 67](https://en.wikipedia.org/wiki/Simula). Guess what 67 stood for. 4. “new and hot topic in programming languages” does not directly translate into specifications (quite the opposite, unfortunately). 5. This is an _ordered list_, which is a specialization of _list_, which is a specialization of _block_, which is a specialization of _element_. ---
    **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, 10:03pm UTC](https://talk.commonmark.org/t/mixed-marker-bullet-lists/1952/14 "2016-01-02T22:03:51Z")
    @Dmitry: Oh, come on … Is this really neccessary? > 1. I don’t own [CommonMark.NET](http://CommonMark.NET); I’m a mere contributor. Yes, fine. I didn’t state or imply otherwise, as far as I can tell. > 2. [CommonMark.NET](http://CommonMark.NET) is not object-oriented in its current state (although I am working on changing that). Okay, good for you (and probably _[CommonMark.NET](http://CommonMark.NET)_!) > 3. The first OOP language was Simula 67. Guess what 67 stood for. Wow, I’d never known about _Simula_ without your help, thank you so much! [Not, obviously.] And this has _what_ to do with “mixed-marker bullet lists” again? > 4. “new and hot topic in programming languages” does not directly translate into specifications (quite the opposite, unfortunately). I agree, and I’d even say that **nothing** translates directly into specifications, for otherwise no specification would be needed. [Kidding aside, I’m not sure what you mean by this assertion anyway.] > 5. This is an _ordered list_, which is a specialization of _list_, which is a specialization of _block_, which is a specialization of _element_. Ehem: there **is** no `block` which is a specialization of `element`, at least not in _CommonMark_ (not in the specification, and not in the DTD). There is no `ordered list` element either, but I think I get what you mean. If you’d now be so kind and _define_ what you mean by “specialization” (it must be a relation between _element types_ from your use of the word, but which one?) in the given context, namely _elements_ in a document content model? _Liskov-substitutable_ maybe? A _projection/embedding_ pair? ---
    **Author:** ![Dmitry](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/dmitry/32/849_2.png) [@Dmitry](https://talk.commonmark.org/u/Dmitry)\ **Post date:** [January 2, 2016, 10:26pm UTC](https://talk.commonmark.org/t/mixed-marker-bullet-lists/1952/15 "2016-01-02T22:26:59Z")
    > [@tin-pot](#): > > Is this really neccessary? No. I wish there weren’t a post length minimum. ---
    **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, 10:37pm UTC](https://talk.commonmark.org/t/mixed-marker-bullet-lists/1952/16 "2016-01-02T22:37:45Z")
    > [@Dmitry](#): > > I believe OOD wan’t very popular back in 1988. In 2016 an abstract list type along with ordered\_list and unordered\_list specializations seems more fitting IMO. When I first answered to your remark, it didn’t occur to me that you were probably trying to make fun of me quoting from a TR published in (gasp!) 1988, discussing a question concerning document model design in the context of (horrors!) SGML. If that’s the case: no offense taken, but let me be clear about my position in this matter: When it comes to _document description languages_—and all of the discussion topics around here fall under this umbrella, or do you think otherwise?—when it comes to topics in this area there are some people, with names like Charles Goldfarb, James Clark, Norman Walsh, Tim Bray (to name a few), whose texts and comments I tend to take rather seriously; for the simple reason that they have much more experience and insight into this field than I have or I’m pretty sure any of us here has. Now comes the twist: some of these people were actually alive “back then”, and had _in the year 1988_ already several years, if not _decades_, of experience with precisely the design decisions discussed in TR 9573 [I do not _know_, but I would bet that Goldfarb had his hand in authoring it, btw]. I don’t know about your age, or background and experience in the subject at hand. But let me just say that a comment like yours above does not reflect favorably on any of those; it rather makes you look as if you just barely learned a fashionable concept and now go around throwing it at every problem at hand. Which is **not** something to be ashamed of (we all did it some time or the other), but it is **not** a license or valid reason to feel automatically above all knowledge and insight accumulated by others. * * * Back to somewhat more concrete topics: throwing “.NET” and “OOD” jargon around is all nice and dandy, but the goal here is a _specification_ (as you seem to realize in one or your enumerated remarks) on how some textual input is transformed into some “structured” output. The latter concept is, to my regret, only defined in a rather fuzzy way (as “the AST”, being more or less equivalent to a _type-valid_ XML document instance conforming to the _CommonMark_ DTD, as far as I can tell). So if you have anything to contribute in _this area_, maybe a formal, simple, abstract, object-oriented meta-model for the element structure of said output, go ahead: I’d very much welcome it. But don’t forget to specify the mapping into XML (or rather: XML Infoset). ---
    **Author:** ![rokejulianlockhart](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/rokejulianlockhart/32/3399_2.png) [@rokejulianlockhart](https://talk.commonmark.org/u/rokejulianlockhart)\ **Post date:** [May 1, 2026, 7:36pm UTC](https://talk.commonmark.org/t/mixed-marker-bullet-lists/1952/17 "2026-05-01T19:36:46Z")
    > [@Crissov](#): > > `( )` to mock checkboxes and radio buttons. @Crissov, that is a very popular sentiment: > **[talk.commonmark.org/t/1952/17 - Radio buttons support · community · Discussion...](https://github.com/orgs/community/discussions/4318#discussioncomment-16783426)** > > I can see a great integration with checkboxes. Thanks for that! Is it possible to add new support for Radio buttons? The main motivation is a different context. On checkboxes, we want to finish all... Is this worth a a separate topic?