[nabsltd]

Originally Posted by JSWolf

I've given no opinion. Its all best practices.

You gave lots of styling opinions. For example, you don't like a line-height greater than 1.1, yet many people find that too tight. This results in your "never use line-height", which is wrong.

As for line-height, there's no need for it as you're not going to be using a dropcap of large first letter.

I use the line-height attribute whenever it is appropriate. I use it on multi-line headings to reduce or increase the spacing between lines. This allows it to change along with font size, instead of remaining fixed. It also allows me to change the space between lines that are part of the same paragraph, split with a <br />.

A large first letter does not work properly on a Kindle because you cannot set the line-height to be smaller.

I have absolutely no problem using line-height of less than 1 so that the span holding larger characters is not used to compute the overall line height. It works perfectly on my Kindle Scribe. I also use it on sub and sup (or anything else that moves text up or down and would often cause a larger computed line height).

The problem with a blank space is that the way most do it, it can be a major fail. If you use a margin to give you that space and it falls at the end/top of a page, the space gets swallowed-up.

I'll bet you didn't know that this happened all the time on physical books too. You just never noticed it because you didn't get to see the "code" underneath. If a section break without a decoration fell at a page break, it often basically disappeared, and the only indicator was the non-indented paragraph.

Also, in a pBook you get *** when the space hits the top/bottom of the page.

This is not universally true. I've got printed books where there is a mixture of "space only" and "decoration" for section breaks, and sometimes the "decoration" falls in the middle of the page, and sometime the "space only" gets swallowed and a new page starts with a non-indented paragraph.

Most embedded fonts do not work well.

Embedded fonts should only be used for something that is not the base reading font. The user gets to pick the base reading font. Using this principle, all embedded fonts work perfectly.

Also, on a Kindle, most people won't see your embedded fonts as they don't switch to Publisher Font.

Choosing "publisher font" is only necessary if the eBook tries to replace the default reading font with an embedded font. When that happens, Kindle ignores it and uses the user-chosen default font. For fonts that are not used to replace the default reading font, embedded fonts display perfectly on Kindle. I have books where entire chapters are a different font from my chosen, and it still works.

Do not use % where em will work better.

% and em are identical for font size, so you can use either in that case. For actual lengths (margins, padding, indents, etc.), both em and % have times when they work better to create the desired look. In general, though, an eBook creator needs to be aware that "em" scales with the font size scaling the device offers while "%" does not. This means that if a user picks a really huge font, "em" for margins can make things very silly (two words per line, or a handful of lines per page), while you can keep your layout somewhat closer to your ideal by using "%" instead.