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

[KB]

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

Eh? I don't understand...

[AmberV]

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).

Alternative Example

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: Select all

<h2 class="title">CHAPTER ONE</h2>
<h3 class="subtitle">Red Book</h3>
<p class="chapter-flourish"><img src="images/flourish.png" alt="" id="flourish" style="height:26px;width:94px;" /></p>
<p class="epigraph">Words are the only bullets in truth's bandolier. And poets are the snipers.</p>
<p class="attribution">— George Wu</p>

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


(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.

CSS Solution A

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.

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:

Code: Select all

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


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

Code: Select all

<h2 class="title">CHAPTER ONE</h2>
<h3 class="subtitle">Red Book</h3>
<p class="chapter-flourish"><img src="images/flourish.png" alt="" id="flourish" style="height:26px;width:94px;" /></p>

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


Now what we need conceptually identical:

Code: Select all

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.

CSS Solution B

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…

Code: Select all

.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.

Structural Hard-Coded Solutions

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: Select all

<p class="chapter-title-with-suffix-page-padding"><br /></p>
<div class="chapter-title-with-suffix">
<h2 class="title">CHAPTER ONE</h2>
<h3 class="subtitle">Red Book</h3>
<p class="chapter-flourish"><img src="images/flourish.png" alt="" id="flourish" style="height:26px;width:94px;" /></p>

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


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: Select all

<div class="image style-name">
    <img ... />
    <p class="caption">...</p>
</div>


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

Code: Select all

<div class="image style-name">
    <img ... />
</div>


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.

[KB]

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 <div> block. Instead, should this be:

- If an image is on its own paragraph, wrap it in a <div> block.
- If a paragraph of the style set as the "Caption" style appears above or below, include that in the <div> block.

?

[AmberV]

Confirmed!