Sorry for taking a while to look into this. There are multiple issues causing problems here, and it looks like you’ve identified most of them. What should be happening:
-
Section Layouts optionally generate a classed <div> around the content of the layout if a class name is assigned for it, in the Section Layouts: Settings tab, with CSS class name.
-
When those conditions exist, nothing special should be done with regards to special CSS output for that div.class-name. It’s just there in case you want to do something with it. Thus no .class-name CSS should appear anywhere in the output.
-
The one case where we might want to see that is if the Layout defines custom body paragraph formatting, but even then it shouldn’t be assigning it to the .class-name div, but rather each paragraph would then be different from the default paragraph formatting, and thus have a .ps# style serial class created for it. A bit messier than a human designer might do for any of this, but such is the way of machine-generated HTML/CSS from an RTF source.
-
The Layout divs should not enclose content generated by other Layouts entirely. Each layout should have its own div if there is a class name given to it. For example a typical chapter might have this stack of sibling divs:
<div class="heading"> ... </div> <div class="text-section"> ... </div> <div class="text-section"> ... </div> etc.
Your assessment is correct, passive background text formatting is being output as CSS for each layout’s div, and since the HTML output is not correct (all layouts end up in the ‘.heading’ div and none of the other layouts even generate divs), we end up with the inactive passive text formatting for a Layout that doesn’t even print text being used to format other layouts’ text.
The simplest solution (on our end) for fixing the one main problem is to remove the code that is printing section layout div CSS. That shouldn’t be there anyway, and even if it should be there, it definitely shouldn’t be coming out after the area where user CSS is injected.
There isn’t a really clean work-around that resolves all of the above, since even the HTML structure is incorrect, but one can at least open the .epub and delete the div.class-name stuff from the end, to at least exert their own control over the formatting, to what limited ends one can.
Frankly, I don’t use any of Scrivener’s .epub output myself. I use Pandoc’s ePub generator with Scrivener, which is a million times cleaner and easier to work with if you know CSS. That’s me though—I’m the one that designed most of this stock CSS, so staring at a blank CSS input field in the compile format designer with no GUI at all for chaning how anything looks doesn’t phase me, and is if anything more welcome that tangling with a GUI that generates CSS from checkboxes and such.
It’s something to consider though, if you are of a similar inclination. You could even copy and paste the CSS out of the generated stylesheet.css file and drop that into the Pandoc Settings compile format pane with adjustments to make it work with Pandoc’s cleaner HTML output.