Suppose you want your webpage to show the below message with the same format, How will you write it in HTML?
If you are planning to use carriage return (ENTER key) to produce line breaks, then let me tell you that it won’t work because HTML will ignore any carriage return and extra spaces.
You can use the br tag which is used to produce line breaks in HTML and here are the two possible ways of using br tag.
Welcome to <br>
Welcome to <br/>
the blog <br/>
Both will give the same output, but what is the difference between br and br/?
But before that let’s look at some pointers.
- br tag is used to produce line breaks in an HTML document and it is a self-closing tag.
- When a tag is used with nothing between it, then a self-closing tag (or empty tag) can be used. br is one such self closing tag, which means there is no need of closing tag ( /br) while using br.
- Generally, TAG/ (not to be confused with /TAG) is used as a condensed way of writing TAG.../TAG.
So from the above pointers, it is evident that br and br/ will provide the same results when used in HTML.
But, whenever we are using XHTML (which is more strict than HTML), it doesn’t allow leaving tags open (like you cannot write just br, you have to close it also but /br doesn't make sense since it is a self-closing tag ), hence br/ will be used in that case.
Also using br is less effective when it comes to code neatness and readability than br/. Hence br/ is generally preferred over br
To sum up, the key differences between br and br/ in HTML can be understood with the help of the following table:
Difference between br and br/ Tag
Let’s look at its browser compatibility now
Both br and br/ produces the same result i.e line break. But br/ is preferred because it can be used with strict rules as well(like while writing XHTML document) and the latter looks cleaner and readable.
Read more about other self-closing tags on Scaler topics.
Author: Rdiddhi Suteri
Top comments (5)
TL:DNR: The HTML standard perspective is:
Self-closing tags don't exist in HTML.
That's an opinion (OK when expressed as such).
The living HTML standard talks about the
brelement and only uses the
What it does mention: "Content Model: Nothing"
The standard further defines the concept of void elements
All of these are "Content Model: Nothing"
Under parse errors (non-void-html-element-start-tag-with-trailing-solidus) we can find:
"The trailing U+002F (/) in a start tag name can be used only in foreign content to specify self-closing tags. (Self-closing tags don't exist in HTML.) It is also allowed for void elements, but doesn't have any effect in this case."
So the "trailing solidus" isn't an HTML feature but is merely tolerated on void elements.
So the "trailing solidus preference" comes from
So, maybe best to use HTML standard for HTML processing, and convert to XML standard (
) as necessary for integration?
It's one thing to go XML -> HTML (e.g. via XSLT). As the output isn't XML there is no reason to use self-closing tags (as they don't exist in HTML).
HTML -> XML is in many cases a lost cause unless one is prepared to apply Postel's law in bulk - in many cases HTML source isn't even "valid" HTML (example Alpine.js site).
HTML and XML have very different parsing philosophies.
HTML parsing on the other hand is very forgiving, usually resulting in a "best effort parse" in line with the web's philosophy of resilience and robustness. Given "content is the foundation, markup is an enhancement" it rather show a little bit of "garbage" to the user than hold back any content. That way an error may affect only part of a page while the rest renders as intended.
This robustness also creates some breathing room for innovation - a legacy browser may not know what to do with a web component but that won't affect the parts of the page that are implemented by more traditional means.
The fact that HTML will accept void elements as self-closing tags despite the fact that self-closing tags don't exist in HTML is a testament to its alignment with the "robustness principle" (while XML doesn't tolerate deviations).
So while XHTML seemed like a good idea on the surface its conformance requirement ultimately would have left the web more fragile ("less robust") in terms of encouraging experimentation/innovation and denying users access to all content even in the face of the most insignificant of errors.
Most people now use HTML5 rather than XHTML (which was initially the proposed derivative of HTML4). W3C does not recommend using XHTML serialization for most authors (ref)