I am trying out Scriveners features to create some technical documentation. One of the style elements I need is to produce text in box with colored background. I am trying to accomplish that with a custom CSS file containing the following definition
In the Scrivener source I want to define a colored box like this:
<div class="YellowBox">
This is the first paragraph inside such a yellow box.
This is an example of a second paragraph in the yellow box. Just to see that our box can contain multiple paragraphs.
</div>
To pass the div tags through the compiler without touching them, I have defined a style called HTML and declared that style in the compile settings as “Text is raw markup”. To see my paragraphs in the source standing out similar to the final result, I have assigned them a style called YellowBox.
That all kind of seems to work, but the result of Scrivener’s compile is not exactly what I expected:
<p class="html"><div class="YellowBox"> </p>
<p style="margin-bottom: 0.33rem; margin-left: 0rem; text-indent: 0rem;
line-height: 1.1em;">This is the first paragraph inside such a yellow box.</p>
<p style="margin-bottom: 0.33rem; margin-left: 0rem; text-indent:
0rem; line-height: 1.1em;">This is an example of a second paragraph in the yellow box.
Just to see that our box can contain multiple paragraphs.</p>
<p class="html"></div></p>
How can I keep Scrivener from enclosing my div tag into its own “<p>” tag?
And how can I tell scrivener that paragraphs of style “YellowBox” don’t need to be compiled with all the paragraph styles, which I set just to see the paragraphs emphasized in my source text?
Perhaps I am trying to do this all in a totally wrong way. Any suggestions on how to it the “right” way?
All right, so that’s definitely a bug that you are running into. This is an older one that was fixed before launch, but it looks like it has regressed.
As for best practices, what you are doing is perfectly fine, and probably the best way to go if you want the interior paragraphs to be parsed for RTF formatting and converted to HTML for you.
Another approach is to wrap the entirety of the text in a “Yellow Box” style, set that itself to be raw markup, and then inject the necessary HTML using the various style prefix/suffix fields (which are also a bit buggy).
This example project shows how this could be done. If you take a look at the Yellow Box settings in the Styles compile format pane, you’ll see I’m inserting the div markup into the style prefix/suffix files, which in theory should wrap around the entire styled range, and then inserting <p> elements around each line.
So that keeps HTML out of your editor entirely, and keeps the generation of HTML centrally generated—but it does come at the downside of needing to either use HTML in the editor where you need inline formatting, or using styles which insert raw HTML for that purpose, within these ranges.
Thanks @AmberV! I really appreciate that you even put together a small demo project!
Let me just rephrase to see if I understood correctly. The Prefix/suffix fields should actually work as “raw text” and the <p> enclosure produced by the compiler is a bug.
The Paragraph prefix/suffix fields are also “raw text”, but enclose each paragraph, while the Prefix/suffix fields enclose a contiguous sequence of equally styled paragraphs. (The manual is not really clear about that, so that is what I guessed.)
The method with defining the “<div class=…> … </div>” enclosure in the compiler settings is exactly what I was striving for, as it keeps the HTML and CSS code separate from the source - just as you point out.
Btw. : Is there a reason why the CSS pane does only appear for epub3 compiles and not for epub2? Seems to be an oversight to me.
Thanks for your help. Really appreciate it. Do you have any comments to my other post (Workflow Recommendations ?
Correct on both counts. When a style is set to raw markup, all methods it has for influencing text will be treated as HTML (or Markdown, etc.), no matter how it got there (replacements, prefixes, text from the editor). They should function as a direct pass-thru.
As for the interplay between the four prefix/suffix fields, in the functional design, you could in effect create a style that produces this (where we are using an <$n:listitem> counter in the prefix field):
<ol class="harvard-style">
<li id="list-item-23">First line from editor</li>
<li id="list-item-24">Second line from editor</li>
</ol>
The method with defining the “<div class=…> … </div>” enclosure in the compiler settings is exactly what I was striving for, as it keeps the HTML and CSS code separate from the source - just as you point out.
Exactly, you can much more easily flip the switch over to RTF and do something completely different with the text. Of course there are ways to inject HTML (or other markup) from the editor in a multi-output environment as well—which is why your first try is still a good approach—that is what that Delete text of this style flag is for. You do have to watch for whitespace though.
ePub2: dunno. It was originally meant to be removed, and was, and then got added back, and I honestly don’t know how much QA or testing it got during the beta. Honestly I’d use Calibre to downgrade an ePub3 if you really need one.
I have your other thread bookmarked to take a look at, yup!
Just tried out if this bug had been fixed in version 3.1.1: No, it hasn’t. The contents of paragraphs that have a style marked as “raw markup” in the compile settings is still surrounded by <p> …</p> tags. Too bad, they didn’t fix that.
It was originally meant to be removed, and was, and then got added back, and I honestly don’t know how much QA or testing it got during the beta. Honestly I’d use Calibre to downgrade an ePub3 if you really need one.