The author wrote an entire article explaining their use case which answers your question. Short version: they’re writing a book which they want to render to multiple formats with semantic linking between items and different rendering based on formats.
I get that, but why not use HTML as the base to render to other formats? I guess I'm not 100% clear what you mean by semantic linking and how could that not be achieved through HTML.
If I understand you correctly, you want to throw out rST, and just have users write HTML directly? I see two issues with that:
1. HTML is designed for representing webpages, not books. Your intermediate representation will become HTML's DOM, which is likely not well suited to the book use case. You'll either need to use an existing HTML-to-DOM parser or build your own. One big limitation of the DOM, as I see it, is that it doesn't have the concept of a page number.
2. HTML is not extensible in the way the author talks about. This is the "semantic linking" thing I meant. In rST, you can define entirely new top-level constructs: he defines an exercise which has a solution and will be a part of a solution list. The semantic linking part is that other parts of the document will refer back to these solutions. Some output formats will have all solutions inline, with the exercises, while other output formats will collect all solutions in one place at the end. HTML is not flexible in that manner.
What is extensible is XML. It's entirely feasible for XML to be the input, but for better-or-worse, most people are even more turned off by XML than they are by something like rST.
> If I understand you correctly, you want to throw out rST, and just have users write HTML directly?
Yep!
> 1. HTML is designed for representing webpages, not books. Your intermediate representation will become HTML's DOM, which is likely not well suited to the book use case. You'll either need to use an existing HTML-to-DOM parser or build your own. One big limitation of the DOM, as I see it, is that it doesn't have the concept of a page number.
I guess my point is that while the main use of HTML indeed to render webpage, it seems pretty well suited at rendering most if not all types of documents. The page number issue you mention is typically only part of the presentation and is handled by the CSS paged media module (though admittedly, support of this isn't universal in my experience).
> 2. HTML is not extensible in the way the author talks about. [...]
Except it is! This is what HTML Custom Elements are all about. Combined with CSS, it can handled to different rendering formats you mention pretty well.
> What is extensible is XML. It's entirely feasible for XML to be the input [...]
I'd actually argue that raw XML is the wrong approach for most things, as the goal of XML is to be extended (e.g.: SVG, MathML, SAML, etc.). But I feel like that's a whole other discussion.
Anyways, I think this is a good conversation and wouldn't mind continuing over email (see my profile). It's fine if some people like rST, but HTML seems better suited for these use case than people make it out to be.
I'm less likely to continue this conversation over email. Such is life. :)
I think that bringing in CSS is a bridge too far for the case of writing a book. Authors are no longer just writing HTML, they're writing HTML and CSS. And CSS is intimately tied to actual web browsers - you're now going to need a browser display engine to be an integral part of how you render your book. (Or you're going to need to implement just enough of that yourself, which is a big undertaking.)
The point of comparison is Markdown, which is relatively straight-forward and simple. HTML and CSS is not that.
