The use case mentioned - custom list bullets - can be implemented using CSS btw [1]. Not that I'd advocate for it; like all things CSS, it involves lookup of obscure and rare custom syntax, questionable layering a la "content:", suggestion of orthogonality that isn't really there, and browser support troubles.

[1]: https://web.dev/css-marker-pseudo-element/

In the rest of HTML syntax, adding a trailing slash does exactly nothing—it’s just ignored by the parser¹. For my part, I firmly recommend against writing it if you’re using HTML syntax, because it gives the false impression that it does something; rather, there’s a hard-coded list of elements that have no contents and thus no closing tag. It’s not uncommon to find people writing their />, but it’s practically never consistently applied, e.g.:

  <meta charSet="utf-8"/>    ← ²
  <link rel="…" href="…"/>
  <link rel="…" href="…">    ← Where’s my /, hmm?

HTML/XML polyglot is a surprisingly thorny issue, and my experience is that a lot of JavaScript libraries make assumptions that don’t hold in XML-syntax documents and thus won’t work properly. In practice, almost no one uses XML syntax for anything new, and foreign content (SVG/MathML) is the last remnant of widely-used XML in HTML.

—⁂—

¹ This is a very slight simplification. Look into the self-closing flag in the spec if you’re interested in the details.

² I think that wrong capitalisation of charSet comes from Next.js, because every time I’ve seen it, Next.js has been present. It has irritated me for years, but never quite enough to dig in and find the source and beg them to fix it. No idea if Next.js supports using XML-syntax HTML, but if it does, that meta charSet will be invalid, because XML syntax is case-sensitive and it’s supposed to be charset—though I think it will still work in practice because of the charset detection algorithm actually working on the bytes, not the XML/HTML syntax, and being case-insensitive. And if Next.js doesn’t support using XML syntax, I wish they’d stop generating trailing slashes, too, because they’re just a waste of time.

  <img src=x/>   =  <img src="x/">
  <img src=x />  =  <img src="x">

It could also be an habit, and not really a harmful one. You can argue against it with convincing arguments, but in the end, there's nothing fundamentally wrong with it. It's understood by the parser.

The space before the slash once was advised for compatibility with old browsers when writing polyglot html. Some old browsers would not understand the slash, but this would not be an issue with a space. This is mostly irrelevant today but habits stick.

And with the gotcha exposed by my sibling comment, maybe it's better to stick with the space after all when using the slash. And I can see how wanting to explicitly close the tag is compelling, even if it has its drawbacks.

    2527 p
    2047 a
    1318 span
    1078 td
    918 b
    537 tr
    531 sub
    499 br
    401 i
    393 table

Moreover, I don't even have internal dependencies, every page is written from scratch (with a pinch of copy-paste). This is a hobby project, and I like to program, so I'm just not interested in code reuse.

But if more people do it and report their usage patterns one could maybe create a "super-markdown", i.e., the closest you could get to mapping html flexibility without the annoying XML verbosity.

Aka SGML.

Though while you can hide those away in an external DTD, SGML of course needs lots of markup declaration ([1]) for HTML "void" (empty) elements, tag inference, and enumerated attribute short forms, and then still more for markdown short references.

[1]: https://sgmljs.net/docs/whatwg-html200129-dtd.html

[0] http://xidoc.nim.town/

I struggled with Markdown (and various other mark up formats) for a long time, until I realised that, for me, nothing beats plain HTML for simplicity and expressive power.

I now use HTML the way people generally use markdown: as an open, easy to read, easy to write, plain-text format for taking notes, writing articles, expressing thoughts, and so on.

I didn't really choose HTML, I just sort of noticed that I was using it. It seems like an unconscious decision, like a river flowing downhill, finding its own path.

Most used tag would be <p>, because I write a lot of essays and things with paragraphing. As well as other structural elements such as headings and lists, I lean into <time>, <cite>, <abbr> a lot.

I tend to use the 'optional' form. I don't close <p>'s and <li>'s unless required.

DSL-wise, I've rather enjoyed Clojure's Hiccup [1].

[0] https://emmet.io/

[1] https://github.com/weavejester/hiccup

Looking up elements that support no closing tag:

html, head, body, p, li, dt, dd, option, thead, th, tbody, tr, td, tfoot, colgroup

Makes sense if you think about it. Basically everything is pretty well defined and its obvious what next tag should close the context. <td> for example obviously ends when you come across another <td>, another <tr>, or the required </table>

Only a madman would nest tables!!

/me crying in 2000's web design.

  <table>
  <tr>
  <td>
    <table>
    <tr>
    <td> table-cell-inside-table
    </table>
  </table>

Took me a long time to train myself out of <br/> afterwards though.

But the optional-style works I think for writing. Especially if you're just writing a document. If you don't have site-menus, a search bar, social-media sharing icons, javascript libraries and all the other paraphenalia and page-furniture of a website, then you are left with a lean and structured file.

It is a valid short form of <br></br>

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/br

so it should be <br> on its own or <br />

<img src="img.png" height="100px">

(also the other parameter is set to "auto" automatically, at least in Firefox)

the width will be set to match the aspect ratio but your browser will have to DL the image first. which probably doesn't matter unless you have content to the left/right of it, then it'll get bumped when the image loads. layout shift is a nasty thing.

but i'm not sure if i understand the question...

https://mtsknn.fi/blog/how-to-remember-markdowns-link-syntax...

Think of it as a function call (mnemonically, it doesn't need to make sense conceptually).

The [ and ] are ascii art for a button - in between goes what is clickable (title) and then comes the url.

> I can never remember which brackets to use

and that is patently untrue, as you just demonstrated.

As for TOC, I've never written anything that strictly needs one. I do have "hxtoc" on my laptop, but I've never needed it.

I do publish some of my writing to my website, and I discuss the minimal tooling I use here: https://brett.coulstock.id.au/site-colophon.html

But I do write HTML templates by hand when I code webapps; it's cleaner and more efficient than use some kind of library.

I tend to use DIVs with custom data- attributes; I don't know if it's a good or bad practice but I'm not familiar enough with other approaches and I'm used to it.

I also code SVGs by hand and it's surprisingly easy and straightforward; most (not all, but most) drawings can be approximated by combining elementary shapes (instead of paths).

Interesting. Do you have any examples of thise approximations?

https://news.ycombinator.com/item?id=35898741

For everyone else feeling like me: Try pug (formerly jade) or rather it's CLI variant pug-cli. You can reuse stuff and even have JS in it to iterate through things or give it parameters, all while still feeling pretty vanilla.

https://pugjs.org/api/getting-started.html

It is a bit terser:

h.div.class('box)(...)

I can't see how anyone would prefer xml formatting to sexp for any significantly lengthy document. I made my own homage to sexpcode called lispmark, some of my friends find it better than markdown or html..

I like to use as many <table> and <span> tags as possible. Particularly for layouts. Sometimes, if I'm feeling frisky... <frame> gets invited to the party.

Advantages: - greater flexibility than with Markdown; - no need to decide between Markdown, ReStructuredText, Wiki markup, BBCode, etc;

Disadvantages: - writing closing tags is cumbersome;

The source code is here: https://github.com/ClickHouse/clickhouse-presentations Example: https://presentations.clickhouse.com/meetup74/ai/

Personally I've come to appreciate that many closing tags are unnecessary in HTML. Makes many constructs much more concise. Especially with tables:

``` <table> <caption>Some letters and numbers <thead> <tr> <th>Letters <th>Numbers <tbody> <tr> <td>A <td>1 <tr> <td>B <td>2 <tr> <td>C <td>3 </table> ```

I used to be team semi-colon in JS but I've switched teams now and have my formatter strip them. There's like 1 or 2 edge cases where that can bite you but practically speaking it's a non-issue. The real downside is that I sometimes get lazy when writing C++ and that very much dislikes poor punctuation.

The p tag is one of the most frequent.

I use span tags for placeholders in templates, that way the HTML is still usable before it is filled in.

The tag form is important to remember, because older browsers will not even display input elements without it, and you won't be able to address them.

The font tag gets a lot of scorn these days, but it is the only compatible way to color individual parts of text in older browsers, so I use it sparingly, via templates.

There is a subset of HTML 2.0 which works consistently across about 25 years of browsers, and I think it is one of the most amazing technologies we have in the world, for its longevity, resilience, and open/unowned nature.

  find . -name '*.html' -exec tags {} \; | sort | uniq -ic | sort -rh | head -n 10

  12307 td
   7224 tr
   5851 table
    950 code
    821 font
    644 a
    522 p
    373 b
    332 span
    293 br

    #!/usr/bin/awk -f
    BEGIN {
        while( (getline t < "tags.txt") > 0) tags[t] = 0
    }
    {
        for (t in tags) tags[t] += gsub("<" t "[ |>]", "")
    }
    END {
        for (t in tags) print tags[t], t
    }


    ./count.awk $(find . -name '\*.html') | sort -rh | head -n 10

    534 li
    290 a
    215 p
    149 br
    132 span
    99 ul
    66 b
    47 div
    40 pre
    37 meta