Really specific formatting bug? Putting 2 "larger than" (quote trigger) characters separated by a paragraph break in a codeblock will add an extra "larger than" character between them.
To simplify the title:
(Formatted text, no space. (Behind the arrows.) While it's expected for quote blocks to not separate with one 'line' between them, it's definitely not expected for the block to be the same size, even w/o text.)
(Formatted text, with a space. Added this one in to contrast with Preformatted w/ space and because it separates the code blocks.)
>
>
>
(Preformatted/Codeblock text, no space. The "quote trigger" arrow in the middle is the bug, since if you look at the "view markdown" option of this post you'll realize that arrow shouldn't be there.)
>
>
(Preformatted/Codeblock text, with a space. This is how I personally fix the bug, if it is that. You can also fix it by typing space into the phantom arrow.)
Now with text inside the quote blocks, for comparison. (And because quoteblocks have to quote something.):
qwerty
asdf
(Formatted text, no space. Here the block expands normally for the text.)
qwerty
asdf
(Formatted text, with a space.)
>qwerty
>
>asdf
(Preformatted/Codeblock text, no space. The arrow in the middle I never typed in is still there.)
>qwerty
>asdf
(Preformatted/Codeblock text, with a space.)
Heh, this is a really weird bug. Given how minor an issue this seems to be though, I don't know if this is really worth making a Tildes gitlab issue for (unless @Deimos feels otherwise)... but it's still pretty interesting nonetheless.
Edit: I suspect this section of code might be the culprit:
https://gitlab.com/tildes/tildes/-/blob/master/tildes/tildes/lib/markdown.py#L170-179
Yeah, that's exactly why. As I've said for other markdown fix ideas, pre-processing markdown to make changes is dangerous because you can't really account for "context" like whether it's inside a code block or not.
This is an example of where I didn't follow my own advice, and the problem that it causes. It's definitely technically wrong, but I don't know that it'll ever really be significant in regular use.
Personally, I use blank lines between blockquotes all the time (even when they're from the same source; in that case I use them to indicate that I'm only selecting pieces of the document). I don't see why this preprocessing step is necessary, especially since users can edit their formatting after posting if they got something wrong. But there's something to be said for intuitiveness of course.
For what it's worth, in Safari 14.0 on macOS 10.15.7 there's no arrow in the middle.
Are you sure you aren't mistaking which section is being referred to? Because it's a bit confusing. I took that sentence to mean the block directly above it (where, for what it's worth, I do see an arrow in the middle).
Ah, OK, in that case, then yes, I see it. The entire post is very confusingly written. I recommend the OP reword it to make it more clear.
Whoops. I added in a few (
---) (...formatting lines? Not sure what those things are called) to make it clearer which sections are which. Not sure how to rewrite the text though. I added in a few details and that's about it.Horizontal rules. (I've been reading a lot about HTML elements lately...)
I think the title being so long made it more confusing. I usually expect the details that are in the second sentence of the title to be a paragraph in the body. Generally, if there's more than 1 sentence, it's not a title anymore.
The horizontal rules definitely help clarify things. Sorry if I sounded grumpy.
No arrow in the middle on Safari for iOS either.
Same here for Chromium 85 on Linux.
No arrow on Firefox 82 / Windows 10; nor on Firefox Android.