4 ms·

Very interesting. If people keeps creating their own extensions of Markdown it's because there's a need somewhere for a comprehensive markup language. Markdown

Very interesting. If people keeps creating their own extensions of Markdown it's because there's a need somewhere for a comprehensive markup language. Markdown wasn't invented with documentation in mind, for example, so now we have rST, Asciidoc, Markdoc, Djot, etc. I really wish a powerful standard emerged, though.

lucideer 2y ago
> If people keeps creating their own extensions of Markdown it's because there's a need This is a general misconception about why people create. People don't always create to fill a need - in most cases, motivation to create is intrinsic rather than extrinsic. As for having a comprehensive markup language - every product & creative avenue in every field in the world needs to contend with balancing complexity & expressiveness with accessibility & simplicity. Markdown errs heavily on the latter side for the writer but comes with natural trade-offs (e.g. it leans heavily on the complexity side for parser-developers) - that push-and-pull will always motivate folk to try & strive for the magical best of both worlds.
- remoquete 2y ago
  People often create to fulfill a need. The need might be intrinsic -- the need to create something. But back to the point: Agreed, you described well the existing tension. At one end of the spectrum you've systems like LaTeX and DITA; on the opposite side, Markdown. I don't think Markdown should ever be extended. If anything, it should be encapsulated.
mhh__ 2y ago
Perhaps it could be some kind of hyper text markup language
- mrinfinitiesx 2y ago
  doesn't sound good enough, let's add some kind of cascading style sheet to it, some java script, wrap it up in something called electron slap the word app on it and ship it.
tcfhgj 2y ago
You forgot Typst https://news.ycombinator.com/item?id=41014941 https://news.ycombinator.com/item?id=41014941
jeltz 2y ago
And before that we had roff.
v3ss0n 2y ago
We should move on to Djot , it is future of markdown by developer of commonmark and pandoc.
- remoquete 2y ago
  The pedigree is outstanding, but what makes Djot superior to, say, reStructuredText or Asciidoc?
  - alexisread 2y ago
    There's page about the design decisions: https://github.com/jgm/djot#rationale https://github.com/jgm/djot#rationale TLDR: single pass, multiple (identical) implementations on different platforms, HTML is not an implicit target, uniform syntax (including attribute syntax)
    - woodrowbarlow 2y ago
      this looks like really good improvements over commonmark. i'd like to start using djot to render existing markdown files, and slowly start writing new files in djot utilizing some of the extra features. i tend to write my markdown such that it would mostly be a valid djot file anyway (no html, #-only for headings, empty lines between all block elements, etc.) -- but i see one design choice that prevents me from making this transition. it looks like djot has changed the syntax for inline italic/bold text in a way that's incompatible with markdown. i see why it was done, but it's a shame because it looks like this is the only thing that really prevents rolling this out as a "soft" transition.
red_trumpet 2y ago
> I really wish a powerful standard emerged, though Relevant xkcd: https://xkcd.com/927/ https://xkcd.com/927/
- deleted 2y ago
  [deleted]
deleted 2y ago
[deleted]
bluGill 2y ago
> I really wish a powerful standard emerged, though. This is not possible. Any standard powerful enough for everything is also too complex for simple things! Most documents are simple and don't need the power. There is a good argument that authors shouldn't even have access to layout (ever see a 4th grader write a report - they spend hours preparing the table of context, index and other such layout details leaving little time for the content!), you may not agree with the argument in the end but you should understand it. There will always be debate about what is the right things to include in your documentation standards. Since there are multiple different types of documents with different requirements there will be different answers.
- smitty1e 2y ago
  Maybe some segmentation into minimal, average, and deluxe would help the Goldilocks situation.
  - bluGill 2y ago
    Unfortunately it is easy to create something that is "better" for which ever situation you are in. It is much harder to think "I can but I shouldn't so I won't". (or maybe I'll do it for fun in my basement and then burn the code once I learned what there is to learn). The above doesn't apply to markup. There are lots of other situations where you can do something better, but it won't be enough better to be worth doing. (and of course there are also cases where it really is better by enough)
tannhaeuser 2y ago
With SGML, there is a powerful standard and prior art. SGML SHORTREF declarations let you define most of markdown's span- and block-level syntax by mapping tokens to start-/end-tags or any other replacement string in a state-dependent fashion such that eg toggling bold text on and off is easy, with special recognition of newline/end-of-line "tokens", etc. The mapping to HTML is very natural, also because using in-line (or block-level) HTML angle-bracket markup tags works exactly as in markdown. Though unlike markdown, SGML will complain about syntax errors, rather than format incomplete markdown syntax as verbatim text, and markdown "referential links" put anywhere before or after the place where it is referenced won't work. Text macros (entities) come for free with this approach, and SGML SHORTREF customizations also can be used for any number of additional document-specific conventions on top of markdown. Even if not actually using SGML but one of the hundreds of markdown-to-HTML converters, checking for SGML upward compatibility is a useful thing to do IMO because of the already crowded space of tokens recognized in marked up text and their recognition priorities.
- remoquete 2y ago
  I've heard this before. It sounds good, but where to start?
  - tannhaeuser 2y ago
    For markdown-in-SGML specifically, there's a tutorial at https://sgmljs.net/docs/producing-html-tutorial/producing-html-tutorial.html https://sgmljs.net/docs/producing-html-tutorial/producing-ht... also covering usage of entities/text macros.

lucideer 2y ago

> If people keeps creating their own extensions of Markdown it's because there's a need This is a general misconception about why people create. People don't always create to fill a need - in most cases, motivation to create is intrinsic rather than extrinsic. As for having a comprehensive markup language - every product & creative avenue in every field in the world needs to contend with balancing complexity & expressiveness with accessibility & simplicity. Markdown errs heavily on the latter side for the writer but comes with natural trade-offs (e.g. it leans heavily on the complexity side for parser-developers) - that push-and-pull will always motivate folk to try & strive for the magical best of both worlds.

remoquete 2y ago
People often create to fulfill a need. The need might be intrinsic -- the need to create something. But back to the point: Agreed, you described well the existing tension. At one end of the spectrum you've systems like LaTeX and DITA; on the opposite side, Markdown. I don't think Markdown should ever be extended. If anything, it should be encapsulated.

mhh__ 2y ago

Perhaps it could be some kind of hyper text markup language

mrinfinitiesx 2y ago
doesn't sound good enough, let's add some kind of cascading style sheet to it, some java script, wrap it up in something called electron slap the word app on it and ship it.

tcfhgj 2y ago

You forgot Typst https://news.ycombinator.com/item?id=41014941 https://news.ycombinator.com/item?id=41014941

jeltz 2y ago

And before that we had roff.

v3ss0n 2y ago

We should move on to Djot , it is future of markdown by developer of commonmark and pandoc.

remoquete 2y ago
The pedigree is outstanding, but what makes Djot superior to, say, reStructuredText or Asciidoc?
- alexisread 2y ago
  There's page about the design decisions: https://github.com/jgm/djot#rationale https://github.com/jgm/djot#rationale TLDR: single pass, multiple (identical) implementations on different platforms, HTML is not an implicit target, uniform syntax (including attribute syntax)
  - woodrowbarlow 2y ago
    this looks like really good improvements over commonmark. i'd like to start using djot to render existing markdown files, and slowly start writing new files in djot utilizing some of the extra features. i tend to write my markdown such that it would mostly be a valid djot file anyway (no html, #-only for headings, empty lines between all block elements, etc.) -- but i see one design choice that prevents me from making this transition. it looks like djot has changed the syntax for inline italic/bold text in a way that's incompatible with markdown. i see why it was done, but it's a shame because it looks like this is the only thing that really prevents rolling this out as a "soft" transition.

red_trumpet 2y ago

> I really wish a powerful standard emerged, though Relevant xkcd: https://xkcd.com/927/ https://xkcd.com/927/

deleted 2y ago
[deleted]

deleted 2y ago

[deleted]

bluGill 2y ago

> I really wish a powerful standard emerged, though. This is not possible. Any standard powerful enough for everything is also too complex for simple things! Most documents are simple and don't need the power. There is a good argument that authors shouldn't even have access to layout (ever see a 4th grader write a report - they spend hours preparing the table of context, index and other such layout details leaving little time for the content!), you may not agree with the argument in the end but you should understand it. There will always be debate about what is the right things to include in your documentation standards. Since there are multiple different types of documents with different requirements there will be different answers.

smitty1e 2y ago
Maybe some segmentation into minimal, average, and deluxe would help the Goldilocks situation.
- bluGill 2y ago
  Unfortunately it is easy to create something that is "better" for which ever situation you are in. It is much harder to think "I can but I shouldn't so I won't". (or maybe I'll do it for fun in my basement and then burn the code once I learned what there is to learn). The above doesn't apply to markup. There are lots of other situations where you can do something better, but it won't be enough better to be worth doing. (and of course there are also cases where it really is better by enough)

tannhaeuser 2y ago

With SGML, there is a powerful standard and prior art. SGML SHORTREF declarations let you define most of markdown's span- and block-level syntax by mapping tokens to start-/end-tags or any other replacement string in a state-dependent fashion such that eg toggling bold text on and off is easy, with special recognition of newline/end-of-line "tokens", etc. The mapping to HTML is very natural, also because using in-line (or block-level) HTML angle-bracket markup tags works exactly as in markdown. Though unlike markdown, SGML will complain about syntax errors, rather than format incomplete markdown syntax as verbatim text, and markdown "referential links" put anywhere before or after the place where it is referenced won't work. Text macros (entities) come for free with this approach, and SGML SHORTREF customizations also can be used for any number of additional document-specific conventions on top of markdown. Even if not actually using SGML but one of the hundreds of markdown-to-HTML converters, checking for SGML upward compatibility is a useful thing to do IMO because of the already crowded space of tokens recognized in marked up text and their recognition priorities.

remoquete 2y ago
I've heard this before. It sounds good, but where to start?
- tannhaeuser 2y ago
  For markdown-in-SGML specifically, there's a tutorial at https://sgmljs.net/docs/producing-html-tutorial/producing-html-tutorial.html https://sgmljs.net/docs/producing-html-tutorial/producing-ht... also covering usage of entities/text macros.