The br element

Okay, so I f**ked up. I forgot to write about <br> and now the whole series is out of order. Having announced this failing on social media, I appreciate the comments I received like, “give yourself a <br>”. Very funny and clever. “Excellent humor,” as Bob Mortimer would say. Anyway, here it is, albeit late.

Some people get very uppity when you conflate the terms tag and element in HTML. Most of the time, a tag is only part of an element. An anchor comprises two tags, for example: <a> (opening) and </a> (closing). But some elements are self-closing or void, like <br/>. In these cases, the tag alone is the element, because inserting text would not make sense. A <br/> is literally a break from text, after all.

This is all made slightly more complex and off-putting by the fact that, in HTML, you don’t actually have to self-close self-closing elements. You can leave the slash out like this: <br>. In XHTML—which is a syntactically stricter hybrid of HTML and XML—removing a slash from a <br/> would be like removing the lead guitarist Slash from the band Guns ‘n’ Roses: a lot of dorks would complain loudly and incessantly. Fortunately, nobody really uses XHTML anymore, like nobody really listens to Guns ‘n’ Roses.

When would you use a <br> element? I’m glad I asked that question. Most of the time, line breaks already occur by:

1. Letting the text wrap naturally, according to the available space, or
2. Separating content between successive block elements, such as paragraphs.

Inserting a <br> manually is usually unnecessary and always risky. It’s liable to look out of place in all but one very specific context. Increase or decrease the space around the text just slightly and the text will reflow, causing the <br> to break where breaking causes an unwanted, erm, breakage.

I very, very rarely code <br> elements into my HTML, because I very, very rarely write poetry.

I learned all my HTML<br>
From a code camp held yearly in hell<br>
We started on `<s>`<br>
Then striked through the rest<br>
Now I have a career in DevRel

But that doesn’t mean I haven’t had to code around them. Which brings me to the subject of WYSIWYG editors.

Briefly, a WYSIWYG editor is a rich text editor that outputs HTML. It enables those who can’t (or won’t) write HTML to generate content in the HTML format. I would estimate this is how most of the web’s content is created. The problem with WYSIWYG editors is they offer visual formatting options based on structural semantics. I should have said: WYSIWYG stands for “What You See Is What You Get”, ironically.

For example, someone looking to make text go big will inevitably choose a “Heading 1” or “Heading 2” formatting option, regardless of whether a corresponding <h1> or <h2> heading element is suitable for the context or the nature of the content.

I recently worked on an algorithm that calculates heading levels and assigns them to design system templates. It was kind of neat, because it meant you could insert any component using headings anywhere in a consuming application and the heading level would be assigned automatically. Just one problem: this only works for components coming from the design system. Meanwhile, most of the actual content is spat out by a WYSIWYG editor.

Anyway, I digress. More to the point, WYSIWYG editors also tend to generate a lot of <br> elements. Why? Well, basically, because their desktop publishing forebears don’t have a concept of a <p>. In desktop publishing, a paragraph is not a semantic entity; it is the appearance of a block of text separated by a single blank line.

In Microsoft Word™, if you hit ENTER you will start a new line. If you hit ENTER twice, then you create that blank line and commence a new paragraph. A web-based WYSIWYG editor worth its salt will behave differently. If you hit ENTER just once—a hard return—a new paragraph (<p>) will be created. Creating a simple line break (<br>) is the purview of a soft return: SHIFT + ENTER.

Okay, so fine. It’s different; people will adapt. Except they don’t. An editor who hits ENTER just once, only to see they’ve jumped two whole lines ahead, will be incensed. And I kid you not, they will backspace to where they started and use TWO SOFT RETURNS to arrive back in exactly the same place.

The same to them, anyway, and they’re not stupid—that’s how it always was, with typewriters and stuff. But to a front-end developer, it’s the difference between two nice paragraphs or some text with <br><br> lurking inside it. To cut a long story short, this is some CSS code I wrote and deployed for one of the world’s largest publishers. It hides all <br> elements, reinstating a natural flow of text across all content.

br {
  display: none;
}