@nontroppo : Both the [MMD Options] & [Styles] panels are doing effectively the same thing: injecting markup based on the associated semantic style.
While true, I think it there is a very important distinction to be made between these two tools, which explain their differences in output:
-
Style prefix/suffix markup: crucially, these are not a tool for generating Markdown. Sure, we might use them for that purpose (and it is very valid to do so), but they are equally designed for inserting caption numbering in rich text workflows, valid XML in a plain-text Format designed for such, LaTeX or ReStructuredText for the same reasons, and so forth.
-
Pandoc|MultiMarkdown Options: on the other hand are hand-coded to create valid CommonMark compliant Markdown for specific types of markup in a controlled environment. We can do things with them that cannot be done with the freeform style system itself (such as stuff like moving caption styled text that falls above or below a table into the correct position and into markings, to be recognised as such).
To address each in order: when considering that the prefix and suffix system is intended for a much broader usage than Markdown alone, there are presumptions made about it that work better for the majority of the cases in how it might be used. One such common case is that most markup systems make heavy use of the container principle—noisier, but better for machine parsing (and just the sort of thing markup systems like Markdown were designed to avoid), such as <p>Line of text</p>. In such systems, we wouldn’t want to ever see:
<p>First paragraph</p>
<p></p>
<p>Second paragraph</p>
While that isn’t actually invalid, it is poor use of syntax—and other uses of this feature might indeed produce invalid syntax, such as:
{
"p1": "First paragraph",
"": "",
"p2": "Second paragraph",
},
That is going to extend to a lot of the kinds of markup we might want to generate with the feature. Markdown is a bit unusual in how we can assert something about a line with a single mark at the beginning or end of a line. Hold that thought for a moment, while taking a look at the next factor.
On distinction (2) we can make strong assumptions about a contiguous text marked with a style should come out like, based on common usages for a specific type of marking. In CommonMark, this is one single block quote comprised of multiple paragraphs:
> First paragraph.
>
> Second paragraph.
As noted above, if you leave the middle line empty it is actually two block quotes that just so happen to be adjacent. We give the user the power to make the decision of which form to use by whether or not the style usage is truly contiguous. Set the empty line between block quote paragraphs to No Style, and you get two adjacent single-line block quotes. Leave the whole field styled and you get one multi-paragraph block quote.
To me this is a logical and coherent definition of a block, in as much as we can map the concept of invisible formatting to the concept of textual formatting in Markdown. If we apply an invisible format to a line that matches the format of the visible lines around it, it is a declaration of continuity—something we would do with visual markup (the > on an otherwise empty line) in text.
Now returning to where we left off above, you might be asking why we don’t leave that power in place for the style-based approach as well: it has everything to do with common usage producing commonly desired results.
Two adjacent but semantically separate block quotes are a lot more unusual to see than two paragraphs in one quote—there is our commonly desired result. The “sloppy” approach of styling the whole sequence, including the blank line is the most common use, producing the most commonly desired result.
But for prefix/suffix usage it’s actually the other way around! If the style prefix/suffix system were to work like the dedicated Block Quote feature, then the sloppy result (common use) would produce what would be in most cases be the undesirable result! That would then mean a whole lot more fiddling around with style commands to enforce a strict No Style Empty Line doctrine. Bear in mind, we aren’t just talking about block quotes in Markdown here any more—we may be talking about 4,000 word ranges of styled text! Can you imagine having to manually manage invisible markings between several dozen paragraphs and having to laboriously proof the output for bad-practice empty line syntax injection?
We didn’t think anyone would much like having to do that either.
That leads us to the final, and potentially most important factor, and that is that styles are not only injected in the editor (thank goodness). In fact best practices in Scrivener are to avoid bulk style usage in the editor. Let’s go back to our paragraph style usage in HTML/XML. It would be best practices to not apply that style in the editor, but rather to set up your body text Section Layout to style the text for you on output.
And now we are in an impossible position if style prefix/suffix values had an impact on empty lines. That best practice approach would be completely unviable because the compiler is going to create contiguous style ranges between any exceptional use of styles in the editor (actual block quotes, etc.).
I would not say it has much to do with “noobiness” as you put. Each tool has its own merits, and I suppose if anything we could say that “sloppy” style usage is perhaps a bad habit, but again it’s really the only practical way to work for very long ranges meant to be semantically contiguous, and the only effective way to work if we delegate that busy-work to the compiler instead.
) like LaTeX and markdown to line-semantics of html and friends?
— but at least a nerd like me would prioritise other improvements to the style-mapping system in the compiler[1].