This is something we gave up when moving from using the browser's HTML parser to a custom parser in 2.0. The tradeoffs of being able to run directly in Node.js and reducing the library size were good, but we have heard from a few people that some of the niceties of HTML like this would be pleasant to have back.

I'm not sure how feasible it is to implement void elements, since its a whitelist. Perhaps we could move validation into something like an editor plugin?

reducing the library size

I just realized that i don't understand why a small library size would be a goal of this library

My understanding is that for most libraries, the size of the library is a necessary cost to be paid for the functionnality it offers

However, for htm, if i understand correctly, babel-plugin-htm reduces the footprint of the library to literally zero regardless of its original size
So with an easy-to-setup opt-in, users can have maximum functionnality of the library (and even smaller runtime cost!) at the cost of zero bytes

Under these circumstances, i see using the htm library in the browser as a transitional path to the Babel plugin rather than something that has to stay forever (which is usually the case for libraries). In this context, keeping the library size small does not seem that relevant any longer

I understand that for some use-cases, the library size is less important. However, there are potential performance reasons to use htm without transpiling in production - including some interesting tradeoffs for JS parsing time. At 400-500 bytes, those tradeoffs are often worthwhile. A 10kb implementation with pretty warnings and english messages would likely invalidate that.

Just an addendum: I think it would be both possible and reasonable to add extended parser error messages to babel-plugin-htm, since it doesn't get loaded at runtime.