DEV Community

Discussion on: Difference Between <br> and <br/> Tag in HTML

Collapse
peerreynders profile image
peerreynders

TL:DNR: The HTML standard perspective is:

Self-closing tags don't exist in HTML.

Also using <br> is less effective when it comes to code neatness and readability than <br/>. Hence <br/> is generally preferred over <br>.

That's an opinion (OK when expressed as such).

The living HTML standard talks about the br element and only uses the <br> version.

What it does mention: "Content Model: Nothing"

When an element's content model is nothing, the element must contain no Text nodes (other than inter-element whitespace) and no element nodes.

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

  • wishing that HTML was more like XML (it isn't)
  • not wanting to remember which elements are void elements but instead desiring an explicit reminder when a tag doesn't support children.
Collapse
primevaldad profile image
david palmer

So, maybe best to use HTML standard for HTML processing, and convert to XML standard (
) as necessary for integration?

Collapse
peerreynders profile image
peerreynders

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.

XML parsing:

  • Is it well formed?
  • Is it valid with reference to the identified schema?

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.