Attempt to fix overflow problem in blockquotes

A problem was discovered in blockquotes for really long text, in
particular in the guidelines: 2305567963945518424753102147331756070. The
problem was that the number flowed outside the border. That should no
longer happen. Below is what should happen instead, though it's hard to
be sure how it will look in every case.

In Safari on a 16" MacBook Pro with Safari all across the screen it is
not a problem but shorter text will be in a smaller box (this means
the green box will vary in size depending on what is in it but this does
not seem to be a big problem).

With Safari in an old iPhone 8 Plus the box can go a bit further beyond
the screen width but text does not go beyond the boundary and one can
scroll left/right at need.

With Safari in an iPhone 14 Pro Max there is currently a cache issue but
earlier (when playing with different options) it seemed to fit and in
Simulator (in macOS) it looks good. However in Simulator earlier it was
fine even when the iPhone 14 Pro Max was not.

In responsive mode in Safari with a small width (400px) it is the same
result as the iPhone 8 Plus.

Finally with Safari in macOS with the window decreased in width it is
fine but it already was fine because it doesn't go to the size of a
phone (though it has helped fix problems with phones).

I have changed the font-style to normal (was italic) in blockquotes also
as this way italics can show up specially if requested.

The guidelines had some line breaks in the blockquotes that were
problematic; these have been removed as they are not necessary and it
did not look good either with smaller width screens.

More testing will likely be useful but it should be a lot better now.

ioccc.css

@@ -724,12 +724,13 @@ transition: all .3s ease;
 
 blockquote {
     margin: 1em 0 1em 1.7em;
-    padding-left: 1em;
     border-top: 4px solid darkgreen;
     border-left: 4px solid darkgreen;
     border-bottom: 4px solid darkgreen;
     border-right: 4px solid darkgreen;
-    font-style: italic;
+    font-style: normal;
+    overflow-wrap: break-word;
+    width: fit-content;
 }
 
 /* This rule makes sure that text in <blockquote><p>..</p></blockquote> is

next/guidelines.html

@@ -1135,44 +1135,47 @@ architectures. For instance, more recent versions of <code>macOS</code> do <stro
 to note such limitations in your <code>remarks.md</code> file. For example if your
 submission factors values up to a certain size, you might want to state:</p>
 <blockquote>
-<p>This submission factors values up <code>2305567963945518424753102147331756070</code>.<br>
+<p>This submission factors values up <code>2305567963945518424753102147331756070</code>.
 Attempting to factor larger values will produce unpredictable results.</p>
 </blockquote>
 <p>The <a href="../judges.html">judges</a> might try to factor the value -5, so you want to might state:</p>
 <blockquote>
-<p>This submission factors positive values up <code>2305567963945518424753102147331756070</code>.<br>
-Attempting to factor large values will produce unpredictable results.</p>
+<p>This submission factors positive values up
+<code>2305567963945518424753102147331756070</code>. Attempting to factor large values will
+produce unpredictable results.</p>
 </blockquote>
 <p>However the <a href="../judges.html">judges</a> might try to also factor 0, so you want to might state:</p>
 <blockquote>
-<p>This submission factors values between 1 and <code>2305567963945518424753102147331756070</code>.<br>
-Attempting to factor values outside that range will produce unpredictable results.</p>
+<p>This submission factors values between 1 and
+<code>2305567963945518424753102147331756070</code>. Attempting to factor values outside
+that range will produce unpredictable results.</p>
 </blockquote>
 <p>Moreover the try to also factor 3.5 or 0x7, or Fred, so you want to might state:</p>
 <blockquote>
-<p>This submission factors integers between 1 and <code>2305567963945518424753102147331756070</code>.<br>
-Attempting to factor anything else will produce unpredictable results.</p>
+<p>This submission factors integers between 1 and
+<code>2305567963945518424753102147331756070</code>. Attempting to factor anything else
+will produce unpredictable results.</p>
 </blockquote>
 <p>You submission might be better off catching the attempt to factor bogus values
 and doing something interesting. So you might want to code accordingly and state:</p>
 <blockquote>
-<p>This submission factors integers between 1 and <code>2305567963945518424753102147331756070</code>.<br>
+<p>This submission factors integers between 1 and <code>2305567963945518424753102147331756070</code>.
 Attempting to factor anything else will cause the program to insult your pet fish Eric.</p>
 </blockquote>
 <p>The <a href="../judges.html">judges</a> might not have a pet fish named Eric, so might want to state:</p>
 <blockquote>
 <p>This submission factors integers between 1 and
-<code>2305567963945518424753102147331756070</code>.<br>
-Attempting to factor anything else will cause the program to insult your pet fish Eric,<br>
-or in the case that you lack such a pet, will insult the pet that you do not have.</p>
+<code>2305567963945518424753102147331756070</code>. Attempting to factor anything else
+will cause the program to insult your pet fish Eric, or in the case that you
+lack such a pet, will insult the pet that you do not have.</p>
 </blockquote>
 <p>When all other things are equal, a submission with fewer limitations will be judged
 better than a submission with lots of limitations. So you might want to code accordingly
 and state:</p>
 <blockquote>
-<p>This submission attempts to a factor value of any size provided that the program is<br>
-given enough time and memory. If the value is not a proper integer, the program<br>
-might insult a fish named Eric.</p>
+<p>This submission attempts to a factor value of any size provided that the
+program is given enough time and memory. If the value is not a proper integer,
+the program might insult a fish named Eric.</p>
 </blockquote>
 <p><strong><code>|</code></strong> Do not fear if you’re not 100% sure of the significance of <code>2305567963945518424753102147331756070</code> as it is not of prime importance: or is it? :-)</p>
 <p><strong><code>|</code></strong> We <strong>DISLIKE</strong> the use of use ASCII tab characters in markdown files, such as in the required <code>remarks.md</code> file.</p>

next/guidelines.md

@@ -1034,44 +1034,47 @@ architectures. For instance, more recent versions of `macOS` do **NOT** support
 to note such limitations in your `remarks.md` file.  For example if your
 submission factors values up to a certain size, you might want to state:
 
->   This submission factors values up `2305567963945518424753102147331756070`.<br>
->   Attempting to factor larger values will produce unpredictable results.
+>   This submission factors values up `2305567963945518424753102147331756070`.
+Attempting to factor larger values will produce unpredictable results.
 
 The [judges](../judges.html) might try to factor the value -5, so you want to might state:
 
->   This submission factors positive values up `2305567963945518424753102147331756070`.<br>
->   Attempting to factor large values will produce unpredictable results.
+>   This submission factors positive values up
+`2305567963945518424753102147331756070`. Attempting to factor large values will
+produce unpredictable results.
 
 However the [judges](../judges.html) might try to also factor 0, so you want to might state:
 
->   This submission factors values between 1 and `2305567963945518424753102147331756070`.<br>
->   Attempting to factor values outside that range will produce unpredictable results.
+>   This submission factors values between 1 and
+`2305567963945518424753102147331756070`.  Attempting to factor values outside
+that range will produce unpredictable results.
 
 Moreover the try to also factor 3.5 or 0x7, or Fred, so you want to might state:
 
->   This submission factors integers between 1 and `2305567963945518424753102147331756070`.<br>
->   Attempting to factor anything else will produce unpredictable results.
+>   This submission factors integers between 1 and
+`2305567963945518424753102147331756070`.  Attempting to factor anything else
+will produce unpredictable results.
 
 You submission might be better off catching the attempt to factor bogus values
 and doing something interesting.  So you might want to code accordingly and state:
 
->   This submission factors integers between 1 and `2305567963945518424753102147331756070`.<br>
+>   This submission factors integers between 1 and `2305567963945518424753102147331756070`.
 >   Attempting to factor anything else will cause the program to insult your pet fish Eric.
 
 The [judges](../judges.html) might not have a pet fish named Eric, so might want to state:
 
 >   This submission factors integers between 1 and
-`2305567963945518424753102147331756070`.<br>
->   Attempting to factor anything else will cause the program to insult your pet fish Eric,<br>
->   or in the case that you lack such a pet, will insult the pet that you do not have.
+`2305567963945518424753102147331756070`.  Attempting to factor anything else
+will cause the program to insult your pet fish Eric, or in the case that you
+lack such a pet, will insult the pet that you do not have.
 
 When all other things are equal, a submission with fewer limitations will be judged
 better than a submission with lots of limitations.  So you might want to code accordingly
 and state:
 
->   This submission attempts to a factor value of any size provided that the program is<br>
->   given enough time and memory.  If the value is not a proper integer, the program<br>
->   might insult a fish named Eric.
+>   This submission attempts to a factor value of any size provided that the
+program is given enough time and memory.  If the value is not a proper integer,
+the program might insult a fish named Eric.
 
 **`|`**   Do not fear if you're not 100% sure of the significance of `2305567963945518424753102147331756070` as it is not of prime importance: or is it?  :-)