There are "slideshow" forward and backward buttons at bottom left. Horrible UX, and when I opened it, actually thought it was vapourware because the landing page was so devoid of information.
I closed it on my desktop after a few minutes when I couldn't figure out how to navigate. Others are talking about slides, but I didn't see any.
My background is human machine interaction. I have a reflexive urge to not look for "undiscoverable" navigation elements and close a page when I see them. The world needs better UI, and I'm doing my part by not giving my eyeballs to bad UI.
It looks like a Reveal.js presentation. I wouldn't say I saw “slides”, but rather a single slide, which is a poor indication that it's a slideshow (which needs to be navigated with the arrow keys or with the arrow buttons in the bottom right). A website that doesn't show more information on scrolling down is incredibly poorly designed.
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.
> 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.
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)
> 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.
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.
TLDR: single pass, multiple (identical) implementations on different platforms, HTML is not an implicit target, uniform syntax (including attribute syntax)
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.
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.
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.
I like it. It's not complex but you can do complex stuff. It is why I use AsciiDoc. I don't think creating a new (and better) markdown will win hearts... yes it is nice but you need to compete with a lot of attempts to improve it. ... relevant XKCD: https://xkcd.com/927/
Thanks for the reminder about Asciidoc! A few years ago I dug into various markup languages looking for a better way to draft legal documents. Asciidoc was the best balance of power & simplicity.
Unfortunately the ecosystem was pretty weak. In subsequent years there has been an effort to standardize the spec, which should unlock better tooling. I need to check in on that…
Yes, but it's probably worth another look as my use cases have shifted around. I'm 1000% not interested in signing up for their SaaS (corporate data security concerns) but I see that they have an open source CLI [0] so maybe I'll try that. Also, looks like they offer a self-hosted enterprise offering now, which is intriguing.
My use cases include:
- Drafting, reviewing and iterating over legal documents, especially contracts
- Technical and business process documentation
- Long-form, print-friendly report generation, including data visualization, tables and images
The open-source CLI is indeed all you need. On Mac, I could just do `brew install typst` to get the compiler, and then run it on a local `*.typ` file. I'm sure there are packages available for most Linux distributions as well by now.
Typst is trying to take on LaTeX: high-quality PDF output, equation typesetting, citation and reference systems, programmability, etc.
But if you look closer, the actual syntax of Typst is clearly a mix of MarkDown and AsciiDoc (e.g. code blocks and lists work like MarkDown, while headers work like AsciiDoc, and I think the math syntax is to some degree inspired by AsciiMath from the AsciiDoc ecosystem).
As someone who mainly uses MarkDown to author PDFs, I find Typst to be a clear competitor to Markdown/AsciiDoc/Org as well as TeX. I think they're working on basic Typst support for Pandoc, in which case you might soon be able to generate HTML with it too.
The king in this space is Pandoc. It supports most things you might need in "serious" documents: figures, tables, equations, references, citations, etc. You can even customize the TeX export template if you need more control over the output. And if you need to later, you can easily re-export the same document to TeX, DOCX, or HTML.
Lately, I've also been using Quarto a bit. The default export is HTML but it also supports PDF. It's nice if you're into "literate programming", where you write code blocks (e.g. Python snippets) in a MarkDown file, and those code blocks are automatically used to generate figures, tables, etc. in your MarkDown file on export.
If you want something that "just works" and are not averse to commercial apps, I can recommend giving "iA Writer" a shot. It has a built-in preview and export solution that is lightning fast and has good support for equations. But I wouldn't use its export for anything important, as the output is clearly draft quality, and the MarkDown support lacks features like citations. (Though it supports footnotes, so for informal documents you can abuse that for citations.)
I wonder about the other direction - how much can you remove from Markdown until it's no longer useful enough for wide adoption?
How about:
one heading level only
no nesting (of lists or styles)
tables can only contain plain text (not even links!)
either indented or fenced code blocks, but not both
But keep the html escape hatch. If anyone needs one of the missing features, they can drop down to html. Just a bit more friction.
I recently made a markdown parser that is essentially this. It runs my blog. My table parser is non-standard, though, as I hate typing up markdown tables. Instead, I’m using a special code block “gen:table” and I just type up a whitespace-aligned table.
The raw markdown table ends up looking like a table even with standard markdown processors since it just renders as an unknown code block.
Tables can be very nice to work with in a text editor with some convenience features like automatic alignment and tab-to-next-cell. At least that's my experience using tables in emacs with org-mode files. But I imagine there's quite a lot going on behind the scenes to make that work, plus there's some inflexible syntax used to recognize when your cursor is in a table.
But I like your approach of leveraging monospace fonts to work as informal tables.
gemtext (the native presentation format for gemini capsules) is a markdown-like language which only uses the first three characters of each line to determine the presentation mode for that line. it's designed so that it's trivial to create a renderer, even on retro 8-bit computers (determine presentation mode, set up the font, then just dump the buffer until you hit a newline). it supports paragraphs, headings (3 levels), links (not inline with text, must be on its own line), lists (unordered), blockquotes, and preformatted text. there is zero inline formatting (not even a way to emphasize words in a paragraph).
Remove img support. Its severely lacking anyways. Most images need more meta data such as sizes, but also modern images are responsive with different resolutions etc.
I wonder if we can replace Markdown by an LLM entirely. Just tell it what you want and how it should look in natural English, and then use that as your source file.
You would need LLM output to be deterministic first (i.e., given the same set of English instructions, you get the exact same output every time). And that’s not even getting into the inherent problems with the nuances of natural language. For something like this you really do need a tailor-made language suited to the task.
I guess OP never get why there is markdown in first place. Why another scripting lang inside Markdown which suppose to be readble , natural to write , easy to render.
```
.function {greet}
to from:
\*Hello, .to\* from .from!
.greet {world} from:{Giorgio}
```
No Hell No , You don't need that in a markdown-like doc. If you want that just use HTML with js. or MDSvex .
Zoom works for me on iOS but I had to zoom so much to read the text that I then had to scroll a lot, turning the whole experience unpleasant. Landscape mode did not naturally enlarge fonts enough to make them readable.
I have one nitpick with djot that is very small but annoying: nested lists shouldn’t require a new line before them.
.
- foo
- bar
- baz
should be OK, but djot requires it to be
.
- foo
- bar
- baz
I get that djot wants blocks to be delimited by newlines, in fact I like that decision. But then a nested list shouldn’t be considered a separate block from its parent, it should be considered a “child”, where “child” blocks are delimited from “parent” blocks by indentation instead of newlines.
EDIT: formatting doesn’t seem to be working, the “foo” and “bar” are supposed to be indented at the same level.
