![]() | This proposal is part of "A Dozen Visions for Wikitext". Shortcuts: Versioning - Grunge - Markdown - HTML-only wikis - Extension tag fragments - Syntax uniformity - Colon replacement - Backticks - Syntax for Discussions - #media - #lang - #balance - Long arguments - Variable-length/structured arguments - Annotations - Visual Templates - Page Description Language - Native Script Editing - One Wiki |
So, if we can do Markdown, can we do nothing at all?
That is, store articles natively as HTML, use Visual Editor as an HTML editor, and not have any parser at all in core?
We’ve done this, too: it’s how Flow worked. Flow was a minor disaster, and part of that disaster was the fact that we didn’t have a good solution for versioning the HTML we stored, but it did work. And versioning was our item #1, so we’ve solved that already, right?
A more rigorous statement of this vision is written up as the “zero parsers in core” proposal. And the goal wasn’t actually to remove all the parsers, but to make them generic and pluggable (phab:T114194), so that wikitext was just a parser you could load as an extension like any other parser. The main architectural hurdle is system messages, which are hard-wired as wikitext. Tagging system messages with a content type would fix that, and it would also help security as well because some messages aren’t wikitext, they are actually plaintext, and some others are raw html, and not being certain about exactly how your system message is going to be parsed is an opening for a heap of security issues.
An HTML-only wiki would just looks the same as VisualEditor except it wouldn’t have the “source” editing option:
Next section: Extension tag fragments