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

adamgreenough

Well-known member
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.


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.

Screenshot 2020-08-07 at 06.02.24.png
Screenshot 2020-08-07 at 07.48.16.png

Screenshot 2020-08-07 at 06.06.01.png

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!). 😄
 
Last edited:
Upvote 56

adamgreenough

Well-known member
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).

Screenshot 2020-08-09 at 15.06.57.png

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.

Screenshot 2020-08-09 at 15.08.20.png
 

adamgreenough

Well-known member
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. 👍
 
Last edited:

Kevin

Well-known member
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. 🤦‍♂️
 

Attachments

  • Screenshot_20200829-170536_Chrome.jpg
    Screenshot_20200829-170536_Chrome.jpg
    129.9 KB · Views: 21

Tradidi

New member
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!
 

Tradidi

New member
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

Well-known member
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

Well-known member
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.
 

krieglich

Member
You should only replace double-brs with p, the single ones are real line breaks:

Code:
$output = str_replace( "<br />\n<br />\n", "</p>\n<p>", $output );
 
Last edited:

PaulB

Well-known member
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.
 
Top