How can I help this feature request move forward?
I remember reading somewhere that the CommonMark specification is frozen in the sense that no new features will be added, but I cannot find any official announcement or discussion. Frozen or not, there are three people listed as making decisions as of now — John, Martin and Jeff. This is not a big committee. Thee people can agree on a feature.
why are description lists needed
the feature is orthogonal to existing features
Description lists are the way to denote finite maps from strings to strings. What is life if you cannot denote a finite map?
I can think of other ways to denote such finite maps, but they are contrived. For example, say we have a finite set {dog; cat; rat; mouse} of labels. We can define a canonical enumeration of this set — a one to one function onto the first few natural numbers:
- dog
- cat
- rat
- mouse
Now we can write a finite map from these canonical numerical identifiers.
- likes to run about
- likes to sleep
- likes to scamper
- likes to scamper
The latter can be composed after the inverse of the former in the evident way to get the desired map from {dog; cat; rat; mouse} to favourite behaviour. For example, rat is 2 and 2 is likes to scamper. But I await the reader will agree that this is absurd. So are all other alternative representations I can think of.
the feature is not going to be supported at large until it is supported in the CommonMark standard
You wanted to be a standard — you succeeded, congratulations. Now people will hide behind your authority when you ask features of them. See example.
why the current de facto standard is just fine
-
There is historical precedent. I believe Merriam Webster dictionaries were using colons to introduce bodies of definitions since time immemorial. Here is how it looks on their web site:
Though I admit the Merriam Webster syntax is way more complicated and will not line up with markdown exactly, this is still in principle a precedent, and it is widely accepted.
-
It has been battle tested for years in Pandoc and other implementations — everything works. One can even denote nested description lists by indenting with 4 spaces or a tab character.
-
The complexity of backtracking is not an insurmountable problem. Practically, no one is going to be defining a million topics to one definition — this is not a use case of Markdown. A security conscious parser will simply limit the number of topics allowed — for example, if it sees 100 lines in a row it can assume no definition will be forthcoming. This is what, for example, HTTP clients and servers already do — if you try to give an infinite stream of data to a security conscious HTTP program it will cut you off at some point. At the time of writing, Pandoc limits the number of topics allowed to 1.
Yes, there may be better syntax eventually. But there is good enough syntax now.
what I should like to happen
I hope someone who makes decisions in CommonMark will actually see this message and give it a moment’s thought.
- If this will never be a part of CommonMark then say it, let people know that there is no hope.
- If something needs to be done — writing, testing — tell us. Maybe I can help, maybe someone else will be interested. There are a lot of people that want this to happen.