6 ms·
Serious question: why would you ever want to not close tags? It saves a couple of key strokes, but we have snippets in our editors, so the amount of typing is t
by HiPhish 9mo ago
Serious question: why would you ever want to not close tags? It saves a couple of key strokes, but we have snippets in our editors, so the amount of typing is the same. Closed tags allow editors like Vim or automated tools to handle the source code easier; e.g. I can type `dit` in Vim to delete the contents of a tag, something that's only possible because the tag's content is clearly delimited. It makes parsing HTML easier because there are fewer syntax rules.
I learned HTML quite late, when HTML 5 was already all the rage, and I never understood why the more strict rules of XML for HTML never took off. They seem so much saner than whatever soup of special rules and exceptions we currently have. HTML 5 was an opportunity to make a clear cut between legacy HTML and the future of HTML. Even though I don't have to, I strive to adhere to the stricter rules of closing all tags, closing self-closing tags and only using lower-case tag names.
- vbezhenar 9mo ago> why would you ever want to not close tags? Because browsers close some tags automatically. And if your closing tag is wrong, it'll generate empty element instead of being ignored. Without even emitting warning in developer console. So by closing tags you're risking introducing very subtle DOM bugs. If you want to close tags, make sure that your building or testing pipeline ensures strict validation of produced HTML.
- pwdisswordfishy 9mo ago> I never understood why the more strict rules of XML for HTML never took off Internet Explorer failing to support XHTML at all (which also forced everyone to serve XHTML with the HTML media type and avoid incompatible syntaxes like self-closing <script />), Firefox at first failing to support progressive rendering of XHTML, a dearth of tooling to emit well-formed XHTML (remember, those were the days of PHP emitting markup by string concatenation) and the resulting fear of pages entirely failing to render (the so-called Yellow Screen of Death), and a side helping of the WHATWG cartel^W organization declaring XHTML "obsolete". It probably didn't help that XHTML did not offer any new features over tag-soup HTML syntax. I think most of those are actually no longer relevant, so I still kind of hope that XHTML could have a resurgence, and that the tag-soup syntax could be finally discarded. It's long overdue.
- xg15 9mo agoWhat I never understood was why, for HTML specifically, syntax errors are such a fundamental unsolvable problem that it's essential that browsers accept bad content. Meanwhile, in any other formal language (including JS and CSS!), the standard assumption is that syntax errors are fatal, the responsibility for fixing lies with the page author, but also that fixing those errors is not a difficult problem. Why is this a problem for HTML - and only HTML?
- nicoburns 9mo agoIt's mostly historical. Browsers accepted invalid HTML for 10 years, there's a lot of content authored with that assumption that's never going to be updated, so now we're stuck with it. We could be more strict for new content, but why bother if you have to include the legacy parser anyway. And the HTML5 algorithm brings us most of the benefits (deterministic parsing) of a stricter syntax while still allowing the looseness.
- londons_explore 9mo ago> never going to be updated, so now we're stuck with it. Try going to any 1998 web page in a modern browser... It's generally so broken so as to be unusable. As well as every page telling me to install flash, most links are dead, most scripts don't run properly (vbscript!?), tls versions now incompatible, etc. We shouldn't put much effort into backwards compatibility if it doesn't work in practice. The best bet to open a 1998 web page is to install IE6 in a VM, and everything works wonderfully.
- afavour 9mo agoThe vast majority of pages from 1998 work fine today. VBscript was always a tiny minority of scripting. And link rot is an undeniable problem but that’s not an issue with the page itself.
- Kwpolska 9mo agoYou’re unlikely to find a 1998-era Web page still running a 1998-era SSL stack. SSL was expensive (computationally and CA-cartel-ically), so basically banks and online shopping would have used SSL back then.
- bazoom42 9mo agoWhy did markdown become popular when we already have html? Because markdown is much easier to write by hand in a simple text editor. Original SGML was actually closer to markdown. It had various options to shorten and simplify the syntax, making it easy to write and edit by hand, while still having an unambiguous structure. The verbose and explicit structure of xhtml makes it easier to process by tools, but more tedious for humans.
- oneeyedpigeon 9mo agoIs it really that much easier to write `<br>` and know that it isn't a problem, than just write `<br />`?
- barnabee 9mo agoIt’s much easier to have to remember fewer rules and for things to be ok if you get some wrong, yes. Especially for casual users of HTML.
- epgui 9mo agoBad reasoning. “Always close your tags” is a simpler rule (and fewer rules, depending how you count) than “Close your tags, except possibly in situations A, B, C…”.
- intrasight 9mo agoI've been closing my tags for 30 years and I assume that I will for the rest of my days. I like that it validates as XML. Historically I used XSLT a LOT.
- eastbound 9mo agoIt triggers the linters so often. I shall keep my <input> tag open.
- TZubiri 9mo ago
- onion2k 9mo agoIn the case of <br/> and <img/> browsers will never use the content inside of the tag, so using a closing tag doesn't make sense. The slash makes it much clearer though, so missing it out is silly.
- jakelazaroff 9mo agoHow does the slash make it clearer? It's totally inert, so if you try to do the same thing with a non-void tag the results will not be what you expect!
- onion2k 9mo agoIt indicates that the content that follows is not inside of the tag without the reader needing to remember how HTML works. Tags should have either a self-closing slash, or a closing tag. The third way of a bare tag is where the confusion comes from.
- jakelazaroff 9mo agoIt doesn't indicate that, though. If you write <div />, for example, the content that follows is inside of the tag. So the reader still needs to remember how HTML works, because the slash does nothing.
- jraph 9mo agoContrary to <img /> or <br />, <div /> is necessarily a mistake or intentionally misleading. The unfamiliar reader should not stumble upon <div /> too often. <div /> is a bug. It's a bit like using misleading indentation in C-like programming languages. Yeah, it can happen, and is a source of bugs, but if the page is well written, the regularity of having everything closed, even if it's decorative for the spec, can help the unfamiliar reader who doesn't have all the parsing rules in mind. Now, we can discuss whether we should optimize for the unfamiliar reader, and whether the illusion of actual meaning the trailing slash in HTML5 can be harmful. I would note that exactly like trailing slashes, indentation doesn't mean anything for the parser in C-like languages and can be written misleadingly, yet we do systematically use it, even when no unfamiliar reader is expected. At this point, writing a slash or not and closing all the tags is a coding style discussion. Now, maybe someone writing almost-XHTML (closing all tags, putting trailing slashes, quoting all the attributes) should go all the way and write actual XHTML with the actual XHTML content type and benefit from the strict parser catching potential errors that can backfire and that nobody would have noticed with the HTML 5 parser.
- MarsIronPI 9mo agoBecause I want my hand-written HTML to look more like markdown-style languages. If I close those tags it adds visual noise and makes the text harder to read. Besides, at this point technologies like tree-sitter make editor integration a moot point: once tree-sitter knows how to parse it, the editor does too.
- kbolino 9mo agoA lot of HTML tags never have a body, so it makes no sense to close them. XML has self-closing tag syntax but it wasn't always handled well by browsers. A p or li tag, at least when used and nested properly, logically ends where either the next one begins or the enclosing block ends. Closing li also creates the opportunity for nonsensical content inside of a list but not in any list item. Of course all of these corner cases are now well specified because people did close their tags sometimes.
- afavour 9mo ago> A p or li tag, at least when used and nested properly, logically ends where either the next one begins or the enclosing block ends While this is true I’ve never liked it. <p>blah<p>blah2</p> Implies a closing </p> in the middle. But <p>blah<span>blah2</p> Does not. Obviously with the knowledge of the difference between what span and p represent I understand why but in terms of pure markup it’s always left a bad taste in my mouth. I’ll always close tags whenever relevant even if it’s not necessary.
- kbolino 9mo agoThis interpretation of the p element implies that it contains a paragraph. But HTML is first and foremost a document format, and one could just as logically conclude that the p element simply starts a new paragraph. Under the latter interpretation, </p> would never exist any more than </hr> or </img>. In practice, modern HTML splits the difference with rigorous and well defined but not necessarily intuitive semantics.
- Pxtl 9mo ago> XML has self-closing tag syntax but it wasn't always handled well by browsers. So we'll add another syntax for browsers to handle. https://xkcd.com/927/ https://xkcd.com/927/
- deleted 9mo ago[deleted]
- 9mo ago
- coffeefirst 9mo agoI would argue the stricter rules did take off, most people always close <p>, it's pretty common to see <img/> over <img>—especially from people who write a lot of React. But. The future of HTML will forever contain content that was first handtyped in Notepad++ in 2001 or created in Wordpress in 2008. It's the right move for the browser to stay forgiving, even if you have rules in your personal styleguide.
- Wowfunhappy 9mo agoImagine if you were authoring and/or editing prose directly in html, as opposed to using some CMS. You're using your writing brain, not your coding brain. You don't want to think about code. It's still a little annoying to put <p> before each paragraph, but not by that much. By contrast, once you start adding closing tags, you're much closer to computer code. I'm not sure if that makes sense but it's the way I think about it.
- SoftTalker 9mo agoIt's honestly no worse than Markdown, reST, or any of the other text-based "formats." It's just another format. Any time I have to write Markdown I have to open a cheat sheet for reference. With HTML, which I have used for years, I just write it.
- ndiddy 9mo ago> I learned HTML quite late, when HTML 5 was already all the rage, and I never understood why the more strict rules of XML for HTML never took off. They seem so much saner than whatever soup of special rules and exceptions we currently have. XHTML came out at a time when Internet Explorer, the most popular browser, was essentially frozen apart from security fixes because Microsoft knew that if the web took off as a viable application platform it would threaten Windows' dominance. XHTML 1.1 Transitional was essentially HTML 4.01 except that if it wasn't also valid XML, the spec required the browser to display a yellow "parsing error" page rather than display the content. This meant that any "working" XHTML site might not display because the page author didn't test in your browser. It also meant that any XHTML site might break at any time because a content writer used a noncompliant browser like IE 6 to write an article, or because the developers missed an edge case that causes invalid syntax. XHTML 2.0 was a far more radical design. Because IE 6 was frozen, XHTML 2.0 was written with the expectation that no current web browser would implement it, and instead was a ground-up redesign of the web written "the right way" that would eventually entirely replace all existing web browsers. For example, forms were gone, frames were gone, and all presentational elements like <b> and <i> were gone in favor of semantic elements like <strong> and <samp> that made it possible for a page to be reasoned about automatically by a program. This required different processing from existing HTML and XHTML documents, but there was no way to differentiate between "old" and "new" documents, meaning no thought was given to adding XHTML 2.0 support to browsers that supported existing web technologies. Even by the mid-2000s, asking everyone to restart the web from scratch was obviously unrealistic compared to incrementally improving it. See here for a good overview of XHTML 2.0's failure from a web browser implementor's perspective: https://dbaron.org/log/20090707-ex-html https://dbaron.org/log/20090707-ex-html
- dragonwriter 9mo ago> I never understood why the more strict rules of XML for HTML never took off. Because of the vast quantity of legacy HTML content, largely. > HTML 5 was an opportunity to make a clear cut between legacy HTML and the future of HTML. WHATWG and its living standard that W3C took various versions of and made changes to and called it HTML 5, 5.1, etc., to pretend that they were still relevant in HTML, before finally giving up on that entirely, was a direct result of the failure of XHTML and the idea of a clear cut between legacy HTML and the future of HTML. It was a direct reaction against the “clear cut” approach based on experience, not an opportunity to repeat its mistakes. (Instead of a clear break, HTML incorporated the “more strict rules of XML” via the XML serialization for HTML; for the applications where that approach offers value, it is available and supported and has an object model 100% compatible with the more common form, and they are maintained together rather than competing.)
- mgr86 9mo agoI'd argue XHTML did take off and was very widely adopted for the first 5-10 years of the century.
- pests 9mo agoFrom a recent HN post, ePub's are technically XHTML by spec.
- mgr86 9mo agoYes, that is an important point. I guess I was focused mainly on the browser. Which is not the typical way to consume epubs. But you are right that ePubs are essentially packaged XHTML.
- dragonwriter 9mo agoEPUB 3.x spec uses “XHTML” to refer to the XML serialization of HTML in the current WHATWG HTML living standard, not the separate historical standard from HTML known as XHTML. The obsolete EPUB 2.x (and earlier, I believe) specs actually used XHTML (XHTML 1.1 in EPUB 2.x), though.
- jrm4 9mo agoThis really does feel like a job for auto-complete -slash- Generative ai tools.
- vimax 9mo agoI built a testing framework, and I wanted it to generate HTML reports during testing with not post-processing report compilation step. I wanted the html in real-time so if a test was cut short for any reason from killing the job to power failure, you'd have a readable html report showing where things stopped. I could do this by just appending divs as rows without closing any of the parent divs, body or html tags. So the more general answer, anytime you want to continuously stream html and not want to wait until the end of the document to begin rendering.
- interactivecode 9mo agoFor the same reason css still works if you make a typo and javascript super dynamic: its a friendly interface. Html, css and js got used so much because you could mess around and still get something to work. While other languages that people use to write “serious” applications just screamed at you for not being smart enough to know how to allocate memory correctly. Html and css is not a competitor to C. Its more like an alternative to file formats like txt or rtf. Meant to be written by hand in a text editor to get styled pages. So easy and forgiving your mom could do it! (And did, just like everyone else in the myspace days)