@jaffathecake completely disagree. HTML treating some tags as special cases that don't need to be closed is atrocious, and it ignoring `/>` and requiring an opening and closing tag to create an empty element is doubly so. HTML should treat all tags the same and tags with no content should have an option to self-close instead of pointlessly doubling the tag and creating noise.
Additionally, supporting `/>` in plain HTML comes with no downside as everywhere it appears it's intended to self-close the tag, and even improves resilience for cases where people used to XML and XHTML didn't know it gets ignored and used it.
Your arguments rely on the status quo of the decisions made by the W3C standard body. That body, at least when it comes to HTML, seems to really like proving itself incompetent since its inception up to today. They're like the Jim Cramer of standards, whatever they decided, the exact opposite is most likely a more sensible choice.
@jaffathecake true, sorry, in that context I agree even if I hate that it's true. There's just something about front-end web standards always managing to choose the worst possible design that really grinds my gears.
And yeah, I forgot it's not W3C which is really nice since I generally respect W3C and HTML was a stain on them for me.
@Amikke my article is based on the status quo. I'm honest and up-front about that. I'm talking about mark-up reflecting how things actually work. Although, if you read to the end of the article, I do link to a proposed change to the spec. Also, it isn't a W3C spec, and hasn't been for over a decade.