2025/Düsseldorf/textauthoring
Text authoring was a discussion session at IndieWebCamp Düsseldorf 2025.
hashtag: #textauthoring
Participants
Tantek Çelik
Joschi KuphalDavid Shanske
Schepp- ... add names
Background
- previously: https://indieweb.org/2024/Berlin/textux
- Joschi Kuphal: ASCIIDoc / Markdown and alternatives for writing posts
- T been working on a simpler alternative: https://tantek.com/w/Markdown
Notes
Joschi used a CMS previously, but is a Markdown afficionado, but for particular stuff he started using ASCIIDoc (https://asciidoc.org/) because the features of Markdown are too limited for what he needs to do like work with (especially for professional work)
- tables
- definition lists - no such thing in Markdown (kind of an extension maybe?)
- code example (inline and block)
- properly marked up quotes (block and inline), being able to indicate the author
Compared it with the features that ASCIIdoc brings, and you can do all of that with ASCIIdoc.
Never used Markdown for his personal website. Too limited for the blog posts that Joschi wants to write, in the semantic and accessible way he wants to write them. He worked out a library to create HTML from ASCIIdoc. Most important thing is being able to take control of the HTML is created per "block" in ASCIIdoc, in order to e.g. add ARIA attributes. Found a way to do this at IWC DUS 2024.
Tantek wnet a similar route than Joschi. He used Markdown on GitHub and the likes but never on his own site. But he found Markdown offensive for design considerations. Tantek then cites the "raison d'^etre" from the Markdown wesbite, being that Gruber wanted to find a syntax that is the most readable possible so that it would even work when not processed. But Tantek did not find that to be true: https://tantek.com/w/Markdown
Examples are links not being automatically transformed into linkd and image URL not being automaticallyswapped out for the image like other UI like the one from Slack do. So he implemented his own syntax for his page. He would wish for these things being implemented in other syntax - together with the ability to turn certain features on and off individually.
Joschi sees us mixing up two distinct things here: The format for storing data and then capabilities of the interpreter/richtext editor. Autolinking would be a feature of the interpreter but not of the storage. Tantek feels like the storage should reflect what the user typed in. Joschi asks why you would not want to store the content with converted / replaced / processed results, like with autolinks and auto image replacement. And he mentions sustainability, as this way conversion from input to result does not need to get repeated all the time. Tantek doesn't think that conversion is a lot of processing which is why it's okay to do it frequently. It also makes the storage format more complicated than needed.
Next question from Joschi: how do you do alternative text in Tantek's syntax? Tantek's syntax offers that feature via a parenthesis following an image URL, which is also still readable. Gunnar sees a lot of resemblance with markdown. But Tantek counters that Markdown's syntax for images brings a lot of noise with it. Gunnar points out that while and URL is easily recognized when ending on .JPG, but how is that going to be with more exotic extensions?
Tantek brings the usecase to the table that people have to edit existing richtext and that if one saves text processed, then the experience editing text will differ from the experience writing it at the beginning.
Coming back to Markdown, Tantek see it as a failed concept because that's not how non-tech people format their texts, but that there are a lot of other, less noisy and weird, markup conventions in practice. Joschi then proceeds to show Tantek Asciidoc which more of the people involved in the discussion seem to like. Tantek then proceeds to show his syntax ideas as written down here: https://tantek.com/w/Markdown
Joschi and Gunnar then spin different scenarios and ask all kinds of questions on how the syntax will formulate and/or process these. Afterwards Joschi proceeds to showing Tantek Asciidoc and to explain a few details about it, like how you do tables (which Tantek has not yet a good solution for). Then they have a look at ASCIIdoc code blocks which Tantek really likes.
Wrap-up: We should keep editing for users as simple as possible while offering rich (compile) results. Joschi adds that "simple" depends a bit on the kind of user. Gunnar sees a WYSIWYG editor as being the favorite kind of editing tools for most users.
We end the session with looking at https://en.wikipedia.org/wiki/Lightweight_markup_language
- ... add notes