Quote:
Originally Posted by Purple Lady
I also hate when scene breaks are broken. But an ebook needs to have other ways to show a scene break than just use extra space between paragraphs. An ebook needs some kind of visual marker for a scene break because depending on the font size you use, the scene break could be lost because the paragraphs are on different pages.
|
Quote:
Originally Posted by JSWolf
When the app doesn't respect text indents of 0 and the scene break is just space, it is very easy to lose when it occurs at the end of the page. Most section breaks that just have space use a top margin of 1em and then a text indent of 0. That's not the correct way to do it. The correct way to do a space only section break is a padding-top of 2em (needs enough space to know it's a section break) and then a text indent of 0. The top margin gets lost when it's at the end of the page. padding doesn't get lost. It carries over to the next page. So you see the space and can easily tell it's a section break.
|
JSWolf, the odd thing is that I knew this distinction but had not thought to apply it to my FirstParagraph style - so thanks for the reminder. The potential problem here is with exactly what you are complaining about
: that not all readers support all aspects of CSS, or they may decide to override it. In which case you can be left with no break - and if the FirstParagraph style keeps its zero indent then not only may no breaking line appear, it can end up looking as if it's part of the previous paragraph.
Which would seem to bring us back to Purple Lady's suggestion that all breaks should have some visual confirmation of the break (something other than just a blank line). I typically use a centred "- - -" or "* * *" in a smaller font so that the break is apparent without being an eyesore. Ideally I would like to use pseudo-element (before/after content) to insert such text, but not all viewers support this capability.
It can be difficult to come up with styles that work well across all viewers. It seems to be necessary to assume the end user does not know CSS, and that an viewer app may do almost anything it wants with the CSS, and this forces the use of safe alternatives as far as possible, and these are not always ideal for end user maintenance.