docs: do not use br-tag for non-significant breaks

According to the W3C, we shouldn't use the br-tag unless the line-break
is part of the content:

https://www.w3.org/TR/2011/WD-html5-author-20110809/the-br-element.html

All of these instances are for non-content usage, and is as such technically
out-of-spec. So let's either remove them, or split paragraphs, based on
how related the content are.

Signed-off-by: Erik Faye-Lund <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>

1 files changed, 22 insertions, 19 deletions

diff --git a/docs/releasing.html b/docs/releasing.html
index 12f24fe52d1..873cc25eb9b 100644
--- a/docs/releasing.html
+++ b/docs/releasing.html
@@ -36,7 +36,9 @@
 <p>
 This document uses the convention X.Y.Z for the release number with X.Y being
 the stable branch name.
-<br>
+</p>
+
+<p>
 Mesa provides feature and bugfix releases. Former use zero as patch version (Z),
 while the latter have a non-zero one.
 </p>
@@ -57,7 +59,9 @@ For example:
 <p>
 Releases should happen on Wednesdays. Delays can occur although those
 should be kept to a minimum.
-<br>
+</p>
+
+<p>
 See our <a href="release-calendar.html" target="_parent">calendar</a>
 for information about how the release schedule is planned, and the
 date and other details for individual releases.
@@ -85,10 +89,14 @@ approximately 48 hours before the actual release.
 
 <p>
 Note: There is one or two releases overlap when changing branches. For example:
-<br>
+</p>
+
+<p>
 The final release from the 12.0 series Mesa 12.0.5 will be out around the same
 time (or shortly after) 13.0.1 is out.
-<br>
+</p>
+
+<p>
 This also involves that, as a final release may be delayed due to the
 need of additional candidates to solve some blocking regression(s),
 the release manager might have to update
@@ -167,9 +175,8 @@ good contact point.
 
 <p>
 <strong>Note:</strong> If a patch in the current queue needs any additional
-fix(es), then they should be squashed together.
-<br>
-The commit messages and the <code>cherry picked from</code> tags must be preserved.
+fix(es), then they should be squashed together. The commit messages and the
+<code>cherry picked from</code> tags must be preserved.
 </p>
 
 <p>
@@ -252,9 +259,8 @@ stabilisation and bugfixing.
 
 <p>
 Note: Before doing a branch ensure that basic build and <code>meson test</code>
-testing is done and there are little to-no issues.
-<br>
-Ideally all of those should be tackled already.
+testing is done and there are little to-no issues. Ideally all of those should
+be tackled already.
 </p>
 
 <p>
@@ -300,7 +306,8 @@ It comes shortly after outstanding patches in the respective branch are pushed.
 Developers can check, in brief, what's the status of their patches. They,
 alongside very early testers, are strongly encouraged to test the branch and
 report any regressions.
-<br>
+</p>
+<p>
 It is followed by a brief period (normally 24 or 48 hours) before the actual
 release is made.
 </p>
@@ -330,10 +337,8 @@ Barring reported regressions or objections from developers.
 <p>
 Patch does not fit the
 <a href="submittingpatches.html#criteria" target="_parent">criteria</a> and
-is followed by a brief information.
-<br>
-The release maintainer is human so if you believe you've spotted a mistake do
-let them know.
+is followed by a brief information. The release maintainer is human so if you
+believe you've spotted a mistake do let them know.
 </p>
 
 <h2>Format/template</h2>
@@ -623,10 +628,8 @@ website. Manually check that it is updated 5-10 minutes after the final <code>gi
 
 <p>
 Parse through the bugreports as listed in the docs/relnotes/X.Y.Z.html
-document.
-<br>
-If there's outstanding action, close the bug referencing the commit ID which
-addresses the bug and mention the Mesa version that has the fix.
+document. If there's outstanding action, close the bug referencing the commit
+ID which addresses the bug and mention the Mesa version that has the fix.
 </p>
 
 <p>