Use semantic paragraph <p> tags in post content instead of line breaks <br> (Accessibility, Semantics, Bug Fixing, Styling, SEO?)

[adamgreenough]

I've commented about this before but have been recommended to start a suggestions thread!

Currently, the Froala editor uses paragraph <p> tags for a hard return and line breaks <br> for soft return if you inspect the HTML while editing. This is how things should work and do in almost all WYSIWYG editors. However, XenForo applies CSS that masks this fact to better represent how the post will look when it is rendered. Normally, a paragraph tag would separate blocks of content by about 0.8 line height.

When XenForo renders the post, it strips out these paragraphs in favour of line breaks using the <br> tag. There's many reasons this is wrong. Chris has previously stated this is simply their personal preference but I have not heard as for why yet. Here's why using line breaks is wrong and using paragraphs would be an improvement.

Accessibility

In many screen readers, line breaks are read over without a pause like you would expect when listening to content separated into paragraphs. Screen readers also have functionality to skip through paragraphs to make navigating large blocks of content much easier, this is not usually possible when line breaks are used instead.

Fixes long standing iOS Keyboard Bug

Opting to use paragraphs instead of line breaks on hard returns plus a bit of CSS to reflect this change in the editor and post view would essentially solve my problem with shift deactivating on iOS after using two new lines to manually indicate a new paragraph.

XF 2.1 - Major editor complaints

I have many users complaining about the post editor. Cursor jumping to beginning when backspacing or deleting wrong text iOS not keeping shift on when entering 2 line breaks and turning it on at seemingly random times (very annoying) Entering 2 line breaks on list does not close the list as...

xenforo.com

Fixed - Froala iOS - Double tapping return produces odd results

xenforo.com

XF 2.1 - How to stop ios keyboard losing capitalisation on new paragraph. Or is it a bug?

At first I thought this was a bug, maybe it is. Who knows? On iPhone, when you press return the keyboard changes to capitals. However for a new paragraph you have to press return again in order to get the space. The keyboard then goes back to lower case. NB: mentioned here but the only answer...

xenforo.com

Styling/Typesetting Improvements

From a styling perspective, I would prefer to have less space than a double BR provides to separate paragraphs. It is not proper typesetting to have a whole line height between paragraphs. It would also make it much easier to provide consistent spacing which is an annoying problem. Currently, the spacing between lists, new lines, embeds, quotes, etc. can be inconsistent and unpredictable. If everything was happily sat in its own paragraph/other semantic tag then applying consistent margins would be a breeze.

It is invalid HTML, the official HTML spec says this is wrong and so does MDN

It should not really be up for debate that line break tags should not be used to space paragraphs. The MDN agrees. The official W3 HTML spec has the following to say:

"br elements must be used only for line breaks that are actually part of the content, as in poems or addresses."

The only reason it would pass as valid HTML in a automatic checker is because the checker does not know the semantic intention of the code, just that it technically does not violate any hard technical rules.





SEO?

It is no secret that search engines love valid, semantic HTML. As we discussed, this isn't it. I expect that Google is smart enough to gloss over this unsemantic HTML since they're so advanced, but why chance it? We are already seeing organic results for forums dropping in many cases and need every advantage we can get. There is a fundamental error with how the most valuable content is currently being formatted. Google takes various snippets from paragraphs, I highly suspect that this affects that though it is very hard to get objective evidence here.

Why have XenForo chose to do it this way?

Why is it designed to be this way? As you can see, the case for paragraphs is strong and appears to be objectively the correct way to do it. I'd love to hear a case for line breaks if one exists beyond just being personal preference.

It is an option in the editor as to how new lines are created but it is simply our preference to use HTML line breaks rather than other options.

So it’s working as we designed it to. You seem to indicate this is problematic. How so?

Semantically you can use <p> tags to separate chunks of text, yes. But you can also separate chunks of text with line breaks. Either approach is valid.

Dismissing this suggestion because it doesn't appear to affect you would be a disservice to the over 2% of users that are visually impaired and would benefit from a screen reader with semantic HTML as well as the huge number of iOS users with an annoying bug every time they want to start a new paragraph.

In an ideal world, perhaps this could be an option if people are worried about unlikely affecting their existing posts?

Thanks for reading! If you agree, an upvote will help get this seen and considered (I hope!).

 

[adamgreenough]

This is my first paragraph!
And this is my second I used enter to get to this line.
I used Shift+Enter to get to this line.

Here you can see that the Froala editor is already formatting it correctly using paragraphs for hard returns and line breaks for soft (shift+enter).



It is just that XF CSS has been applied to remove the natural spacing from paragraphs like you'd expect in a normal text editor.

Once saved, we can see this is all converted to line breaks in the outputted post which is incorrect by seemingly all accounts.

 

[DragonByte Tech]

If that fixes the shifting bug on iOS then this is a mandatory change, IMO. I post from mobile on occasion and it's extremely annoying.

 

[adamgreenough]

Thought I'd check a few other popular forum software/editors to see how they're handling this...

Invision Community: Paragraphs (with line break support)
vBulletin: Converts all paragraphs and line breaks to line breaks like XenForo
Discourse: Paragraphs (with line break support)
Vanilla: Paragraphs (with line break support)
phpBB: Converts all paragraphs and line breaks to line breaks like XenForo
MyBB: Converts all paragraphs and line breaks to line breaks like XenForo
WordPress (TinyMCE): Paragraphs (with line break support)
Flarum: Paragraphs (with line break support)

A definite trend with the older style forums taking the line break approach. Perhaps seen as easier when dealing with BB code? Still, I hope XenForo can do better and leave that old way of thinking behind, they're smart guys.

 

[Lawrence]

Paragraphs for sure, with empty <p> tags converted to line breaks.

 

[Kevin]

I'd love to see even an option for it instead of switching it by default if the devs are stuck on insisting BR breaks are acceptable.

We shouldn't have to explain to members in 2020 to use double returns between paragraphs.

 

[adamgreenough]

Yes definitely! An option would be perfect. I think <p> should be default for new installs though.

 

[Tradidi]

This is an important issue for me as I would like to format my articles (and other posts) consistently by applying (and thus enforcing) margins to paragraphs (via CSS), rather than relying on the user to add white space by adding an empty line. These empty lines don't even look consistent between the editor and the rendered view, so I now have to guess where to add an empty line and where not. Not very WYSIWYG imho!

I'm really puzzled/disappointed that the developers went down the <br> road.

Just think, what do people do in a decent word processor if they want to separate their paragraphs? Can any serious editor imagine using line breaks to add white space, rather than consistently formatting the whole text by defining and applying paragraph styles? That's like using spaces instead of tabs or indents, yuck. By forcing people to use <br> the developers are preventing us from enforcing consistent and professional looking articles!

 

[btmgreg]

I can't contribute to this thread much, but I'm all for making things the right way.

 

[Tradidi]

Here's how I solved this issue by overwriting some of the core code, which is not ideal but is still better than waiting for a better solution (which may never happen).

In the src/XF/BbCode/Renderer/Html.php file change the filterFinalOutput function from

public function filterFinalOutput($output)
{
return '<div class="bbWrapper">' . trim($output) . '</div>';
}

to

public function filterFinalOutput($output)
{
$output = str_replace( "<br />\n", "</p>\n<p>", $output );
$output = "<p>\n" . $output . "\n</p>";
$output = str_replace( "<p></p>", "", $output );
$output = preg_replace( "/<p><h(\d?)>(.*?)<\/h(\d?)><\/p>/", "<h$1>$2</h$1>", $output );
return '<div class="bbWrapper">' . trim($output) . '</div>';
}

It seems to work fine for me so far, with no unexpected side effects.

 

[djbaxter]

I really don't care. To me, it's a non-issue.

As it stands, the editor works just fine. If it aint broke, don't fix it.

And as for iOS (not MacOS), on my devices I default to Firefox and it works just fine there too. I assume you must be talking about Safari but you're not stuck with that as your browser, you know. You can download the big three browsers and set anyone of them as default on iOS.

 

[Max Taxable]

Here's how I solved this issue by overwriting some of the core code, which is not ideal but is still better than waiting for a better solution (which may never happen).

In the src/XF/BbCode/Renderer/Html.php file change the filterFinalOutput function from

to

It seems to work fine for me so far, with no unexpected side effects.

Someone should make a correctly coded addon based on this, so core files don't have to be manually edited. The edit won't survive upgrades.

 

[PaulB]

One issue with <br>--aside from the accessibility issue--is that it makes styling a bit more cumbersome. What if I don't want the spacing between paragraphs to be exactly one line? What if I want a hanging indent in article forums?

In the US, the current Supreme Court precedent is that websites for companies with brick-and-mortar presence must be accessible. (I am not a lawyer, so this is probably an oversimplification, and a federal appeals court recently contradicted this precedent in another case.) Using semantic tags to indicate the purpose of a block of text should be assumed to result in a more accessible experience, so I'm not sure why this is contentious. <br> has no discernible benefit over <p>, and <p> brings notable accessibility and styling benefits.

 

[djbaxter]

That appeals court ruling is at https://www.courthousenews.com/websites-not-bound-by-ada-accessibility-rules-11th-circuit-finds/

 

[djbaxter]

One issue with <br>--aside from the accessibility issue--is that it makes styling a bit more cumbersome. What if I don't want the spacing between paragraphs to be exactly one line? What if I want a hanging indent in article forums?

In the US, the current Supreme Court precedent is that websites for companies with brick-and-mortar presence must be accessible. (I am not a lawyer, so this is probably an oversimplification, and a federal appeals court recently contradicted this precedent in another case.) Using semantic tags to indicate the purpose of a block of text should be assumed to result in a more accessible experience, so I'm not sure why this is contentious. <br> has no discernible benefit over <p>, and <p> brings notable accessibility and styling benefits.

Actually br does have an advantage over p if you want the following content on the next line without a blank line between.

Not all websites fall under ADA and lower courts have upheld some challenges to the Supreme Court ruling. And that's just in the US: the laws in other countries also vary according to accessibility rulings.

Do All Websites Have to Be ADA Compliant? - Accessible Metrics

Do all websites have to be ADA compliant? The ADA doesn't mention websites. But many businesses have been in ADA civil suits. Let's take a closer look.

www.accessiblemetrics.com

Website Accessibility & the Law: Why Your Website Must Be Compliant

Designing for inclusion and website accessibility isn't just for compliance – it is a good business decision to make. Learn why here.

www.searchenginejournal.com

ADA Compliance for websites explained - 18 steps checklist

Learn about the Americans with Disabilities Act for websites, check how to be compliant with our ADA compliance checklist or use our free ADA checker.

siteimprove.com

Actionable tips and how-tos to improve your website - Siteimprove Blog

Expert insight and handy tips to help you dig deeper into accessibility, user experience, website management, and more.

siteimprove.com

Introduction to Canadian Digital Accessibility Laws

Accessibility laws in Canada can differ based on whether you're in the public or private sector, your province and national presence, and company size.

www.accessibility.com

 

[PaulB]

Actually br does have an advantage over p if you want the following content on the next line without a blank line between.

I would expect a WYSIWYG to handle both tags the way they're meant to be used: two line breaks results in <p>, one line break results in <br>. Alternatively, for desktop users, it would be reasonable for Enter to create a new paragraph and Shift + Enter to create a line break--that's how Word handles it, but it doesn't work for mobile users.

Both <p> and <br> should be used, but they mean different things. When I press Enter twice, I expect to create a new paragraph. When I press enter once, I expect a line break. Again, I don't see how this is contentious. Other tools have found ways to implement this; Markdown handles it intuitively, Word handles it intuitively, even WordPress handles it intuitively (taking the Word approach--Shift + Enter for a line break, if I recall correctly).

Not all websites fall under ADA

Of course they don't, but it doesn't matter because there's no disadvantage here. More styling options, better typography and presentation, differentiation between line breaks and paragraphs, and better compatibility with assistive technology. What's there to lose?

 

[krieglich]

Actually br does have an advantage over p if you want the following content on the next line without a blank line between.

Yeah, that's why you make a br when you have a line break and a p when you have a paragraph (the false(!) two line breaks in default Xenforo). I don't understand why you keep on commenting on this matter, why do you have such a problem with accessibility?

 

[PaulB]

Yeah, that's why you make a br when you have a line break and a p when you have a paragraph (the false(!) two line breaks in default Xenforo). You just don't get it. I don't understand why you keep on commenting on this matter, why do you have such a problem with accessibility?

It's actually a pretty common point of confusion; even people who are too young to have ever used a typewriter have a tendency to indent in Word uses spaces or tabs, for example.

Since most people press Enter twice for a new paragraph anyway, I'm in favor of that being used to indicate <p>. For single line breaks (<br>), I think the single-Enter approach makes more sense for a website, as opposed to the Word-like approach of Shift + Enter that doesn't work on mobile.

<p> and <br> represent semantically different concepts. <p> doesn't necessarily mean that there's a specific amount of space between paragraphs--it makes no assertion about styling on its own. It's purely semantic. Both should be used, but the majority of forum posts are likely only going to need <p>.

As an example of appropriate usage of both, let's say you have a poetry-oriented forum:

You would want
line breaks
between lines
within a stanza

But the stanzas
should be demarcated
as paragraphs.

I would expect that to result in the following HTML:

<p>
You would want<br>
line breaks<br>
between lines<br>
within a stanza
</p>

<p>
But the stanzas<br>
should be demarcated<br>
as paragraphs.
</p>

Pardon my lousy poetry.

 

[djbaxter]

Yeah, that's why you make a br when you have a line break and a p when you have a paragraph (the false(!) two line breaks in default Xenforo). I don't understand why you keep on commenting on this matter, why do you have such a problem with accessibility?

I don't have a problem with accessibility. I have a problem with people over-generalizating.

 

[PaulB]

I don't have a problem with accessibility. I have a problem with people over-generalizating.

I think the confusion here is over whether it needs to be one or the other--it doesn't (and shouldn't). It should be possible to use both, but that's currently not the case. A good WYSIWYG should handle both intelligently, similar to Microsoft Word or WordPress.

They're not sports teams; we're not rooting for our favorite tag here. There's not even any need to weigh the pros and cons of using one or the other: if they're both used as they're semantically intended to be used, you get the best of both worlds.