# Unicode Character 'BULLET' (U+2022) **URL:** \ **Category:** Uncategorized\ **Created:** [September 4, 2014, 11:46pm UTC](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397 "2014-09-04T23:46:12Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![instanceofme](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/instanceofme/32/185_2.png) [@instanceofme](https://talk.commonmark.org/u/instanceofme)\ **Post date:** [September 12, 2014, 4:25pm UTC](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397/21 "2014-09-12T16:25:48Z")
> [@Virtlink](#): > > Wouldn’t implementations need to understand the encoding to be able to parse a document at all? For example, UTF-16 is completely different from UTF-8. Even with single-byte character encodings I’m quite sure byte values below 128 (thus US-ASCII) are also used as part of byte sequences that are valid code points in other encodings. So, ignoring all encoding and treating all text as US-ASCII wouldn’t work. > > As implementations have to determine which encoding they’re reading, you might as well expect them to support UTF-8 (of all possible encodings), and therefore Unicode. Not necessarily. A simple parser that would match significant markers on ASCII chars and blindly output all other bytes would sill work fine with one-byte encodings like ISO-1559-\* and one-byte-or-non-ASCII encodings like UTF-8. Admittedly it won’t work with UTF-16, though. I’m just saying that including Unicode markers raises the bar for implementations. ---
**Author:** ![instanceofme](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/instanceofme/32/185_2.png) [@instanceofme](https://talk.commonmark.org/u/instanceofme)\ **Post date:** [September 12, 2014, 4:42pm UTC](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397/22 "2014-09-12T16:42:22Z")
> [@kagan](#): > > No. This is not a minor inconvinance. This is a major annoyance. One should not force the user to do anything at all just to prevent markdown from messing the text up as I have shown in my original example. Because text is not HTML, you have to make concessions, like requiring two spaces at the end of a line to get a line break, otherwise you cannot have a well-formatted text file OR you get line breaks every other sentence in the output. Markdown already works like this in almost all implementations, except for some that are not destined to be used with text files (e.g. embedded in an app or website). So when you say “it doesn’t [work]”, you mean that, like most markdown implementations today, it doesn’t work for this quite specific case of both using the `•` bullet and not wanting to append those two spaces. Consider the alternatives: 1. Loose the encoding-agnosticism – backward-incompatible in a major way plus lots of drawbacks 2. always breaking lines – backward-incompatible in a major way, loosing the ability to have clean text files I think not supporting `•` as a list item marker it is the lesser important annoyance. ---
**Author:** ![seantek](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/seantek/32/364_2.png) [@seantek](https://talk.commonmark.org/u/seantek)\ **Post date:** [September 12, 2014, 9:35pm UTC](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397/23 "2014-09-12T21:35:07Z")
Like instanceofme said: > [@instanceofme](#): > > like most markdown implementations today, it doesn’t work for this quite specific case CommonMark (as I understand it) is supposed to smooth out differences between all of the implementations out there, and smooth out the ambiguities in Gruber’s writeup. Its purpose is not necessarily to add new features. Regardless of the character set issue, it looks and smells like a new feature. ---
**Author:** ![kagan](https://cdn.commonmark.org/letter_avatar_proxy/v2/letter/k/50afbb/32.png) [@kagan](https://talk.commonmark.org/u/kagan)\ **Post date:** [September 13, 2014, 3:06pm UTC](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397/24 "2014-09-13T15:06:45Z")
> [@seantek](#): > > it looks and smells like a new feature. Fenced code blocks are old and list items are new? ---
**Author:** ![seantek](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/seantek/32/364_2.png) [@seantek](https://talk.commonmark.org/u/seantek)\ **Post date:** [September 13, 2014, 4:06pm UTC](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397/25 "2014-09-13T16:06:47Z")
No. With • (and the Unicode standard), yes. ---
**Author:** ![bjornte](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/bjornte/32/496_2.png) [@bjornte](https://talk.commonmark.org/u/bjornte)\ **Post date:** [December 17, 2014, 12:01pm UTC](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397/26 "2014-12-17T12:01:44Z")
Hi, I’m writing on an iPad, and here the «•» is readily accessible by long-pressing the «-» button. It requires fewer button presses than «\*» or «+». Here’s my list example: ## General to do • Continue sales • Better presentation material • Read e-mail to Ian • Read old draft business plan • Contact Dan Gøran • Ask Simen about mail It was written using the • character, using Notes in the iPad. This looks good in the preview here on the talk page, but bad in the dingus ([http://spec.commonmark.org/dingus.html](http://spec.commonmark.org/dingus.html)). The dingus makes it look like so: • Continue sales • Better presentation material • Read e-mail to Ian • Read old draft business plan • Contact Dan Gøran • Ask Simen about mail (Why the difference between the talk pages and the dingus?) ---
**Author:** ![JCSalomon](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/jcsalomon/32/381_2.png) [@JCSalomon](https://talk.commonmark.org/u/JCSalomon)\ **Post date:** [December 17, 2014, 4:37pm UTC](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397/27 "2014-12-17T16:37:31Z")
The difference is due to this site respecting arbitrary line-breaks; the dingus (and the Commonmark spec) concatenate adjacent lines into a single paragraph. (Note that though the list displays nicely here, it has not been translated into an HTML list.) ---
**Author:** ![jgm](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/jgm/32/1360_2.png) [@jgm](https://talk.commonmark.org/u/jgm)\ **Post date:** [December 17, 2014, 7:31pm UTC](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397/28 "2014-12-17T19:31:00Z")
See [https://github.com/jgm/CommonMark/pull/198](https://github.com/jgm/CommonMark/pull/198) Your point about the ease of typing a bullet on an iPad might count in favor of making this change. +++ Bjørn S Tennøe [Dec 17 14 12:12]: ---
**Author:** ![cirosantilli](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/cirosantilli/32/145_2.png) [@cirosantilli](https://talk.commonmark.org/u/cirosantilli)\ **Post date:** [December 19, 2014, 10:17am UTC](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397/29 "2014-12-19T10:17:06Z")
-1: There are already too many ways of making lists. This puts even greater burden on implementors and learning curve on end users. Like in programming languages, [it is better to have one single way to do things](https://www.python.org/dev/peps/pep-0020/). ---
**Author:** ![codinghorror](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/codinghorror/32/2_2.png) [@codinghorror](https://talk.commonmark.org/u/codinghorror)\ **Post date:** [December 19, 2014, 8:45pm UTC](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397/30 "2014-12-19T20:45:52Z")
No, I don’t agree @cirosantilli there are already so many ways to make lists: `* this is a list` `+ this is a list` `- this is a list` So why not unicode bullet? Seems rather safe and minor of a change to me and it would help real users I see doing this in the wild a fair bit. That’s the main thing I care about. The combination of “easy, minor” and “seen in the wild a lot.” I think we should include it @jgm . ---
**Author:** ![jgm](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/jgm/32/1360_2.png) [@jgm](https://talk.commonmark.org/u/jgm)\ **Post date:** [December 19, 2014, 10:53pm UTC](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397/31 "2014-12-19T22:53:39Z")
I think I am also in favor. Note that reStructuredText added unicode bullets a long time back: they allow `•`, `‣`, or `⁃`: Here is their mailing list discussion: [http://thread.gmane.org/gmane.text.docutils.user/2959/focus=2960](http://thread.gmane.org/gmane.text.docutils.user/2959/focus=2960) And their spec: [http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#bullet-lists](http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#bullet-lists) +++ Jeff Atwood [Dec 19 14 20:57]: ---
**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:** [December 19, 2014, 11:44pm UTC](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397/32 "2014-12-19T23:44:29Z")
Causal writers who do not know how to insert `•` may be confused when editing _someone else’s_ unicode bullet list. `*` `+` and `-` are all easily accessible from a standard keyboard. Pressing Option+8 on the Mac to insert an additional `•` list item is not intuitive. If the writer does not know the key combination then they must use copy/paste, search for how to insert `•`, or rewrite all of the existing list markers. No other Markdown syntax requires knowledge of key combinations (besides Shift of course). ---
**Author:** ![zzzzBov](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/zzzzbov/32/218_2.png) [@zzzzBov](https://talk.commonmark.org/u/zzzzBov)\ **Post date:** [December 24, 2014, 6:44am UTC](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397/33 "2014-12-24T06:44:49Z")
I’m still on the fence for this change. So I’ll voice my thoughts for and against, and see if anyone can sufficiently shoot them down. > [@codinghorror](#): > > **So why not unicode bullet?** Seems rather safe and minor of a change to me and it would help real users I see doing this in the wild a fair bit. (emphasis mine) 1. IIRC, all special characters in Markdown are in the ASCII range. Adding support for U+2022 would require that conforming implementations support unicode rather than ASCII, making the standard more restrictive. 2. Limited support from existing implementations. If they didn’t need it before, why do we need it now? 3. More divergence from the original markdown. 4. This particular change seems like it belongs in a unicode extension. Which could add **all** relevant unicode bullet characters to the list of acceptable characters, including (but not limited to): - • (U+2022) bullet - ‣ (U+2023) triangular bullet - ⁃ (U+2043) hyphen bullet - ⁌ (U+204C) black leftwards bullet - ⁍ (U+204D) black rightwards bullet - ∙ (U+2219) bullet operator - ◦ (U+25E6) white bullet Additionally, unicode numerals beyond `0-9` could be supported for numeric lists. **on the other hand** 1. “making the standard more restrictive” isn’t a strong argument. Unicode support isn’t particularly difficult when the character sets are well defined. 2. Many existing implementations don’t have support for fenced code blocks either, but utility was favored over popularity to reduce ambiguity. 3. Divergence from the original markdown is almost unavoidable, as the original is practically abandonware. If the original were to use semantic versioning, it’d be 1.0, and this would be the 2.0 spec due to the known API incompatibility. 4. Why go through all the extra effort to define the unicode alternatives to the core characters and then leave it up to implementors to choose whether or not they should implement an optional extension? Adding the unicode alternatives to core could help to make markdown more portable between conforming implementations. ---
**Author:** ![Knagis](https://cdn.commonmark.org/letter_avatar_proxy/v2/letter/k/ba9def/32.png) [@Knagis](https://talk.commonmark.org/u/Knagis)\ **Post date:** [December 24, 2014, 7:57pm UTC](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397/34 "2014-12-24T19:57:34Z")
> [@zzzzBov](#): > > IIRC, all special characters in Markdown are in the ASCII range. Adding support for U+2022 would require that conforming implementations support unicode rather than ASCII, making the standard more restrictive. Just wanted to note that this is not a valid point. There are two cases - either the particular implementation supports some kind of Unicode text encoding (like the C reference implementation supports UTF-8) or not (where it supports only ASCII). - If the supports just ASCII then there is no problem since the input data cannot contain a Unicode bullet char. - If it supports Unicode then the change to support this is trivial (as shown by the pull request). Also note that the specification already contain tests that verify correct handling of Unicode characters (for url-encoding and tab expansion). ---
**Author:** ![lu\_zero](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/lu_zero/32/557_2.png) [@lu\_zero](https://talk.commonmark.org/u/lu_zero)\ **Post date:** [December 26, 2014, 2:06am UTC](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397/35 "2014-12-26T02:06:07Z")
Would be nice to support all the possible bullet points then, willing to update the patch accordingly? ---
**Author:** ![Brian\_Lalonde](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/brian_lalonde/32/1565_2.png) [@Brian\_Lalonde](https://talk.commonmark.org/u/Brian_Lalonde)\ **Post date:** [December 31, 2014, 6:34pm UTC](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397/36 "2014-12-31T18:34:13Z")
Common “in the wild” use case: Bullets are often generated when pasting text out of certain popular word processing programs. WRT the awkwardness of input: Mobile OS (tablets, initially) soft keyboards will increasingly be used for Markdown. It’s fewer keystrokes. See [http://www.emojitracker.com/](http://www.emojitracker.com/) to address any concern about popularity of characters not appearing on hardware keyboards. 😉 ---
**Author:** ![lu\_zero](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/lu_zero/32/557_2.png) [@lu\_zero](https://talk.commonmark.org/u/lu_zero)\ **Post date:** [January 1, 2015, 3:25pm UTC](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397/37 "2015-01-01T15:25:47Z")
See above for a list of possible bullets. ---
**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, 2015, 12:13pm UTC](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397/38 "2015-01-03T12:13:19Z")
[quote=“Brian\_Lalonde, post:36, topic:397”] WRT the awkwardness of input: Mobile OS (tablets, initially) soft keyboards will increasingly be used for Markdown. It’s fewer keystrokes.[/quote] It’s true that use of software keyboards is increasing. Hardware keyboards aren’t going anywhere though. For serious writing, hardware keyboards remain an important option. > [@Brian\_Lalonde](#): > > See [http://www.emojitracker.com/](http://www.emojitracker.com/) to address any concern about popularity of characters not appearing on hardware keyboards. 😉 I had a look at that site. Can you explain how it addresses [the issue I raised earlier](http://talk.commonmark.org/t/unicode-character-bullet-u-2022/397/32) regarding appending list items to other people’s unicode lists? ---
**Author:** ![Brian\_Lalonde](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/brian_lalonde/32/1565_2.png) [@Brian\_Lalonde](https://talk.commonmark.org/u/Brian_Lalonde)\ **Post date:** [January 5, 2015, 5:20am UTC](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397/39 "2015-01-05T05:20:19Z")
> Can you explain how it addresses the issue I raised earlier regarding appending list items to other people’s unicode lists? “Confused” seems like a broad assessment based solely on a very specific presumed configuration of ignorances, I guess. I’d expect someone editing a document with bullet characters to either copy and paste them if they felt insecure about the format, or else replace them with their favorite Markdown bullet characters. ---
**Author:** ![vitaly](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/vitaly/32/396_2.png) [@vitaly](https://talk.commonmark.org/u/vitaly)\ **Post date:** [January 5, 2015, 6:31am UTC](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397/40 "2015-01-05T06:31:45Z")
+1 for extending markers list. [Previous page](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397.md?page=1) [Next page](https://talk.commonmark.org/t/unicode-character-bullet-u-2022/397.md?page=3)