It used to be possible to conceal multiple spoiler lines like this:
[spoiler]Darth is Anakin
Rosebud is a sled
Everybody dies[/spoiler]
But this no longer works.
You can still do a mid-line spoiler like this but multi-line spoilers require the [spoiler] tag to appear on a line by itself.
[spoiler]
multi
line
spoiler
[/spoiler]
Can we get the old behavior back?
The behavior of [quote] seems to have changed as well.
BBCode quotations now have to include [quote] on a line by itself, which is annoying.
BBCode for quote is only block, no more inline now.
[spoiler]
This still works?
[/spoiler]
This still works?
On the block syntax you need a line break, you can’t mix inline and block.
The discussion is here:
This seems like the key post talking about this issue:
I think I agree with that for [quote], because [quote] affects the entire block of text; it’s nonsensical to start a quote in the middle of a non-quote line.
But there’s nothing terrible about that for [spoiler]. An exception should be made for inline multi-line spoilers.
There already appears to be some special case code. Consider these examples:
[spoiler]spoiler text[/spoiler]
[quote]quote text[/quote]
These behave totally differently. The spoiler works, but the quote doesn’t.
spoiler text
P.S. I don’t really care about [quote] but I think that last [quote] example should work, too.
[spoiler] is an inline / block level element
[quote] is block only
What I eliminated was “mixed” mode.
What about this text:
I **think this should be bold
but it is not**
Which render as expected when you remove the newline?
I **think this should be bold
but it is not**
Supporting mid-sentence multiline [spoiler] is at odds with CommonMark philosophy. No other CommonMark syntax operates like that.
I think you’ll find that HTML
operates like that, and HTML is part of CommonMark; we should think of BBCode as more like HTML than like CommonMark asterisks and underscores.
If it were a <spoiler> tag, there would be no question that it should span multiple paragraphs.
Sort of, but the spec is creates broken HTML which we normalize
This <b>is bold
and this is only bold in preview</b>
This is bold
and this is only bold in preview
I’ve filed a separate bug about the preview. The editor and the post result should never differ in that way, right?
“Broken HTML” is a rather philosophical idea. The HTML5 parsing spec explains in detail how user agents are supposed to render unbalanced tags like this: <b>bold <i>bold italic</b> italic</i>
It’s supposed to render like this: bold bold italic italic. “Normalizing” the HTML by ending the </b> without reopening the <i> is not correct behavior for HTML. I claim that it’s not what HTML users would expect it to do, nor is it desirable.
Broken HTML is:
<p>test <b>test</p>
<p>test </b></p>
There is nothing philosophical about what is broken there, run it via a validator.
The validator will tell me that it’s invalid, and the spec makes it clear how it should render: the second paragraph should be bolded. This is what it means to be HTML; it’s specified behavior in response to invalid HTML.
More generally, the HTML parsing spec makes it clear that invalid HTML isn’t “broken.” It’s “invalid,” but it has a specified rendering output, and Discourse is not following it for <b> tags. Despite that, Discourse should follow that for <b> tags, and it should use the same behavior for BBCode.
For comparison, consider XML. XML’s specified behavior is to render nothing when the document contains unbalanced tags. Unbalanced XML tags are broken.
Unbalanced HTML tags render exactly the same way in all browsers. Unbalanced HTML tags are “invalid” but not broken.
P.S. I’ve discovered that I can use <blockquote> instead of [quote] and get back great-looking one-line quotations.
[quote]this is broken[/quote]
<blockquote>but this works great</blockquote>
but this works great
But I still don’t really care about [quote]. I care about spoilers.
This conversation about misnested tags has kinda moved to the other thread. (Including a workaround for nokogiri’s busted HTML parser.)