LeoThreads has trouble with blockquotes. One weird trick is
all that's needed for LeoThreads to display them properly.
All images are annotated screen captures of LeoThreads activity. Edits and annotations were made using MS Paint.
A blockquote is a quotation which is longer than a line of text. If a quote can be compared to a sentence, then a blockquote can be compared to a paragraph (or a block of quotes).
Blockquotes can be made using either HTML or Markdown.
In HTML, the content to be quoted as a block is wrapped in a BLOCKQUOTE element as shown:
In Markdown, each string of text starts with the > character (the "greater-than" symbol). This is the Markdown version of the above HTML example:
When composing long form content at InLeo-- posts at LeoArticles-- blockquotes appear or or less as we would expect them to appear. Although they are formatted differently at LeoArticles than they are by other front-ends, their fundamental behavior is the same.
It makes sense for us to think that the way InLeo handles blockquotes at LeoArticles would be the same for LeoThreads.
As of Sunday 2023-December-03, LeoTheads at InLeo doesn't handle blockquotes properly. This wasn't always the case at LeoThreads. However, with with changes and updates happenning faster than we can track, something happened and blockquote rendering within LeoThreads is broken.
When I tested blockquotes at LeoArticles, I saw that they looked as intended. As a result, there is nothing for me to show regarding blockquotes at LeoArticles.
When I tested blockquotes at LeoThreads, however, I noticed some things I hadn't expected. Based on those discoveries, I found a workaround which will let LeoThreads display blockquotes properly.
For tesing purposes, I'm using the first verse from the "Weird Al" Yankovic song "Yoda" (itself a parody of the song "Lola" by The Kinks)
Below are the tests.
This test is pure plaintext: no HTML/Markdown formatting, no codes.
In the Data Entry Box, the text is typed as it would appear on a sheet of song lyrics. Manual line breaks define the lines of text. Reverse video is used to distinguish each line of text.
The Thread Preview area shows the text as one continuous stream of characters-- no line breaks. Since neither HTML not Markdown formatting was used, this output is expected.
As in Test 1, pure plaintext is used.
In the Data Entry Box, manual line breaks were added to add a blank line between lines of text.
The Thread Preview shows the text as it was intended to appear.
However, this is not a blockquote. It's still pure plaintext. When we want to include a blockquote, it's formatted in a way which makes it obvious it is a blockquote. This is what HTML/Markdown offers.
This is the first test including either HTML or Markdown.
In the Data Entry Box, the Markdown code for blockquote-- the [>] character-- was added only to lines containing text. Blank lines added manually stay untouched. These codes were highlighted in reverse video.
In the Thread Preview, the blockquote indicator has been added before each line containing the Markdown code. Blank lines were left untouched in the Data Entry Box, so in Thread Preview they don't acquire the blockquote formatting.
Notice that the text is treated as 5 separate blockquotes rather than 5 lines which make up 1 blockquote. For each > character, the quoted text gets wrapped inside a pair of double quotes.
This begins with the basis for TEST 3, only it adds Markdown code where blank lines should be.
In the Data Entry Box, all lines-- both text lines and blank lines-- get the Markdown code for blockquote.
The Thread Preview displays the text as intended by the text from the Data Entry Box.
However, this happens when lines alternate between text and blanks. Blockquotes won't always be provided in the format of music lyrics.
TEST 4 is the same as TEST 3, only the HTML element replaces the Markdown character ...
>.
Output for TEST 5 is almost the same as for TEST 4. The key difference? When using HTML for the blockquote, the " character automatically added by InLeo first appears on the 2nd line of the text in the blockquote.
This was an unexpected side effect of using the HTML blockquote element.
TEST 6 is the same as TEST 5 except for one thing: a blank line was added between the opening HTML tag and the first line of content in the blockquote.
In terms of content, the Thread Preview is an exact match of the Data Entry Box. The misplaced " character from TEST 5 appears at the proper location in TEST 6.
When blank lines are added between each line of blockquote content, LeoThreads will display the blockquote correctly. So what happens when the blank lines are not included?
Since TEST 6 was executed as expected, the expectation was for TEST 7 to execute in the same way as TEST 6.
Instead, TEST 7 executed in the same way as TEST 1-- as if no blockquote existed. The blockquote was rendered by LeoThreads as pure plaintext, as if nothing happened.
Will this happen if the HTML element is replaced by its Markdown equivalent?
Markdown code replaced the HTML blockquote element. TEST 8 Thread Preview is the same as TEST 7 Thread Preview.
TEST 7 and TEST 8 failed. However, something useful came out of these 8 tests:
There is a way to break a line manually, as with poetry or song lyrics: the HTML line break element (written as <br />).
What if each line ended with the HTML line break element?
TEST 9 ended up like TEST 7 and TEST 8, except for one difference: Line 1 ended with <br />, and it caused the rest of the content to drop to the next line as expected. The rest of the lines in the blockquote didn't have the HTML line break element, so the Thread Preview continues to mishandle those lines.
It's not actually the blank line itself which causes this behavior, but rather the carriage return/line feed. This is what <br /> adds to a line of text.
So what happens when <br /> is added to each line which needs it?
<br /> Codes AddedSUCCESS -- Each line containing <br /> at the end produced a carriage return/line feed and caused the rest of the content to move to a new line.
This is how the Thread Preview should have appeared from the very beginning when each line of text had its own Markdown code and there were no blank lines.
This worked with Markdown. Can it work with HTML?
<br /> Codes AddedSUCCESS -- Thread Preview for TEST 11 is identical to Thread Preview for TEST 10.
Using just 1 > character, the content can be written as one line of text. Where the line breaks need to happen, insert <br />.
If characeters length is a concern, try this version of the blockquote workaround. If this isn't enough, switch to one of the alternate workarounds (explained below).
| CONCLUSION: |
|---|
If a blockquote needs to appear a certain way (such as for song lyrics or poetry), end each line with <br />. |
Each uses 6 characters. TEST 10 and TEST 11 each had 4 HTML line break elements, so for each test 24 characters were consumed.
If an InLeo BASIC user wants to post a thread, then 216 characters are used for content while 24 get used for display rendering. Although character usage isn't so much a concern for InLeo PREMIUM users, it's still something to keep in mind when a thread needs to appear a certain way.
<br /> Can't Be Used?One alternative workaround is to use the Markdown code for code fencing. Normally this tells the front-end to display whatever is between 2 sets of fences exactly as composed. 3 backtick characters-- ``` begin the code fence, then the content follows, then another set of 3 backtick characters closes the code fence.
Code fencing costs a threader 6 total characters in overhead (compared to 6 for "n" <br />s used). While it saves of total character overhead, it can make the content less readable due to pre-defined font characteristics.
The HTML <pre>...</pre> can be used for code fencing. It was actually meant for situations such as poetry, song lyrics, and Doge.
This produces a Thread Preview similar to what TEST 1 produced, which was a failed test. If code fencing needs to be used in order to accomodate the thread's content, stick with Markdown for code fencing or the HTML <pre>...</pre> element.
There was a time during the early days of LeoThreads when blockquotes could be used without a concern. Even after numerous updates blockquotes worked as expected.
Sometime during Late Summer/Early Autumn 2023 the blockquote feature broke. I don't know what caused this bug, so I can't offer a solution for it. This is a bug the developers may know about, but explaining it as a thread and tagging it with the #feedback hashtag wouldn't be enough.
Until this bug gets fixed, we have 1 solid workaround and 2 so-so workarounds if we want a thread to be displayed in a certain way (especially for poetry like that posted by @bcpoets).
<br />;Besides tagging this post with the expected topic tags and a token tag or two, I tagged this post #feedback.