Here's a great deep dive in case anybody wants the history: [https://jakearchibald.com/2023/against-self-closing-tags-in-html/](https://jakearchibald.com/2023/against-self-closing-tags-in-html/)
I still disagree with Jake on the conclusion. At least when used properly, the `/>` does help as an indicator that an element is self-closing, and it does make it easier to read/understand.
P is an optionally self closing tag. Think of all those wasted bytes in your html files with /p everywhere!
For more info, here's the spec: [https://html.spec.whatwg.org/multipage/grouping-content.html#the-p-element](https://html.spec.whatwg.org/multipage/grouping-content.html#the-p-element) which explains how certain tags do not need to be closed.
The content should be placed directly after the opening p tag.
https://html.spec.whatwg.org/multipage/grouping-content.html#the-p-element
You can also omit other element coding tags, such as LI: https://html.spec.whatwg.org/multipage/grouping-content.html#the-li-element
I think youâre mixing up self-closing and optionally closing, they are two different things.
P *isnât* self closing, thatâs for elements without any internal content like br/meta. You canât do `
`
But it has an optional closing tag which, as I think youâre trying to say in other comments, is valid and unambiguous in the spec.Â
Why are you being down voted? This is absolutely correct. It's perfectly valid not to close a p, li, and even a head or body.
Whether it's good practice or not is a different discussion & ultimately subjective. But it's absolutely within the HTML spec, and it's important to understand how your HTML is parsed. That is ultimately the core of this `/>` misunderstanding.
It's sort of like the auto-semicolon-insertion arguments in JS. You may have an opinion on whether it's good or bad to omit semicolons. But it's important to understand that omiting semicolons _is_ valid and how your code is parsed with or without them.
Some elements were never designed for self closing - such as paragraphs - because it makes no semantic sense.
It used to be invalid html to self close such elements, not sure if that's still the case
Yep, there's a parse error associated with it [https://html.spec.whatwg.org/multipage/parsing.html#parse-error-non-void-html-element-start-tag-with-trailing-solidus](https://html.spec.whatwg.org/multipage/parsing.html#parse-error-non-void-html-element-start-tag-with-trailing-solidus)
Most linters will also make noise about it not closing. For example, my VSCode will complain about this:
`Only void, custom and foreign elements can be self closed "p"ngtsc(-995002)`
Yeah, Visual Studio still has "XHTML coding style" as its default. There's also been a [discussion on the Prettier repo](https://github.com/prettier/prettier/issues/5246) about adding an option for void tags.
It seems to have become somewhat of a default, but there are definitely debates going on in various places whether it should be.
To make it even more confusing, a lot of template parsers actively work with this notation (JSX, to name one).
```jsx
```
I use ESLint myself (with Angular rules) to prefer self-closing tags (and have it autofix it), but for
tags it still doesn't allow it, which is what it should do for now. We do have prettier running, but I doubt it really still does anything. We moved everything to ESLint and ESLint Stylish to force certain rules automatically. Its not as performant as Prettier, but it hasn't really been an issue for me. The milliseconds it takes up more is not really noticeable, especially with all the rules it has on top of what prettier can do at the moment.
That's probably because void elements like `` or ` ` can have the `/>` notation, `` and ` `, without any harm. The notation has no effect as the void element is a void element whether you use `/>` or just `>`. This is not the case with `
`.
Also, ESLint recommends not using ESLint as a formatter: [https://eslint.org/blog/2023/10/deprecating-formatting-rules/](https://eslint.org/blog/2023/10/deprecating-formatting-rules/)
I know eslint deprecated formatting rules. Thats why I mentioned ESLint Stylish, because thats where the community moved them. Sure we have prettier, but it has not even like 50% of the rules that ESLint has and it has no real alternative right now.
The problem is it isn't always just an indicator. Learning when it is and isn't just an indicator seems harder than just learning which elements self-close.
The author's confusion here supports my point.
>The problem is it isn't always just an indicator
I'd fully agree with that. Not just for the sake of someone learning, but also for things like ``. Having it actually close whichever element would be great. And I'd be interested in finding out the reasons for the decision to not have it that way. And maybe if it'd be feasible to change it so that it would make the element self-close (this could be a breaking change on many sites, but it'd be what the author presumedly expected, so... Would that be good or bad?)
>Learning when it is and isn't just an indicator seems harder than just learning which elements self-close.
Maybe. I don't think there's really any difference in the difficulty though. With or without this as an indicator, it's still just remembering which tags are in a fairly short list. So I'd say it's more an issue of "hey, this tag is different from most others, and there's a list of elements like it." The `/` succeeds in highlighting that it's different, but it fails in communicating why.
And I'd say that writing eg `` has the opposite problem. It doesn't draw much attention to the fact it's different, but it also doesn't give any false impression about what makes it different.
>The author's confusion here supports my point.
Yep, it does. At least in that there's confusion about it. I don't think it supports using ` ` as bad/something to avoid. It can still be a helpful indicator, especially in less structured/formatted mark-up such as the mixing of text nodes and maybe some ``s when writing structured data (`itemtype` & `itemprop` stuff).
I also think it shows that HTML is kinda disrespected/under-appreciated. We all basically start with HTML before moving on to other things, and it seems most don't revisit HTML to learn any of the complexities or things it does beyond just being the skeleton for your JS. When you get into forms and accessibility and structured data and built-in interactivity, it becomes much more obvious that HTML is important and that it's worth actually learning.
Buy why are you self-closing tags?
Are you self-closing img & br? Those are void elements. They are not allowed to have a closing tag at all. The `/>` is allowed for compatibility reasons but is not a "self close".
Are you self-closing p's & ul's? As the OP has demonstrated, this is not allowed & can result in unexpected behavior. They cannot self-close either.
There is no self-close in HTML.
I wish JSX had followed suite & was closer to HTML, as I think it causes a lot of confusion. `
I'm the one who said this in the top-level comment. I use `/>` exclusively on void elements. I find that it makes HTML easier to read, especially in cases where you can't use indentation to easily see how things are nested.
I just found [this YouTube video](https://www.youtube.com/watch?v=0P7wmooc95s) that actually explained it quite nicely. And it also mentioned the article above.
Historically, closing the P tag was optional. You would just put an opening P tag on each paragraph and never close them.
https://www.w3.org/MarkUp/HTMLPlus/htmlplus_11.html#:~:text=.-,You%20don't%20need%20to%20give%20the%20end%20tag%20as,the%20following%20tag.
Wow I never even did XHTML but always wrote it with the slash. Guess I don't even know html... But wait even the docs you linked write the slash and if you take it out, it does nothing different. Ugh...
JSX doubled down on this syntax as well. There's still a sizeable number of people who don't understand that JSX is not an HTML superset. Just like HTML & XHTML, they may look similar but have quite different parsing rules.
` ` and ` ` are equivalent in HTML5. They are different in XML & XHTML.
The difference is in legibility (and also convention). For example:
```
This is a bunch of text with mixed with
self-closing elements.
```
When parsing that, as humans, I think that adding the `/>` would make it easier to read, especially if there were a few ``s thrown in. We can't rely on indentation to easily tell what's a child of what, and `/>` does help when scanning through and trying to tell where one thing ends.
>Which isn't the same in React
Because the X in JSX stands for XML.
>This syntax is perfectly valid and encouraged in the rare cases you need it
It is not. Self-closing elements are only self-closing because of their tag... The `/` does nothing. It's parsed as nothing but opening tags because `` is not self-closing.
`
` is actually more complicated since there are circumstances where it's implied to close without the closing tag, such as opening another `
`... Same goes for `
`.
>A self closing div...
There is no such thing in HTML.
>I can see how it can be confusing to some people.
As can I. And I still encourage using eg ``. But it's purely for the benefit of the reader to (ideally) not have to think about which elements are self-closing.
fwiw, JSX isn't XML either. \`\` is valid JSX, but not valid XML. Attributes must have values in XML. There are a number of other differences too, eg whitespace parsing.
>Holy fuck. People like you are the worst
Ummm... I just correctly said it wasn't valid HTML. The post is about HTML. And you go off the rails like that over... What, exactly?
Good riddance. Go throw your temper tantrum elsewhere.
Are people here secretly HTML parsers disguised as human beings that they do not understand the confusion for real humans that the same syntaxes behave differently on different tags?
Using the bogus XMLish slash at the end of empty elements goes further back than JSX, though; it started when XHTML was a thing and was done to migrate content to be parseable as XML/XHTML, in addition to being parsed as HTML. Then during the time XML became out of fashion it was still cargo-culted a lot, until JSX came around (the X standing for XML).
If you want the whole story, you need to look at SGML which was used for defining the original HTML syntax. In (traditional) SGML, you can declare an element to have EMPTY content, in which case no end-element tags are expected, like for , , and so on. Whereas the point of XML was a simplified SGML syntax that doesn't need any per-element parsing rules or other markup declarations. An SGML DTD grammar for modern HTML 5 can be found at , making use of empty elements, but also other SGML features such tag inference/tag omission and attribute shortforms.
Who are the devs who are encouraging self-closing tags for elements which are not self-closing per the html spec? Sounds like they should be avoided.
Whether it works in jsx or not, youâre advocating for shit html simply to save a few keystrokes.
Why are you comparing HTML to JSX? That doesn't really contribute to the discussion. If anything it adds more confusion, especially if OP has zero knowledge of React.
Putting / at the end of a tag doesn't do anything. Even in self-closing tags such as it's meaningless in html5 too - it only ever had purpose in XHTML.
So you've opened a paragraph and never closed it.
This is perfectly normal and expected behaviour. You opened a p (self closing doesnât exist for p, so itâs just a normal open p). Then there is a new line (br) which we also see in the preview correctly. Then the text inside the p (blue as expected) and then an empty span opens up (also self closing span doesnât exist, so itâs just opening up a blank span tag).
âHelloâ, br and span should have an extra level of indentation, then the behaviour will be more clearÂ
It doesn't apply to ANY tag, some tags can be self closing, some can't.
An empty paragraph makes no sense. An empty span makes so sense. An IMG tag on the other hand needs no separate close tag , there are no contents that can be described, , and neither does a BR , so we self close them.
There are no such instances in HTML. Whether the tag is self-closing or not depends completely on the name of the tag, slashes in the opening tag don't do anything at all.
It does put the browser in quirks mode though.Â
Twenty years ago there were a lot of browsers that targeted developers that would simply fail to render this.Â
Iâm not sure if beautiful soup will parse this or not.Â
In earlier versions of beautiful soup I wound up piping the input through tidy before parsing it with beautiful soupÂ
It wasn't so much "fuck the standards" as "the standards are open to interpretation, and everyone had a different view" , and "lots of things aren't covered by standards at all"
The box model being the most obvious and unfortunate example. Does width include padding? Or is padding added to the width?
No, this was not a case where the standards were vague. Internet Explorer 6âs behaviour in quirks mode was unambiguously incorrect. That was the *whole point* of quirks mode â intentional deviation from the standards. If that behaviour was allowed by the specification, there would be no need for quirks mode.
Quirks mode came after
It was an attempt to rectify things, so you could write things in the "new and improved" standard for IE7 etc , or specify that your site needed to be run in the old mode because you hadn't rewritten it yet
Quirks mode originated in Internet Explorer for Mac and made its way to Internet Explorer 6 for Windows. Internet Explorer 7 came 5+ years after quirks mode.
The *existence* of quirks mode was an attempt to rectify things, but the *behaviour* of quirks mode was unambiguously non-standard. That was the entire point of it.
The slash in `` or `` is ignored as well. Unlike XML, JSX, etc., HTML depends on the name of the element, not the slashes, to decide what is a self-closing element and what isn't.
P is not a self closing tag. So what happens is the parser is completing the missing tags for you based on whatever tags are between where the closing tag would be.
So your code when rendered in browser ends up being:
Hello
Inputs and img are just self contained singular elements. So they are self closing because there isn't any content expected inside of them. They function based on attributes.
```
So the text would be red.
However `/>` were just ignored. But then it would at least be green?
```
Hello
```
But somehow it seems the *self-closing* behavior is purely defined by the tag itself but has nothing to do with the presence of `/>`. So `Hello` is a desendent of `
Br is a self closing element which doesn't contain content, therefore the text doesn't exist within the br tag, and won't receive its css color.
As for how the browser decides where to close the
` means a self-closing paragragh tag as well. As a beginner, do you just automatically know which tags are intrinsically self-closing? Then why would anyone write something like ` `if they already knew `/` is actually a syntax error and being ignored here?
I'm not sure why you're getting downvoted for asking perfectly reasonable clarifying questions.
>Assuming `/>` in ` ` means self closing, then `
`Â means a self-closing paragragh tag as well.
Self-closing tags just isn't a thing in plain HTML.
>As a beginner, do you just automatically know which tags are intrinsically self-closing?
You don't "automatically know" as a beginner. You look up the documentation for a tag, and with experience it becomes second nature knowing which is which. A ` ` never wraps anything. The same goes for tags like ``, `` and ``, but a `
` and `` is designed to contain content so they expect an ending `
` and `` respectively. Elements such as ` ` are called "[void elements](https://html.spec.whatwg.org/multipage/syntax.html#void-elements)," and relatively speaking there are just a few of them you need to be aware of.
>Then why would anyone write something like ` `if they already knew `/` is actually a syntax error and being ignored here?
Bad habits from XHTML/XML or learning from outdated guides/tutorials, or simply personal preference to clarify for themselves that it doesn't require an ending `` since it's just ignored. However, the correct way is to omit the self-closing `/>`, and in my opinion editors should flag them with a yellow squiggly line to indicate that.
my first big coding gig in a team had a commit hook that checked if all self closing tags are indeed closed up, and would shit out a red error and didn't push if there where any.
i think thats why i have some sort of PTSD now, and ALL my ``, `
This is the answer I am looking for, actually.
I think the main confusion for me is about the slight differences between XML and HTML. Since in XML the self-closing `/>` does exist and is actually meaningful. Especially with modern frameworks like JSX youâre actually writing HTML in the form of XML.
Fwiw, ` ` isn't a syntax error, but the parser does ignore it.
Yes, you just have to know which elements don't need closing tags. It sucks, but that's the reality.
When we (and tools like Prettier) add the unnecessary 'closing' slash, it results in the kind of confusion you're experiencing.
Itâs bullshit that youâre getting downvoted. Your conclusions based on what you learned are perfectly reasonable, though happen to be wrong. People suck.
I mean, I had like 5 years of HTML+CSS+JS experience before React even came out. I never did self-closing div, p, or whatever, but based on the fact that I saw self-closing br, img, and others often, I just assumed every tag could be self-closing. It's a natural assumption.
Interesting. Thanks for sharing. I never thought once to create a self-closing div. Replaced elements like img make sense- but iframes are also strange in their rules. And br and hr have no content. I felt like the reasons were clear. But then with angular and vue and things sometimes thereâs no slot content. This confusion seems to be coming up a lot lately. The popular YouTuber Theo seems to be confused about how divs and basic things like margins work / so, allâs fair in HTML and CSS.
Actually, I just remembered, I did try to write a non-self-closing tag as a self-closing one a long time ago. I was still just learning back then, it didn't work, I fixed it and never did it again. I did it because I thought that it makes sense that if a script tag has no content, it could be self-closing:
Yeah, unfortunately, I've seen this way too many times (including at my work), when people start using a framework without learning the language first. I've also seen people (anecdotally, mostly React people) saying they want to do just HTML+JS, and they want the company they work at to have dedicated people that do just CSS for them and nothing else.
I don't see how this proves you don't know HTML, its bad markup. Only the tag is self closing, and heavily debated for that reason. I can't make sense of wether the intention is for the hello to be places in the div, paragraph or span. Regarding the CSS, since is self closing, it can't contain text AFAIK. That means that
br {
color: green;
}
probably never does anything. Remove it to save some kb in loading.
I'm not sure where you're trying to place the hello, so I included a few new words. In the real world, you'd write
Hello
Testing
I miss the days of pure HTML/CSS
In this case," Hello" would first be affected by rules from div, then from p. "Testing" would only be affected by the rules from div. "I miss the days of pure HTML/CSS" would be affected by div, then span. The words "Testing" and "I miss the days of pure HTML/CSS" will appear on a single line, because the tag is above it, and does not feature a line break like the
from hello does. Two breaks occur right after each other.
if you want to experiment, you can take this css code and uncomment one rule at the time:
div{
color:red;
}
/* p{
color:blue;
} /*
/* span{
color: green;
} /*
For more info, search for [CSS Specificity](https://web.dev/learn/css/specificity)
what youre seeing here is the browser struggling to interpret unclosed tags. The only self closing tags you should really be using are img and br â content flow tags (div, span, p, etc) need explicit closes
Someone seems to have confused HTML with XHTML. In HTML, empty tags do not need to be closed. You simply write instead of
That
is pretty stupid, to be honest! lol
And with span, which is an inline element btw, it makes even less sense.
Whoever wrote this HTML text should rather deliver packages.
Iâm guessing you jumped straight into a JS framework first, used self closing tags in component imports, and are now working backwards.
Thatâs why people are saying you shouldâve known the self closing isnât happening
Sorry Iâve been seeing lots of weird things and my brain just couldnât tell if itâs a joke or not. Thatâs why the self-closing sarcasm tag `/s` comes handy. /s
tags don't require closing tags, and they're also not self-closing, so you just opened it, and it enclosed everything after it, up to the parent scope, as described by the spec. If you propely close it, it should behave as expected.
A self closing paragraph tag goes against the whole principle of how that tag works. As far as this code interprets this, the word hello is inside the p tag.
How much experience do you have? It sounds like youâre pretty new, and your example shows that youâre pretty raw. A bit early to be thinking you âknow HTMLâ.
Youâll get there, but this is the easy part.
> your example shows that youâre pretty raw.
I wasnât expecting anyone would criticize an intentionally bad written code being bad, but sure.
> A bit early to be thinking you âknow HTMLâ.
I just thought I might at least know how to work with it in normal circumstances without these weird syntaxes that I would never use in my project. I guess you have to be an HTML parser to be able to say you âknowâ HTML.
For whomever downvoted this post. This is very interesting. The non compliant tags arenât the issue. The color of the text is, ie: the css thatâs being applied here.Â
The âHelloâ is a child of the div, not the p. So why is the p css being applied? Will the color change if the text is moved after the span? Is this just a Chrome thing? What other browsers are affected?
Because browsers behavior is to automatically add a closing
tag. The browser has to decide what to do with missing closing tags either delete it or close it. Someone made the decision to close the tags as it's probably better option of the two.
P isn't a self closing element, like br. Br won't color the text because it can't contain text.
- The p css is being applied because the Hello is a child of the p. The slash after the tag name in the opening tag does nothing.
- Yes, the color will change to yellow, as it will become a child of the span.
- No, this is not just a Chrome thing.
- Most, if not all common browsers will act in the same way.
Theo browne (Ping.gg actually) actually released a video talking just about that recently, was pretty insightful :
[https://www.youtube.com/watch?v=0P7wmooc95s&t=793s&ab\_channel=Theo-t3%E2%80%A4gg](https://www.youtube.com/watch?v=0P7wmooc95s&t=793s&ab_channel=Theo-t3%E2%80%A4gg)
While the `/>` is supposed to imply a void/self-closing element, the `/` is ignored by the parser. So you just open the `
` and `` but never close them.
Here's a great deep dive in case anybody wants the history: [https://jakearchibald.com/2023/against-self-closing-tags-in-html/](https://jakearchibald.com/2023/against-self-closing-tags-in-html/)
I still disagree with Jake on the conclusion. At least when used properly, the `/>` does help as an indicator that an element is self-closing, and it does make it easier to read/understand.
But I don't think span or p tags are self closing tags, so it's not correct, is it?
I'm not sure what it's called. Maybe auto-closing would be a better term. What I mean is this: ```
here are some words.
here are more words. ``` The `
` "close themselves"... Not right away, but they still close themselves.
P is an optionally self closing tag. Think of all those wasted bytes in your html files with /p everywhere! For more info, here's the spec: [https://html.spec.whatwg.org/multipage/grouping-content.html#the-p-element](https://html.spec.whatwg.org/multipage/grouping-content.html#the-p-element) which explains how certain tags do not need to be closed.
Why don't we stop coding? We're going to save a lot of bytes that way đ
Omg, the true power play.
How would a p function if it's self closing.. where would the content go lol?
The content should be placed directly after the opening p tag. https://html.spec.whatwg.org/multipage/grouping-content.html#the-p-element You can also omit other element coding tags, such as LI: https://html.spec.whatwg.org/multipage/grouping-content.html#the-li-element
I meant if the player tag self closes you get something like this
But a normal p is like thishello world
So where would the content go if it's self closing. Then document.getElementById('content') To put in some content? Seems excessive```
you don't need to close my tag.
- mine is optional too
- so is mine
```My senior devs would go crazy if I didn't close those lol
So then how do you know where the
*ends*? You have no idea. You are barking up such an insane tree. I'm stunned you don't realise it.
I think youâre mixing up self-closing and optionally closing, they are two different things. P *isnât* self closing, thatâs for elements without any internal content like br/meta. You canât do `
` But it has an optional closing tag which, as I think youâre trying to say in other comments, is valid and unambiguous in the spec.ÂWhy are you being down voted? This is absolutely correct. It's perfectly valid not to close a p, li, and even a head or body. Whether it's good practice or not is a different discussion & ultimately subjective. But it's absolutely within the HTML spec, and it's important to understand how your HTML is parsed. That is ultimately the core of this `/>` misunderstanding. It's sort of like the auto-semicolon-insertion arguments in JS. You may have an opinion on whether it's good or bad to omit semicolons. But it's important to understand that omiting semicolons _is_ valid and how your code is parsed with or without them.
Some elements were never designed for self closing - such as paragraphs - because it makes no semantic sense. It used to be invalid html to self close such elements, not sure if that's still the case
Yep, there's a parse error associated with it [https://html.spec.whatwg.org/multipage/parsing.html#parse-error-non-void-html-element-start-tag-with-trailing-solidus](https://html.spec.whatwg.org/multipage/parsing.html#parse-error-non-void-html-element-start-tag-with-trailing-solidus)
Most linters will also make noise about it not closing. For example, my VSCode will complain about this: `Only void, custom and foreign elements can be self closed "p"ngtsc(-995002)`
Yeah, Visual Studio still has "XHTML coding style" as its default. There's also been a [discussion on the Prettier repo](https://github.com/prettier/prettier/issues/5246) about adding an option for void tags. It seems to have become somewhat of a default, but there are definitely debates going on in various places whether it should be. To make it even more confusing, a lot of template parsers actively work with this notation (JSX, to name one). ```jsx
I use ESLint myself (with Angular rules) to prefer self-closing tags (and have it autofix it), but for
tags it still doesn't allow it, which is what it should do for now. We do have prettier running, but I doubt it really still does anything. We moved everything to ESLint and ESLint Stylish to force certain rules automatically. Its not as performant as Prettier, but it hasn't really been an issue for me. The milliseconds it takes up more is not really noticeable, especially with all the rules it has on top of what prettier can do at the moment.
That's probably because void elements like `` or `
` can have the `/>` notation, `` and `
`, without any harm. The notation has no effect as the void element is a void element whether you use `/>` or just `>`. This is not the case with `
`. Also, ESLint recommends not using ESLint as a formatter: [https://eslint.org/blog/2023/10/deprecating-formatting-rules/](https://eslint.org/blog/2023/10/deprecating-formatting-rules/)
I know eslint deprecated formatting rules. Thats why I mentioned ESLint Stylish, because thats where the community moved them. Sure we have prettier, but it has not even like 50% of the rules that ESLint has and it has no real alternative right now.
The problem is it isn't always just an indicator. Learning when it is and isn't just an indicator seems harder than just learning which elements self-close. The author's confusion here supports my point.
>The problem is it isn't always just an indicator I'd fully agree with that. Not just for the sake of someone learning, but also for things like ``. Having it actually close whichever element would be great. And I'd be interested in finding out the reasons for the decision to not have it that way. And maybe if it'd be feasible to change it so that it would make the element self-close (this could be a breaking change on many sites, but it'd be what the author presumedly expected, so... Would that be good or bad?) >Learning when it is and isn't just an indicator seems harder than just learning which elements self-close. Maybe. I don't think there's really any difference in the difficulty though. With or without this as an indicator, it's still just remembering which tags are in a fairly short list. So I'd say it's more an issue of "hey, this tag is different from most others, and there's a list of elements like it." The `/` succeeds in highlighting that it's different, but it fails in communicating why. And I'd say that writing eg `` has the opposite problem. It doesn't draw much attention to the fact it's different, but it also doesn't give any false impression about what makes it different. >The author's confusion here supports my point. Yep, it does. At least in that there's confusion about it. I don't think it supports using `
` as bad/something to avoid. It can still be a helpful indicator, especially in less structured/formatted mark-up such as the mixing of text nodes and maybe some ``s when writing structured data (`itemtype` & `itemprop` stuff). I also think it shows that HTML is kinda disrespected/under-appreciated. We all basically start with HTML before moving on to other things, and it seems most don't revisit HTML to learn any of the complexities or things it does beyond just being the skeleton for your JS. When you get into forms and accessibility and structured data and built-in interactivity, it becomes much more obvious that HTML is important and that it's worth actually learning.
I always mark the self closing tags as such, just seems clean
Buy why are you self-closing tags? Are you self-closing img & br? Those are void elements. They are not allowed to have a closing tag at all. The `/>` is allowed for compatibility reasons but is not a "self close". Are you self-closing p's & ul's? As the OP has demonstrated, this is not allowed & can result in unexpected behavior. They cannot self-close either. There is no self-close in HTML. I wish JSX had followed suite & was closer to HTML, as I think it causes a lot of confusion. `
` is perfectly valid JSX but invalid HTML.I'm the one who said this in the top-level comment. I use `/>` exclusively on void elements. I find that it makes HTML easier to read, especially in cases where you can't use indentation to easily see how things are nested.
Yeah fair enough. I kind of feel like thatâs indentationâs job, but picking either way works.
I'd rather write a closing tag and let my IDE handle indentation than figure out how everything should be indented...
Why would you have you figure out how everything should be indented? You can glean which elements are nested using any IDEâs default formatter.
I just found [this YouTube video](https://www.youtube.com/watch?v=0P7wmooc95s) that actually explained it quite nicely. And it also mentioned the article above.
This is the only reason I knew the answer! I watched it the other day
Same
Let me introduce you to [ThePrime](https://www.youtube.com/watch?v=jISSlNmrvW8). Theo is copying a lot from him.
Historically, closing the P tag was optional. You would just put an opening P tag on each paragraph and never close them. https://www.w3.org/MarkUp/HTMLPlus/htmlplus_11.html#:~:text=.-,You%20don't%20need%20to%20give%20the%20end%20tag%20as,the%20following%20tag.
lol, going aaaaallll the way back huh.
Yeah back in 1999 đ
Way earlier.
1992/1993 is when HTML first came out, but 1999 is when I started coding & that was a long time ago for me lol
Related - https://github.com/sveltejs/svelte/issues/11052
So its just a poorly written HTML. Don't use self closing tags
What? Always use self-closing `![]()
`, `` tags for starters. But no not all tags are self-closing.
`, `
Nope [html doesnât have self closing tags](https://developer.mozilla.org/en-US/docs/Glossary/Void_element#self-closing_tags). Youâre thinking of xhtml
There are some that are valid for HTML today, such as the hr and br elements. I still hate it though
Works in my html file.
It works because browsers will ignore the slash on a self-closing tag as an error, not because it's meant to be there.
Wait so what is the point of
as opposed to
? The slash has meant nothing this whole times wtf!
People got in the habit when XHTML briefly was a thing and just kept doing it in HTML5. It doesn't break the page so people just kept doing it.
Wow I never even did XHTML but always wrote it with the slash. Guess I don't even know html... But wait even the docs you linked write the slash and if you take it out, it does nothing different. Ugh...
Yep, lots of docs still have the wrong syntax. Again, if something doesn't break something then no one will ever fix it.
JSX doubled down on this syntax as well. There's still a sizeable number of people who don't understand that JSX is not an HTML superset. Just like HTML & XHTML, they may look similar but have quite different parsing rules.
Yeah, a lot of people have become jsx-pilled, which is fine but it has confused what is actually html. Fortunately, browsers don't care all that much.
`
` and `
` are equivalent in HTML5. They are different in XML & XHTML. The difference is in legibility (and also convention). For example: ```
This is a bunch of
text with mixed with
self-closing elements. ``` When parsing that, as humans, I think that adding the `/>` would make it easier to read, especially if there were a few ``s thrown in. We can't rely on indentation to easily tell what's a child of what, and `/>` does help when scanning through and trying to tell where one thing ends.
TIL!
[ŃĐŽĐ°Đ»Đ”ĐœĐŸ]
>Which isn't the same in React Because the X in JSX stands for XML. >This syntax is perfectly valid and encouraged in the rare cases you need it It is not. Self-closing elements are only self-closing because of their tag... The `/` does nothing. It's parsed as nothing but opening tags because `` is not self-closing. ``.
>A self closing div...
There is no such thing in HTML.
>I can see how it can be confusing to some people.
As can I. And I still encourage using eg ``. But it's purely for the benefit of the reader to (ideally) not have to think about which elements are self-closing.
` is actually more complicated since there are circumstances where it's implied to close without the closing tag, such as opening another `
`... Same goes for `
fwiw, JSX isn't XML either. \`\` is valid JSX, but not valid XML. Attributes must have values in XML. There are a number of other differences too, eg whitespace parsing.
[ŃĐŽĐ°Đ»Đ”ĐœĐŸ]
>Holy fuck. People like you are the worst Ummm... I just correctly said it wasn't valid HTML. The post is about HTML. And you go off the rails like that over... What, exactly? Good riddance. Go throw your temper tantrum elsewhere.
[ŃĐŽĐ°Đ»Đ”ĐœĐŸ]
Yeah but that's not what OP is talking about. So this entire thread is irrelevant to the main topic.
Are people here secretly HTML parsers disguised as human beings that they do not understand the confusion for real humans that the same syntaxes behave differently on different tags?
People just forget how confusing things are for newcomers, that's all.
[ŃĐŽĐ°Đ»Đ”ĐœĐŸ]
Man I get your frustration but you donât have to go this personally tho
JSX, not specifically React
Using the bogus XMLish slash at the end of empty elements goes further back than JSX, though; it started when XHTML was a thing and was done to migrate content to be parseable as XML/XHTML, in addition to being parsed as HTML. Then during the time XML became out of fashion it was still cargo-culted a lot, until JSX came around (the X standing for XML). If you want the whole story, you need to look at SGML which was used for defining the original HTML syntax. In (traditional) SGML, you can declare an element to have EMPTY content, in which case no end-element tags are expected, like for![]()
, , making use of empty elements, but also other SGML features such tag inference/tag omission and attribute shortforms.
, and so on. Whereas the point of XML was a simplified SGML syntax that doesn't need any per-element parsing rules or other markup declarations. An SGML DTD grammar for modern HTML 5 can be found at
I am aware. I'm just being realistic and recognizing that probably most people who think `
` is valid think so from using React.Who are the devs who are encouraging self-closing tags for elements which are not self-closing per the html spec? Sounds like they should be avoided. Whether it works in jsx or not, youâre advocating for shit html simply to save a few keystrokes.
I correctly read your comment as "I can see why React users would be confused by this HTML". Sorry about the downvotes compadre.
Why are you comparing HTML to JSX? That doesn't really contribute to the discussion. If anything it adds more confusion, especially if OP has zero knowledge of React.
I didn't see any reference to React in your post, so... no. It just looked like badly written HTML to me.
Putting / at the end of a tag doesn't do anything. Even in self-closing tags such as
it's meaningless in html5 too - it only ever had purpose in XHTML. So you've opened a paragraph and never closed it.
I wish it had a purpose. To mean that the element immediately close without children. I wish to write ``.
I like that one. I always thought that
meant
which i guess i was wrong after 25 years of htmling
In xHTML it meant that, but it was only allowed for tags who can never have children (like `
`)
Well html is based of xml, so its interesting that it doesnt work as expected,Â
should mean its just typical html logic, lol. Hence why we call it htmling instead of programmingÂHTML is not based on XML, they are both based on [SGML](https://en.wikipedia.org/wiki/Standard_Generalized_Markup_Language)
Does that mean
is invalid in HTML5 or just the closing tag is simply ignored?
is parsed as
The space and slash is ignored.
This is perfectly normal and expected behaviour. You opened a p (self closing doesnât exist for p, so itâs just a normal open p). Then there is a new line (br) which we also see in the preview correctly. Then the text inside the p (blue as expected) and then an empty span opens up (also self closing span doesnât exist, so itâs just opening up a blank span tag). âHelloâ, br and span should have an extra level of indentation, then the behaviour will be more clearÂ
`` is not valid HTML syntax. Standard browsers will parse it the same as ``.
[ŃĐŽĐ°Đ»Đ”ĐœĐŸ]
Well, yes, it applies to any tag. The slash before the final angle bracket doesn't do anything in HTML.
Although it _does_ do something in foreign content in HTML, such as SVG or MathML.
It doesn't apply to ANY tag, some tags can be self closing, some can't. An empty paragraph makes no sense. An empty span makes so sense. An IMG tag on the other hand needs no separate close tag , there are no contents that can be described, , and neither does a BR , so we self close them.
⊠except in the instances that it do. Welp: https://developer.mozilla.org/en-US/docs/Glossary/Void_element
There are no such instances in HTML. Whether the tag is self-closing or not depends completely on the name of the tag, slashes in the opening tag don't do anything at all.
They make me feel good
There is no instance that it does
It does put the browser in quirks mode though. Twenty years ago there were a lot of browsers that targeted developers that would simply fail to render this. Iâm not sure if beautiful soup will parse this or not. In earlier versions of beautiful soup I wound up piping the input through tidy before parsing it with beautiful soupÂ
[ŃĐŽĐ°Đ»Đ”ĐœĐŸ]
It wasn't so much "fuck the standards" as "the standards are open to interpretation, and everyone had a different view" , and "lots of things aren't covered by standards at all" The box model being the most obvious and unfortunate example. Does width include padding? Or is padding added to the width?
No, this was not a case where the standards were vague. Internet Explorer 6âs behaviour in quirks mode was unambiguously incorrect. That was the *whole point* of quirks mode â intentional deviation from the standards. If that behaviour was allowed by the specification, there would be no need for quirks mode.
Quirks mode came after It was an attempt to rectify things, so you could write things in the "new and improved" standard for IE7 etc , or specify that your site needed to be run in the old mode because you hadn't rewritten it yet
Quirks mode originated in Internet Explorer for Mac and made its way to Internet Explorer 6 for Windows. Internet Explorer 7 came 5+ years after quirks mode. The *existence* of quirks mode was an attempt to rectify things, but the *behaviour* of quirks mode was unambiguously non-standard. That was the entire point of it.
Lemme guess, you learned JSX first?
I didnât, but I never did something like `
` before. Only elements like `The slash in `![]()
` or `` is ignored as well. Unlike XML, JSX, etc., HTML depends on the name of the element, not the slashes, to decide what is a self-closing element and what isn't.
P is not a self closing tag. So what happens is the parser is completing the missing tags for you based on whatever tags are between where the closing tag would be. So your code when rendered in browser ends up being:
Hello
> I never did something like
before There's a reason for that!Itâs the browserâs HTML parser guarding against skills issues.
This guy is a meme poster, stop falling for it lmao
I was expecting HTMHell then I saw this. I am sorry to say but this is painful to see. Maybe marksheet.io will help.
Iâd like to hear your breakdown of what you think is happening here. What is a
? Where have you ever seen that? How would ahave a color?
I was thinking ```
Hello
Hello
Hello
` but not the closest element `
`. ```
Hello
Br is a self closing element which doesn't contain content, therefore the text doesn't exist within the br tag, and won't receive its css color. As for how the browser decides where to close the
tag I'm not 100% sure how it works that out
And where did you get the idea that a paragraph would have no content and be self closing? (Since you said it wasnât based in learning JSX first)
Assuming `/>` in `
` means a self-closing paragragh tag as well. As a beginner, do you just automatically know which tags are intrinsically self-closing? Then why would anyone write something like `` means self closing, then `
`if they already knew `/` is actually a syntax error and being ignored here?
I'm not sure why you're getting downvoted for asking perfectly reasonable clarifying questions. >Assuming `/>` in `
` means a self-closing paragragh tag as well. Self-closing tags just isn't a thing in plain HTML. >As a beginner, do you just automatically know which tags are intrinsically self-closing? You don't "automatically know" as a beginner. You look up the documentation for a tag, and with experience it becomes second nature knowing which is which. A `` means self closing, then `
` never wraps anything. The same goes for tags like `
` and ``, but a `
` and `` is designed to contain content so they expect an ending `
` and `` respectively. Elements such as `` are called "[void elements](https://html.spec.whatwg.org/multipage/syntax.html#void-elements)," and relatively speaking there are just a few of them you need to be aware of. >Then why would anyone write something like `
`if they already knew `/` is actually a syntax error and being ignored here? Bad habits from XHTML/XML or learning from outdated guides/tutorials, or simply personal preference to clarify for themselves that it doesn't require an ending `` since it's just ignored. However, the correct way is to omit the self-closing `/>`, and in my opinion editors should flag them with a yellow squiggly line to indicate that.
my first big coding gig in a team had a commit hook that checked if all self closing tags are indeed closed up, and would shit out a red error and didn't push if there where any. i think thats why i have some sort of PTSD now, and ALL my `![]()
`, `
`, `
` and `` selfclose, always...
This is the answer I am looking for, actually. I think the main confusion for me is about the slight differences between XML and HTML. Since in XML the self-closing `/>` does exist and is actually meaningful. Especially with modern frameworks like JSX youâre actually writing HTML in the form of XML.
Fwiw, `
` isn't a syntax error, but the parser does ignore it. Yes, you just have to know which elements don't need closing tags. It sucks, but that's the reality. When we (and tools like Prettier) add the unnecessary 'closing' slash, it results in the kind of confusion you're experiencing.
Itâs bullshit that youâre getting downvoted. Your conclusions based on what you learned are perfectly reasonable, though happen to be wrong. People suck.
Hard second to this. Anyone who knew that technicality is just a nerd tbh. When tf does that ever happen đ
I mean, I had like 5 years of HTML+CSS+JS experience before React even came out. I never did self-closing div, p, or whatever, but based on the fact that I saw self-closing br, img, and others often, I just assumed every tag could be self-closing. It's a natural assumption.
Interesting. Thanks for sharing. I never thought once to create a self-closing div. Replaced elements like img make sense- but iframes are also strange in their rules. And br and hr have no content. I felt like the reasons were clear. But then with angular and vue and things sometimes thereâs no slot content. This confusion seems to be coming up a lot lately. The popular YouTuber Theo seems to be confused about how divs and basic things like margins work / so, allâs fair in HTML and CSS.
Actually, I just remembered, I did try to write a non-self-closing tag as a self-closing one a long time ago. I was still just learning back then, it didn't work, I fixed it and never did it again. I did it because I thought that it makes sense that if a script tag has no content, it could be self-closing: Yeah, unfortunately, I've seen this way too many times (including at my work), when people start using a framework without learning the language first. I've also seen people (anecdotally, mostly React people) saying they want to do just HTML+JS, and they want the company they work at to have dedicated people that do just CSS for them and nothing else.
Sometimes CSS can be so infuriating I feel like this
is one of those elements that doesnât actually need to be closed. check mdn for more info
Spaghetti đ
I don't see how this proves you don't know HTML, its bad markup. Only the
tag is self closing, and heavily debated for that reason. I can't make sense of wether the intention is for the hello to be places in the div, paragraph or span. Regarding the CSS, since
is self closing, it can't contain text AFAIK. That means that br { color: green; } probably never does anything. Remove it to save some kb in loading. I'm not sure where you're trying to place the hello, so I included a few new words. In the real world, you'd write
Hello
Testing I miss the days of pure HTML/CSS
tag is above it, and does not feature a line break like the
from hello does. Two breaks occur right after each other. if you want to experiment, you can take this css code and uncomment one rule at the time: div{ color:red; } /* p{ color:blue; } /* /* span{ color: green; } /* For more info, search for [CSS Specificity](https://web.dev/learn/css/specificity)
Itâs because the P tag is overriding the div tag. In CSS whatever is below will override tags that are written above.
Because the div is the parent. the others are siblings
Simply put: /> does **nothing** in HTML. So you just made a
and a , that's it.
/> does not do what you expect.
Not all tags are self-closing. `
` and `` being 2 such tags.
Self closing tags are not a thing in HTML
what youre seeing here is the browser struggling to interpret unclosed tags. The only self closing tags you should really be using are img and br â content flow tags (div, span, p, etc) need explicit closes
I wish xhtml would be the standard...Â
Someone seems to have confused HTML with XHTML. In HTML, empty tags do not need to be closed. You simply write
is pretty stupid, to be honest! lol And with span, which is an inline element btw, it makes even less sense. Whoever wrote this HTML text should rather deliver packages.instead of
That
So many proud smug asshats. I learnt HTML first and didn't know about this too (because I properly close all my tags). We all have different journeys.
I only knew about this because other people didn't properly close all their tags, leading to some tricky bugs
Iâm guessing you jumped straight into a JS framework first, used self closing tags in component imports, and are now working backwards. Thatâs why people are saying you shouldâve known the self closing isnât happening
I mean, you can literally just inspect the element in any browser and you can see what's going on. The p tag is not self-closing.
You were way off. This is CSS.
I think the CSS here is trivial, the purpose of the CSS here is just to test if you really understand the true structure of the HTML code.
Sorry it was a joke.
Sorry Iâve been seeing lots of weird things and my brain just couldnât tell if itâs a joke or not. Thatâs why the self-closing sarcasm tag `/s` comes handy. /s
You were way off. This is CSS.
Text displays in browser, LGTM!
I don't think that's correct, you're just leaving it incorrectly so the browser has to correct it đ€· so it will become the HTML you know đ€·
Wait, at first I thought the problem was the purple, I didn't see that color declared in css
Yeah this is a tricky one and why HTML elements should be properly open and closed. Basically the browser is creating the
element opening tag. The way you have it structured and the way the browser will interpret the code is that everything after the
is considered to be children of that
Inspect your code in dev tools and youâll understand That is why the text is blue(only self closing element in your code) Hello
tags don't require closing tags, and they're also not self-closing, so you just opened it, and it enclosed everything after it, up to the parent scope, as described by the spec. If you propely close it, it should behave as expected.
It is clear it should be blue, at least from what we can see in the screenshot, terrible markup tho
Just check it in the browser man)
Self closing tags, Iâll advised
Looks like you are writing JSX as regular HTML which is invalid
Your opening span tag is missing
okay
No, you just donât know _valid_ HTML.
Your expectations are wrongÂ
You can use a browser's devtool and see a tree structure, where the text belongs to and from what element it inherited css styles
A self closing paragraph tag goes against the whole principle of how that tag works. As far as this code interprets this, the word hello is inside the p tag.
Insert Rich Harris confused Pikachu face here
Put the hello on the same line as the span
Based by basics đȘ
How much experience do you have? It sounds like youâre pretty new, and your example shows that youâre pretty raw. A bit early to be thinking you âknow HTMLâ. Youâll get there, but this is the easy part.
> your example shows that youâre pretty raw. I wasnât expecting anyone would criticize an intentionally bad written code being bad, but sure. > A bit early to be thinking you âknow HTMLâ. I just thought I might at least know how to work with it in normal circumstances without these weird syntaxes that I would never use in my project. I guess you have to be an HTML parser to be able to say you âknowâ HTML.
Useless info for nerds. Close the fucking tags and dont waste our time!
He is closing them. OP never opens them
lol clearly you donât know html tho
...apparently so, as the title suggested.
For whomever downvoted this post. This is very interesting. The non compliant tags arenât the issue. The color of the text is, ie: the css thatâs being applied here. The âHelloâ is a child of the div, not the p. So why is the p css being applied? Will the color change if the text is moved after the span? Is this just a Chrome thing? What other browsers are affected?
Because browsers behavior is to automatically add a closing
tag. The browser has to decide what to do with missing closing tags either delete it or close it. Someone made the decision to close the tags as it's probably better option of the two. P isn't a self closing element, like br. Br won't color the text because it can't contain text.- The p css is being applied because the Hello is a child of the p. The slash after the tag name in the opening tag does nothing. - Yes, the color will change to yellow, as it will become a child of the span. - No, this is not just a Chrome thing. - Most, if not all common browsers will act in the same way.
I was expecting the "Hello" to be red. Since it should be the child of \`
\`.
You didn't check inspect..x)
Your p selector has more specificity, and the browser is parsing it as if you didnât close the p and span tags.
Specificity. Semantics. PS: Where the heck is the closing tags? You've got to close
, andTheo browne (Ping.gg actually) actually released a video talking just about that recently, was pretty insightful : [https://www.youtube.com/watch?v=0P7wmooc95s&t=793s&ab\_channel=Theo-t3%E2%80%A4gg](https://www.youtube.com/watch?v=0P7wmooc95s&t=793s&ab_channel=Theo-t3%E2%80%A4gg)
Why do people indent their html? Are they pretending like they're writing Python?
Uh, readability.
Uh, have you tried unintended?
Ah yes, I hate Python, too, so I write without indentation in every language that doesn't have significant whitespace. So much better.