Jake Archibald📝 The case against self-closing tags in HTML
At best, they're a relic from the past, and at worst, they're actively misleading.
https://jakearchibald.com/2023/against-self-closing-tags-in-html/
Some folks suggested that 'explicit' self-closing tags are faster to parse, so I added a section on that. If anything, they're slower to parse. https://jakearchibald.com/2023/against-self-closing-tags-in-html/#it-makes-the-markup-faster-to-parse
Roma Komarov@jaffathecake As I did mention “parse” in my comment, I think I need to clarify that I meant only human readability, not the actual HTML parser :)
That said, I think the best way forward would be for tools like prettier to fix the `<div />` cases (and browsers to complain about these in one way or another), just so we would handle the actual problems and won't have to argue about the personal preferences.
Christopher Mardell@kizu @jaffathecake I’m inclined to agree on the human-parsing thing. Even if the browser doesn’t care, I tend to see a tag as open until I see a slash. Reminds me of this: https://xkcd.com/859/
@chrismardell @kizu sure, but only because you've internalised that /> means "closed", even though it doesn't.
You could just as easily internalise that > at the end of an img tag means "closed".
@jaffathecake @kizu sure, I could internalise it that way, but I choose not to because I like the consistency of a-slash-for-every-tag too much. 🙂
joshhunt@jaffathecake why do people care so much about this either way? This seems like a non-issue?
kapowaz@joshhunt @jaffathecake genuinely wondering this too. Feels like another one of those ‘performance’-related sealioning debates some standards wonks love so much.
@jaffathecake @joshhunt no, I know; but you know the kind of debate I’m talking about: “Don’t nest your selectors! Use classnames not element selectors!” - where the difference in parsing times is dwarfed by other factors.
@jaffathecake @joshhunt I’d say JSX has enough quirks that distinguish it from HTML that it needs to be treated separately anyway. There doesn’t need to be one universal rule covering both.
@joshhunt @jaffathecake (I admire the level of attention you put into these articles fwiw Jake, but as you point out, JSX isn’t HTML, and a competent dev can adapt)
keithamus@joshhunt @jaffathecake I think because the “issue” is simple enough to understand (at least on a surface level) and prevalent enough to impact everyone (even if the impact is minuscule). So you get opinions from a large audience. In other words people care because it’s a thing they can care about.
@keithamus it seems like a very “rearranging the deck chairs on the sinking titanic” deal 😅
Ben Ramsey@joshhunt @keithamus I think people care about it because it was very important for strict XHTML.
With HTML 5, the closing tags are no longer necessary, and there’s no longer any XML serialization of HTML, but old habits die hard.
@ramsey @joshhunt My point was, you don’t see the same level of debate in, say, web crypto issues about adding chacha20 poly1305 though. Issues filed and blog posts written, but my social media feeds are not abuzz about the pros and cons. It’s also important, arguably more so, but people tend to gravitate not to what’s important but to what they have opinions on.
Kir Belevich@jaffathecake <br> is just too convenient and easy example.
Let's better talk about more dangerous HTML "loose mode" mess:
https://www.w3.org/TR/2014/REC-html5-20141028/syntax.html#optional-tags
"An li element's end tag may be omitted if the li element is immediately followed by another li element or if there is no more content in the parent element."
Such tricky conditions is a nightmare from SAX parsers perspective. HTML parser becomes a complex look-ahead-go-back-just-in-case SAX deviation with vaguely implied logic.
mantish@jaffathecake I was in the "it makes it more readable" camp, but you make a very good point against it
Priit Pirita@jaffathecake I do agree with your blogpost 100%
Matt Wilcox@jaffathecake I have never liked self-closing behaviour and a "self closing tag" is a neat way for me to know "I opened the thing, and the thing is now closed".
The problem is there shouldn't BE self closing tags.
Open a tag, close a tag. Even if it has no content.
Consistency matters to my brain, and a list of separate tags you don't need to close hurts it.
@jaffathecake I suspect that's why this persists.
"I open a thing, I close the thing".
It's just a good pattern. And HTML's design sure doesn't need that - but that's the problem. We want symmetry. Conceptually.
gtb@jaffathecake I'm in "to me self-closing looks pretty" clan 😄
Also, you missed one more case.
I'm working with Vue a lot. In Vue component can have a slot and don't have it.
I.e. `<error />` could just print a default error message and `<error>Error message</error>` would display a custom error message.
I'm for consistency and for Vue templates self-closing HTML tags is good for consistency.
Perfectly valid case IMO, since you bring up JSX.
Doug Parker 🕸️@jaffathecake 🙋 I was absolutely one of those "always explicitly close empty tags" people because it meant you didn't need to memorize which tags were self closing.
But learning now that the `/>` doesn't actually do anything and still relies on self-closing behavior has made me repent my sinful ways. 🙏
Marc Etienne@develwithoutacause @jaffathecake yeah, it's purely aesthetic. Like you note, it's only for humans.
I am inconsistent, I admit. I'll use them when working with Java devs, but not on pure Frontend code or PHP code. And otherwise just trust Prettier to clean up after me.
@fnordius @develwithoutacause they're only for humans… except in the cases where they aren't 😀
That's why I'd prefer to only use them when they effect the tree.
Luke B@jaffathecake you make some very pragmatic points there.
But as someone who started web development in the 2000s, I know web tech can be summarised as:
* 1990s - old fashioned & inconsistent
* 2000s - new & exciting
* 2010s - overly complicated bloatware
* 2020s - scary & unnatural
Therefore, I propose we only support 2 formats on the web: XHTML and RDF.
Ondřej Žára@jaffathecake Nicely written. Eventhough the surgeon xml parsing is a false dilemma. Surely the surgeon would either check their page before publishing it, or - more probably - use a publishing system that guarantees valid xhtml output.
@ondras I based the failing example on a real page that was serving with the XHTML doctype.
@ondras I based the failing example on a real page that was serving with the XHTML doctype.
@jaffathecake sounds like a misconfiguration or a backwards-incompatible change in a system that has been working correctly before. I find it hard to believe that a page would have been created that never displayed correctly and noone was bothered/notified about it.
Elis HIrwing 🌱> I wouldn't try and write JSON so it can be parsed by a YAML parser, so I don't see why I'd do the same with HTML and XML.
Joke's on you here! Because it doesn't matter how you format a valid json document, a YAML parser will parse it regardless 😉
Potch@jaffathecake the volume of "only <derogatory term> people would think <various contradictory things>" in your comments
@potch I haven't had a proper look yet, but I saw a couple fly past. I keep meaning to prevent comments on future posts
@jaffathecake not on you! Just telling as to one of the prevailing attitudes and clear they read right past the "scare away the newcomers" jab in your post
Amikke@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.
@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.
@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.
Claudio Cicali@jaffathecake Oooh I Iove that topic. I also wrote about it some months ago https://claudio.cica.li/posts/2022/self-closing-tags/
Jack Yan (甄爵恩)@jaffathecake Thank you, Jake, thatʼs very useful.
Braw ☕🏳️🌈@jaffathecake okay you really convinced me here
… that I hate web development xD
Louis Ingenthron@jaffathecake Having started coding in the early 2000s, I use self-closing syntax like dogma.
But I hadn't realized just how pointless and unsupported it had gotten... Do browsers even use it as a hint to behaviour with HTML5 or do they just discard it entirely as meaningless?
But I hadn't realized just how pointless and unsupported it had gotten... Do browsers even use it as a hint to behaviour with HTML5 or do they just discard it entirely as meaningless?
@LouisIngenthron just discarded
@jaffathecake Thanks for the write up! I liked self-closing tags aesthetically (maybe a psychological about there not being a tag open without it being explicitly closed [1]) but after reading through this post I think I'll be avoiding them in the future.
Sandrine@jaffathecake I actually like self-closing tags, it keep things neat.
I did read the article and aside that it can be misleading for people that would assume a consistency of JSX, I don't agree for the cases against, even in responses of this post.
1. I don't care about JSX and what assumptions people could possibly make based on their stack.
This is the web, content is king, HTML first as foundation, everything else later.
2. Prettier and other compilation tools are not my concern.
3. Only tags with content have closing tags, which make sense.
4. I reckon all tags should close.
5. Therefore self-closing tags for elements that do not have content but only value through attributes make sense.
It's clean, strict, consistent, helping juniors to be familiarised with tags and their difference and IT IS PRETTY !!! 😂
@fedbysandrine hm, but there are plenty of tags that feel contentless, but can't self-close, eg <iframe>
@jaffathecake Not really. Iframe does render content in source code, iframe is a wrapper.
Not an element like input, br or hr.
Not an element like input, br or hr.
@jaffathecake That said, it comes to developer preference.
I always said if you can argument it, then you have a case.
I used to use xhtml strict, because it forced me to be very strict on my code, but I allowed myself to not pass validator on target="_blank".
I'd rather be strict and have that one only not meeting the criteria, but I knew why.
Here it's the same. HTML5 is not xHTML, as long that it doesn't actually create impact on rendering, to each their own to weight the pros and cons. :)
I always said if you can argument it, then you have a case.
I used to use xhtml strict, because it forced me to be very strict on my code, but I allowed myself to not pass validator on target="_blank".
I'd rather be strict and have that one only not meeting the criteria, but I knew why.
Here it's the same. HTML5 is not xHTML, as long that it doesn't actually create impact on rendering, to each their own to weight the pros and cons. :)
@fedbysandrine iframe and the others are "replaced content"
John Manoogian III@jaffathecake sigh the web is a prison lol feels like we will never be free of this junk
Gil Tayar@jaffathecake Uh... any JSON is a valid YAML, so "I wouldn't try and write JSON so it can be parsed by a YAML parser" doesn't make sense ☺️.
Great post! Learned a lot about how HTML parses self-closing tags, ie it ignores them. I did not know that, and I suspect most people don't either. Given that, I agree with what you said about tools not outputting them.
Zitrone@jaffathecake yeah, last paragraph! im 100% in: /> should always be selfclosing. i'd love to see <iframe /> for example.
i am in the readability-camp. in my experience it really does speed up seeing things.
and i want to add: your newcomer-point doesn't fully count. because what they also do is </img>. (sure doesn't cause problems as <div/>, but you argue on learning due to the lack of consistency.)
i am in the readability-camp. in my experience it really does speed up seeing things.
and i want to add: your newcomer-point doesn't fully count. because what they also do is </img>. (sure doesn't cause problems as <div/>, but you argue on learning due to the lack of consistency.)
Bob Dendry has moved!@jaffathecake
My sole opinion on this as an amateur-at-best HTML tinkerer is that they're fugly, and thus bad.
My sole opinion on this as an amateur-at-best HTML tinkerer is that they're fugly, and thus bad.
Mladen@jaffathecake I'm personally a fan of XML and so I like closing tags. It just looks weird when they're not there.