The actual thing that matters is that the / is ignored so (unlike with XML I believe) you can’t self-close a non-void element by adding a trailing /. But “void elements should not have trailing slashes” is extrapolation on your part; the trailing slash improves readability and is kosher since it doesn’t act as a self-close.
HTML parsers only allow this to stop pages breaking when developers make mistakes; see this Computerphile video. ‘Able to be parsed correctly’ is not the soul criterion for it a syntax being preferred, otherwise we would all leave our <p> elements unclosed.
Yes, it is not “incorrect” to write <br/>, but it is widely considered bad practice. For one, it makes it inconsistent with XML. Linters will often even “correct” this for you.
I personally find the official style (<br>) to be more readable, but this is a matter of personal opinion. Oh, and I used to have the same stance as you, but I also used to think that Python’s whitespace-based syntax was superior…
At the end of the day, regardless of anyone’s opinion, we should come to SOME consensus…and considering that W3C already endorses <br>, we should use this style.
“readability” is subjective. much like how there is no objective definition of “clean code”. i am not arguing that either option is more generally “readable”, i am insisting that people use a common standard regardless of your opinion on it. a bad convention is better than no convention. i dont personally like a lot of syntax conventions in languages, whether that be non-4-space indenting, curly braces on a new line, or early-declared variables. but i follow these conventions for the sake of consistency within a codebase or language, simplicity on linter/formatter choice, and not muddling up the diffs for every file.
if you want to use <br/> in a personal codebase, no-one is stopping you. i personally used to override every formatter to use 2-space indenting for example. but know that there is an official best practice, which you are not following. if you work in a shared codebase then PLEASE just follow whatever convention they have decided on, for the sake of everyone’s sanity.
if you work in a shared codebase then PLEASE just follow whatever convention they have decided on, for the sake of everyone’s sanity.
That goes without saying; I’m not a barbarian.
“readability” is subjective. much like how there is no objective definition of “clean code”.
Did you not see the part where I said it’s less readable “in my opinion”?
i am insisting that people use a common standard regardless of your opinion on it.
I can read this one of two ways: either you’re making an assertion about what people are currently doing, or you’re telling me/others what to do. In the first case, you’re wrong. I’ve seen many examples of self-closed <br> tags in the open source projects I’ve contributed to and/or read through. In the second case, IDGAF about your opinion. When I contribute to an existing project I’ll do what they do, but if I’m the lead engineer starting a new project I’ll do what I think is the most readable unless the team overwhelmingly opposes me, ‘standards’ be damned, your opinion be damned.
The spec says self-closing is “unnecessary and has no effect of any kind” and “should be used only with caution”. That does not constitute a specification nor a standard - it’s a recommendation. And I don’t find that compelling. I’m not going to be a prima donna. I’m not going to force my opinions on a project I’m contributing to or a team I’m working with, but if I’m the one setting the standards for a project, I’m going to choose the ones that make the most sense to me.
It’s not extrapolation on my part, the HTML spec is pretty direct about it:
Then, 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 (/), which on foreign elements marks the start tag as self-closing. 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.
For example, in the case of <div/>Some text, browsers interpret this as <div>Some text</div>, treating the slash as ignored and considering the div element to encapsulate the text that follows.
You should never rely on a browser interpreting a non standard use in a specific way. It can change at any moment, and wouldn’t be reliably reversed because it’s inherently non standard.
🤓 ackshually that’s not the HTML spec. Void elements should not have trailing slashes.
https://developer.mozilla.org/en-US/docs/Glossary/Void_element
> Clicks on
<br>> Example is
<br />The actual thing that matters is that the
/is ignored so (unlike with XML I believe) you can’t self-close a non-void element by adding a trailing/. But “void elements should not have trailing slashes” is extrapolation on your part; the trailing slash improves readability and is kosher since it doesn’t act as a self-close.An explanation of this problem can be found on the official W3C HTML validator wiki.
HTML parsers only allow this to stop pages breaking when developers make mistakes; see this Computerphile video. ‘Able to be parsed correctly’ is not the soul criterion for it a syntax being preferred, otherwise we would all leave our
<p>elements unclosed.Yes, it is not “incorrect” to write
<br/>, but it is widely considered bad practice. For one, it makes it inconsistent with XML. Linters will often even “correct” this for you.I personally find the official style (
<br>) to be more readable, but this is a matter of personal opinion. Oh, and I used to have the same stance as you, but I also used to think that Python’s whitespace-based syntax was superior…At the end of the day, regardless of anyone’s opinion, we should come to SOME consensus…and considering that W3C already endorses
<br>, we should use this style.If a spec tells me I should do something that makes my code less readable in my opinion I am going to ignore the spec every time.
There’s even one in English that I actively and pointedly flout: punctuation must go inside of the quotes if the quote terminates the sentence
Yeah, unless it’s a formal setting, reader comprehension comes before all else
“readability” is subjective. much like how there is no objective definition of “clean code”. i am not arguing that either option is more generally “readable”, i am insisting that people use a common standard regardless of your opinion on it. a bad convention is better than no convention. i dont personally like a lot of syntax conventions in languages, whether that be non-4-space indenting, curly braces on a new line, or early-declared variables. but i follow these conventions for the sake of consistency within a codebase or language, simplicity on linter/formatter choice, and not muddling up the diffs for every file.
if you want to use
<br/>in a personal codebase, no-one is stopping you. i personally used to override every formatter to use 2-space indenting for example. but know that there is an official best practice, which you are not following. if you work in a shared codebase then PLEASE just follow whatever convention they have decided on, for the sake of everyone’s sanity.That goes without saying; I’m not a barbarian.
Did you not see the part where I said it’s less readable “in my opinion”?
I can read this one of two ways: either you’re making an assertion about what people are currently doing, or you’re telling me/others what to do. In the first case, you’re wrong. I’ve seen many examples of self-closed <br> tags in the open source projects I’ve contributed to and/or read through. In the second case, IDGAF about your opinion. When I contribute to an existing project I’ll do what they do, but if I’m the lead engineer starting a new project I’ll do what I think is the most readable unless the team overwhelmingly opposes me, ‘standards’ be damned, your opinion be damned.
The spec says self-closing is “unnecessary and has no effect of any kind” and “should be used only with caution”. That does not constitute a specification nor a standard - it’s a recommendation. And I don’t find that compelling. I’m not going to be a prima donna. I’m not going to force my opinions on a project I’m contributing to or a team I’m working with, but if I’m the one setting the standards for a project, I’m going to choose the ones that make the most sense to me.
It’s not extrapolation on my part, the HTML spec is pretty direct about it:
https://html.spec.whatwg.org/multipage/syntax.html#start-tags
I don’t think it’s an extrapolation to say that code which is “unnecessary and has no effect of any kind” should be omitted.
And yeah, I linked the MDN docs because they’re easier to read but if they disagree then obviously the spec is the correct one.
To be annoyingly nitpicky, how is “unnecessary” defined in this context? Whitespace is usually “unnecessary” but I quite like it for readability.
I broadly agree with you though, the W3C spec changes things.
Wasn’t the space before the closing
/only because IE was dumb?Trailing slash lets you do this though:
This is terrible.
You should never rely on a browser interpreting a non standard use in a specific way. It can change at any moment, and wouldn’t be reliably reversed because it’s inherently non standard.
Why would you want that.