Comment by imiric
17 hours ago
The author has a point, but I object to this mischaracterization:
> XHTML, being based on XML as opposed to SGML, is notorious for being author-unfriendly due to its strictness
This strictness is a moot point. Most editors will autocomplete the closing tag for you, so it's hardly "unfriendly". Besides, if anything, closing tags are reader-friendly (which includes the author), since they make it clear when an element ends. In languages that don't have this, authors often add a comment like `// end of ...` to clarify this. The article author even acknowledges this in some of their examples ("explicit end tags added for clarity").
But there were other potential benefits of XHTML that never came to pass. A strict markup language would make documents easier to parse, and we wouldn't have ended up with the insanity of parsing modern HTML, which became standardized. This, in turn, would have made it easier to expand the language, and integrate different processors into the pipeline. Technologies like XSLT would have been adopted and improved, and perhaps we would have already had proper HTML modules, instead of the half-baked Web Components we have today. All because browser authors were reluctant to force website authors to fix their broken markup. It was a terrible tradeoff, if you ask me.
So, sure, feel free to not close HTML tags if you prefer not to, and to "educate" everyone that they shouldn't either. Just keep it away from any codebases I maintain, thank you very much.
To be fair, I don't mind not closing empty elements, such as `<img>` or `<br>`. But not closing `<p>` or `<div>` is hostile behavior, for no actual gain.
Img and br are not allowed to be closed.
Worse, due to the aforementioned permissive error handling in HTML parsers, a closing </br> tag will end up inserting a second line break
You close them in the same tag:
This syntax is ignored in HTML. The / is thrown away and has no effect.
This non-closing talisman means that <div/> or <script/> are not closed, and will mess up nesting of elements.
1 reply →
Wrong.[1]
> if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS character (/)
If you're going to be pedantic, at least be correct about it.
[1]: https://html.spec.whatwg.org/multipage/syntax.html#start-tag...
You left out the rest of the spec:
> On void elements, it does not mark the start tag as self-closing but instead is unnecessary and has no effect of any kind. For such void elements, it should be used only with caution — especially since, if directly preceded by an unquoted attribute value, it becomes part of the attribute value rather than being discarded by the parser.
(The void elements are listed here: https://developer.mozilla.org/en-US/docs/Glossary/Void_eleme... )
1 reply →
There can't however be a separate closing tag, which is a reasonable interpretation of the post you are replying to
For ebook production, you need to use xhtml, the epub standard is defined that way. And it is indeed useful to be able to treat them as xml files and use xslt and xquery, etc. with them.