Hello - this is my first post on this forum. The commonmark website asks for feedback, and I have been advised that this forum is the right place to bring that. I am writing, as a user, because I have noticed some things in an implementation of markdown that could have a bearing on the markdown spec.
I have just seen this notice >> Please note the CommonMark spec is currently frozen with respect to features, but there are supersets of or extensible implementations of CommonMark that may support what you need. <<
Given the notice, I am not sure how to categorise this post, so I am putting the whole thing down here, and asking if a moderator could guide me as to how/where to categorise and/or retitle the post. I am also unsure how much of what I am looking for will be specific to the actual implementation, and how much will be relevant to the spec itself, a superset, or an extension. That having been noted, here goes …
I am not a coder, and yet I am using, with some success, a program called Obsidian - that has been my main introduction to markdown. I have no idea how faithfully Obsidian meets the commonmark spec - this page here Obsidian Flavored Markdown - Obsidian Help notes the Obsidian approach. My view on the biggest weaknesses of that program from a user perspective seems to go back to the markdown spec itself, and for that reason I am writing to you as custodians of the markdown spec, to see if you can see your way to expanding the specification to take these points into account.
- The limited granularity of anchor points. I, in common with many others, like to link into Obsidian documents both from other documents in Obsidian and from URLs stored in other programs. Referring to a heading # is OK. Referring to a block of text (see the information in the linked to page above) seems to be non-standard, and a bit of a kludge. Referring to paragraphs, sentences, and individual words or even individual letters, is not possible, drastically cutting the functionality of the program. I would very much appreciate if you can apply your combined brain power to working out how this should be done by means of the markdown standard. This is a very well known issue. Linking to a folder containing documents would also be very useful.
- Indenting text in a viewed document. The only way to indent text to form an outline seems to be to use bullet points or numbers underneath headings. Thinking through the structure of a document to add headings before you write it is a high friction way of working, and I would like to see a way of writing text and changing the indent structure in a much more organic way.
- The use of color. < mark style=“background: hexcode;”>highlightedtexthere < /mark> (note - remove space following each < for the actual code used)
is the way used in an Obsidian plugin to add different color highlights to text in an Obsidian document. A lower friction method would be welcomed. - Tables are a major headache - they take ages to write and format.
- It seems to me that (in general terms) markdown is intended to be used for very simple things, and html for more complicated things. It would be very nice to see some combined markdown and html editors that can create a single document that can have both. I think that this is already contemplated in the spec, but I have not seen any editors that can do both in the same document. Are you aware of anything out there that does this ?
I am writing because feedback has been requested - I do not know enough about markdown, html, or coding to have a very detailed interaction, but I do know what I want to try to achieve. I have no idea how possible any of this is, and as far as all these things go, I hope you do not mind my ignorance of the detail of all of this, or by my references to Obsidian - and I hope that you are OK to discuss these things here and can give me your thoughts as to the best way to achieve this and in such a way as interoperability can be achieved between different implementations so different programs can be used successfully on the same set of markdown documents.
Many thanks !