Remove first line indent fails with a Section Layout Prefix in EPub3 compile

This is quite straightforward, when you have a section layout prefix, a

is generated to wrap the prefix content. This means that the following

which is the “first” paragraph now does not match the p + p CSS rule you use to collapse the text indent. Here is an Inspector view in iBooks showing the issue:

The solution is theoretically simple, use a

instead of a

. I think if you put it in manually then MMD should respect the raw HTML when it converts to EPub…

Hmm, I’m not sure about that. In your particular case a

would be fine, because you are using the prefix to insert an image. But if it is a paragraph, then it is better to use

For this case, wouldn’t the following selector suffice?

p.centered-text + p { text-indent: 0rem; }

OK, so the solution would be to use another CSS rule that excluded a particular class sibling selector. If you can give the

in the prefix an #id then you can use this in the default CSS (it is more specific and thus overrides the p + p rule):

p#sectionprefix + p { text-indent: 0rem; }

I tested it in the inspector and it works:
Screen Shot 2017-12-12 at 22.07.01_SML.png
Note the

wrapping the prefix is given an id=“sectionprefix” and this allows the CSS rule to match and the indent is correctly collapsed…

AmberV: if centered-text is exclusively used there then that would also work, but the #id is going to be more precise…

EDIT: the other issue though is if you can have multiple paragraphs, in which case I wonder whether you should do:

blah

?

OK, just tested and yes if you enter multiple lines, the prefix content generates multiple

's:

[code]

Blah

Doh!

THIS DUMMY SCRIVENER project is intended to illustrate how to: Use folders in the Binder to hold the Title and heading quotation of each chapter. The quotation will not have its first words in upper case. Each folder has a Section Type of Chapter Title and will be given a Section Layout of Chapter with Title in compile.

[/code]

So wrappinng all the

's in an #id’ed

(make sure this div has no margins or padding) would be an easy way to solve this…

My line of thinking then would be that it should be using a “heading-flourish” class instead of something generic. It might very well be you’d want that for other reasons as well, to modify the spacing of the box a bit to design the element into the heading and away from the body text for example.

IDs are probably a better tool in this particular role, I do agree, and if desired they could be achieved through other means: like using a markup pass-through style instead of a simple classed paragraph, and supply whatever HTML you well please….

Although, ha, I just realised something funny happens when you try that. The <$img…> tag goes from generating HTML to inserting a placeholder Unicode glyph for the image. I’m not sure what function that would be used for; might not be intentional.

Well—that aside, you could use this:

<p id="section-flourish"><img src="images/flourish.png" /></p>

…so long as somewhere else “flourish.png” is compiled normally.

There is an interesting side-effect to using that method: Scrivener has no clue what you are doing in a pass-through style nor does it care. So from what I can tell of how the code handles lines that have been injected this way, they are classified as “blank lines”, in terms of the behaviour chosen in the Text Layout compile format pane. Consequence: my code snippet looks like this on output, without any custom CSS:

[code]

SCENE A

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua...

[/code]

That inline style override is directly influenced by the From paragraphs after blank lines checkbox.

Update: still though with the div vs p discussion, isn’t all of this better handled under a broad umbrella of “switch on raw HTML and have at it”, than specific feature adjustments? We’ll never anticipate everything one wants to do in the prefix field, so why not leave it open-ended?

Unless I’m missing something, I think the following is a very simple example of where a hard-coded approach like you’re describing could be problematic: you’re looking at this as a way of inserting an image beneath major section break’s heading—but there is nothing about the section prefix field that implies it only be used once per .xhtml file. There might be a whole sequence of items within a literal eBook section that are using a layout with a prefix, and now the hard-coded ID assumption breaks the more strict validity checks.

I can actually make it so that

is used instead of

around any paragraph that contains nothing but an image. Is this safe to do or could it have other ramifications?

This isn’t anything to do about the , only that the prefix can generate paragraphs, and any paragraph will stop your p + p rule from working as intended:
Screen Shot 2017-12-12 at 23.21.46.png
The compiler suggests that the first indent will be removed, which it does normally because of the p + p and other CSS rules. But those CSS rules break if the prefix has any content, because it becomes the first paragraph not the content.

This is an edge case for sure, but just to be clear, the problem is with any prefix content that comes after the title. My solution would be a semantic one — a

identifies all content of the prefix, whether it is text or an image. I can’t see this as being a problem, unless there is another CSS rule that is a child not a descendant selector where this would be an issue…

In your particular case it is an image that is the prefix, though.

It is to be expected that if you use text in a prefix, then that will become the first text and should rightly be a paragraph and so will be affected by p+p. That’s not a bug - that’s expected behaviour.

However, I am suggesting that when a paragraph contains nothing but an image, it could be surrounded by

instead of

- would that cause any problems?

As for it being a problem, by the time the MMD and HTML is generated the text has been compiled, so Scrivener has no way of knowing at that point a prefix from anything else.

I’d say in terms of best-practices, a div should ideally only be used as a container for multiple related items rather than as a structural appendage for one single item. If one element needs special treatment, that is what classes and ids are for, if a suitable specific element is not already available.

I would be inclined more toward this, that if a prefix or suffix is comprised of multiple block elements then it could be wrapped in a div. It would give one additional formatting power in terms of handling the prefix as a whole, without resorting to pass-through styles.

But, importantly, that would reduce flexibility, right? At the moment I can do this, in combination with the above inclusion of an image:

And get the following HTML:

[code]

SCENE A

12:32 — Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua....

[/code]

I wouldn’t be able to get that result if the code through a div around the section-prefix because it had multiple block elements.

It’s an assumption that if a prefix/suffix has multiple block level elements we will want to semantically group them together with a div element—and that might be a safe assumption in many cases, but it might step on some toes in others in a way that cannot be worked around. (Whereas one can always insert divs into their prefix through the use of pass-through styles).

Hm, this is thorny edge case indeed. AmberV is correct in that for potential inline content you don’t want an intervening block element. In which case the

is only appropriate if the content has a newline after it. This also applies to an as the can be inline or block depending on its placement. So if an image is alone and terminated with a newline, then
, otherwise a

or a depending on line termination?

So back to my earlier suggestion, you mean? An image on its own gets

around it instead of

?

If it is a lone image with a newline, then IMO yes.

But not if it is an epigraph with an attribution line (two paragraphs)?

Eh? I don’t understand…

I mean to say, it’s a single-use solution, and again, not the best in terms of producing well-formed HTML. What is being described as the problem to be solved—whether paragraph formatting intended for the first paragraph of a section should be applied to content in the suffix, and if not, how best to get around that—is something that could be a problem with different kinds of content, not just one single image on its own line (with the additional stipulation that the style used for the image must be generic).

[size=120]Alternative Example[/size]

If the idea is to come up with a solution that doesn’t require custom CSS—and that may be fine idea, don’t get me wrong—then I think the solution should handle more than just one example. To demonstrate what I mean by other examples, here is a simple variation on the above settings, adding a few lines of custom metadata:

The HTML code produced by this example is as follows:

[code]

CHAPTER ONE

Red Book

Words are the only bullets in truth's bandolier. And poets are the snipers.

— George Wu

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

[/code]

(P.S. Out of curiosity, why does the Title style in the Ebook format use an h2 heading by default, and the subtitle an h3? What is occupying the role of h1? Is that an ePub good-practice thing?)

We have the same exact problem as before—the p + p selector fails because the attribution is a paragraph as well.

A div would solve that—the problem is coming up with a safe trigger for inserting one. It might be simply that if the prefix terminates with a carriage return, or if the suffix begins with one, then it is a safe assumption to wrap the content of the field in a div—no matter what it may be. It might come back to bite us if someone tries to do something I’m not thinking of at the moment, but I think that’s a pretty safe approach. It has the possibility of generating less than ideal HTML, but that’s a pretty minor objection in the grand scheme.

[size=120]CSS Solution A[/size]

That aside I still think it is worth looking at this problem as something that can be solved without adding structure, first, to see if these solutions are satisfactory in and of themselves. To put it to a comparison, when you insert a separator into the HTML, you class it and have CSS designed to suppress the following paragraph indent. What you don’t do (and rightly so) is insert the unclassed separator paragraph into a div merely to dodge the p + p. :slight_smile:

Again, as with the initial example, the solution can be done purely with CSS and style application by the user. You don’t need a programmatically inserted div to solve this problem. With the above example here, all I need is:

p.attribution + p { text-indent: 0rem; }

If the epigraph wasn’t there and the HTML was:

[code]

CHAPTER ONE

Red Book

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

[/code]

Now what we need conceptually identical:

p.chapter-flourish + p { text-indent: 0rem; }

The logic here is no different than behind why we have stuff like .br + p and .separators + p exclusions in the stock CSS generation.

The main reason those solutions have been ruled out as inapplicable above (so that we cannot recommend using “p.centered-text + p”) is that the “Centered Text” style is being used generically for all text that is centred and sometimes might be used in a context where the following line should be indented normally.

To my mind, that suggests the Format ought to have two styles, one that blocks the following indent and the other that does not—not because there are different needs in formatting, but because the reason for not blocking the following indent is surely a semantic argument. Or to put it another way, a major element like a component of the chapter heading should probably not be using a general-purpose text alignment class.

[size=120]CSS Solution B[/size]

Okay—but say one doesn’t want two styles, and definitely must use one style for both the chapter heading elements and general text. This is still something that can be solved purely with CSS, no structural elements inserted—because we already have all of the structure we need here. CSS allows us to take into account the context of the thing that is context to the paragraph following it (whew!). We might not want “.centered-text” to always suppress the following indent, but would it be safe to say we always want it to suppress the following indent when it itself follows chapter heading structure? Well then…

.title + .centered-text + p, .subtitle + .centered-text + p { ... }

That’s maybe even a safe enough thing to assume, that it’s worth putting into the stock built-in format (after vetting all contexts, I just looked at this one code example) along with the separator and br overrides.

[size=120]Structural Hard-Coded Solutions[/size]

One last point: this isn’t just a problem with the section prefix/suffix! You can also get to to this same condition using the title suffix field, which produces the following HTML:

[code]

CHAPTER ONE

Red Book

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

[/code]

So whatever was done would perhaps need to be done to images in general, not just those found in the section prefix/suffix. And to make it generally useful to figures in the text, you could maybe throw in a dash of your Caption style detection code from MMD to make the following:

[code]


<img … />

[/code]

And for other cases, like the one found inside of the section-prefix:

[code]


<img … />

[/code]

It’s again, not the cleanest HTML out there, but it won’t break anything.

Side-effect, all paragraphs following figures get their indent suppressed. Personally I prefer that look myself, and I think most people would conceptually think of From all paragraphs following other elements to, in this case, include images.

As I said above, by the time the HTML is injected in the code, there is no concept of anything being title prefixes, section layout prefixes or anything else - there are just rich text paragraphs that need converting to HTML and MMD, nothing else. So the solution cannot rely on knowing that this sequence of paragraphs is a section layout prefix or any such.

I’m still confused as to the suggested solution. Right now, if an image is detected as being on its own paragraph, it gets wrapped in a

block. Instead, should this be:

  • If an image is on its own paragraph, wrap it in a
    block.
  • If a paragraph of the style set as the “Caption” style appears above or below, include that in the
    block.

?

Confirmed! :slight_smile: