Hacker News Reader

Comment by aparks517 | Hacker News Reader

I do something like this. You can write HTML almost as simply as text if you ignore some current best-practice.

Google's guidelines for HTML5 [0] are surprisingly good and concise. You can omit most closing tags, and even many "structural" tags are implicitly opened. This is a 100% correct and complete HTML5 document:

    <!doctype html>
    <title>Title of the document</title>
    <p>A paragraph
    <ul>
        <li>First item
        <li>Second item
    </ul>
    <p>Another paragraph

writing html tables by hand is especially pleasurable due to the auto-closing tags. As I see it, modern HTML is so concise that markdown is more of a burden than an aid. In most cases, we would be better off writing html directly than markdown. Maybe the only thing that I miss is that an empty line creates a paragraph tag.

[0] https://google.github.io/styleguide/htmlcssguide.html

That's very cool. Do you have a good solution for inline math?

I wonder how far could one go with just Unicode symbols. Entry would probably need a proper editor support. Additional use of sub/sup could also help.

https://en.wikipedia.org/wiki/Mathematical_operators_and_sym...

The only reasonable thing I have found is mathjax.

Otherwise, if you math is just inline latin/greek symbols without 2D formulas (integrals, summations, etc), you can get away with unicode symbols and sub-indices.

Org mode supports inline Latex that can be exported to html.

Here's a nice demo on how to write tech docs using Emacs and Org mode https://youtu.be/0g9BcZvQbXU

Maybe KaTeX https://katex.org/

I think one of the advantages is that markdown is not just that it is concise, but that it is also somewhat limiting.

If someone worked on a large team and moved all documentation from markdown to HTML, I think they'd quickly grow to become something a lot more messy than your example.

Markdown was made to support inline HTML and most parsers/compilers will support it by default (including Github).

Already has best of both worlds.

Yes, but when you ask someone to write markdown they usually write markdown. And when you ask someone to write HTML, they typically add closing tags.

You've touched on a slightly interesting topic. HTML has never had strict parsing requirements, for example, it was completely permissible in HTML4 to leave a tag unclosed if you subsequently opened a tag which could not be nested (as in your example of two <li>s in a row). Containers have always been implicit in most cases, so it's perfectly acceptable to start a table row without having started a table, the parser will start the table when it encounters the row. This is ultimately because HTML is derived from SGML, a markup standard that is visually similar to XML but with very relaxed parsing.

However, HTML4.1 for a time faded in popularity compared to XHTML, which was an "HTML-like" markup derived from XML rather than SGML. XML has significantly stricter parsing rules, for example always requiring full closing tags, trailing slashes on self-closing tags, etc.

XHTML's popularity seems to have been in large part a result of the IE6 backlash. Problems with web standards were widely perceived as a high priority for the web. This was the time period in which people kept putting "W3C Compliant HTML" badges in their footers. Because XHTML had stricter parsing rules, it fit into the general scheme of emphasizing web markup that was "correct" by allowing for strict automatic validation. Because it was XML-compliant it also fit nicely into both the popular-at-the-time "Semantic Web" (e.g. XHTML documents could be validated against XML DTDs/schemas) and dovetailed with browser support for XSLT (in which case a document could be sent to the browser as semantic XML with an XSLT "style sheet" for transformation to XHTML for presentation), which was one of those things that seemed like "the future" for about five minutes. I had done my personal website that way for a hot minute.

XHTML's vogue was somewhat short-lived, while it was a big part of the "web" scene in e.g. 2007, it was largely forgotten the moment HTML5 because available. What seems to have survived from XHTML, though, is a much stricter approach to writing SGML being seen as more or less required. I think a lot of people "grew up" on XHTML, quite possibly unknowingly, and so errantly view HTML itself as XLM with the subsequent parsing rules.

As always, there is often value in being explicit and verbose in markup in terms of maintainability. But in a lot of cases readability and maintainability are not harmed or even improved by saving some typing... as in cases like lists and tables.

That said, a big part of the phenomena is that hand-writing or reading HTML is decidedly out of vogue today, and so in general the readability quality of most HTML on the web is extremely poor, generally a result of it being generated by templating or composable component systems which often abandon basic indentation, as well as by the popularity of frameworks with unusual use of HTML such as non-semantic class-driven CSS frameworks. Of course this phenomena isn't entirely new, FrontPage and DreamWeaver were popular in their day and generated some pretty terrible markup, but it seems to have become more common, rather than less, for HTML to be machine-generated and thus extremely unpleasing to humans.

I wrote up a few of my own thoughts[0] on moving away from writing markdown to writing HTML directly. At this point I have a small bit of code to wrap things into an <article> tag include a <header>, <footer> with links to a home page and include some boilerplate like <meta> tags. I don't think I've sacrificed anything in terms of best practices and actually gained a few things in writing more semantic HTML which I think aid in assistive technologies[1]. I actually hope people will "view page source" on my pages anymore -- a big part of getting to where I am has been testing against alternative browsers like eww and w3m.

[0]: https://idle.nprescott.com/2020/why-bother-with-markdown.htm...

[1]: https://sourcehut.org/blog/2020-05-27-accessibility-through-...

I've been writing HTML directly for my blog [1] for 20 years [2] and back around 2003 I started to be a bit more pedantic about the HTML I use, so I always (try to) close every tag. About five years ago I set up a gopher server [4] and use it to mirror my blog. I went the easy route and decided to use Lynx to convert the entries from HTML back to text, and ... it looks horrible. Now that the Gemini protocol [5] has stabilize, I've decided I should convert the HTML to text myself, and because I decided back in 2003 to close every tag, it's easy to do (after spending an evening cleaning up a few entries here and there---there are over 1,000 entries pre-2003 that need extensive cleanup though---sigh).

The optional tags make it easier to write, but make it far harder to mechanically process later if need be.

[1] http://boston.conman.org/

[2] It's been only the past year or so that I've created my own markup language [3] to render the HTML, and it's the resulting HTML that I store.

[3] A mostly-up-to-date sample of what it looks like: https://github.com/spc476/mod_blog/blob/master/NOTES/testmsg And the Lua script that parses it: https://github.com/spc476/mod_blog/blob/master/Lua/format.lu... It's still buggy, and there are corner cases I know how to avoid, and I'm not recommending it to anyone else, as it works for me.

[4] gopher://gopher.conman.org/

Nice. I went one step further because I don't even want to write HTML. I built my website in PHP to parse plain-text files then sort and display them by creation/modification date or title/category. The only markup in the text files is usually <b>, <i>, and sometimes <a href>. This way I can write in whatever editor I feel like, export as .txt, then scp the file right to my site for publishing. I guess it's like a custom CMS? Either way, it really helps my ability to write for some reason.

Reply on news.ycombinator.com