readable VS asciidoctor-html5s

Original author here. Thanks for the submission. I built the service mostly for myself because I have an old Kobo eBook reader and the browser is pretty basic. This works very well, though.

Only after building it I realized that there could be more use-cases; for example when traveling and working from a bad connection. The pages are usually much more lightweight than the original ones and don't contain any trackers.

I don't even have metrics for that service. No idea how many people are using it and I don't care for the most part. That said, if anyone is interested in using the service you can run your own instance and be completely independent.

The code is here BTW: https://github.com/readable-app/readable.

Did you mean the meta headers? Any example in particular that I could look at? We're in the process of testing different readability libraries. Here's a discussion on what we saw so far: https://github.com/readable-app/readable/issues/2 Maybe you can add a comment there so we don't forget to check your use-case.

https://github.com/jirutka/asciidoctor-html5s

The HTML alternate back-end fixes a lot of these issues and chooses semantic elements for a more modern age (while Asciidoctor is actively overhauling its output I believe).

The issue visually can be solved with CSS as-is, but Microsoft GitHub treats its AsciiDoc rendering as a second-class citizen despite it objectively having more/better features for documentation than Markdown. The negligence becomes apparent when you look at the way GitHub syntax fork (“flavor”) handles admonitions; not only does it overload, overcomplicate, and ruin the semantics of the blockquote, but the CSS styling that makes them look nice was never ported to admonitions for reStructuredText and AsciiDoc despite these formats having the feature natively to the syntax (no fork required).