More Margin Questions

[bookman156]

I didn't understand until recently the recommendation I received in this forum not to use margin for spacing, but padding instead. In web design this makes no sense, but in ebooks I came across a good example recently in the PocketBook Reader in Android. I altered the margin all around the page and this completely destroyed the margins I have been using to space type. On changing it to padding instead I could alter the page margin without any effect on my spacing.

As for line-height, I experimented with removing, but have reinstated, as without line-height being set you may end up having no choice but too tight or too spaced. It is the case on the above-mentioned reader for example. But if you set line-height (in em) to what you think is aesthetically desirable then this is reflected in the reader, effectively giving you access to inbetween measures that are in any case relative to the font size, if you alter it.

As for default units, I have seen people use pt in ebooks, which so far as I know is solely a print measure. I always use em. 12pt only equals 1em for 12pt type. For 10pt type 1em is 10pt. I have no idea how ereaders use pt, or whether they do, but em is better as a relative unit.

[bookman156]

Based on the above, I'd probably agree with everyone here and just remove the top/bottom margins from everywhere in my CSS except where I specifically want some different spacing.

That's precisely where you should use padding or you risk having your margin space overwritten simply because someone slightly changes the all-round page margin in their ereader. It seems to vary between ereaders, altering the page margin on the Lithium Reader in Android leaves your own other special margins intact, for example, but not in PocketBook Reader. Padding sidesteps the issue. In epubs I only use margin now for page margin (0.5em), setting to zero on the p tag, and in a transitional hr tag:

hr.transition {
    margin: 1.5em 40% 1.55em 40%;
    border: 0;
    border-bottom: 1px solid darksalmon;
}

[JSWolf]

Originally Posted by bookman156

I didn't understand until recently the recommendation I received in this forum not to use margin for spacing, but padding instead. In web design this makes no sense, but in ebooks I came across a good example recently in the PocketBook Reader in Android. I altered the margin all around the page and this completely destroyed the margins I have been using to space type. On changing it to padding instead I could alter the page margin without any effect on my spacing.

That is a mistake. You do not want to alter the margins all around the screen. You really don't. You want to let the person reading set the margins if the program has that as an option. For example, Kobo Readers have the option to change the margins. You don't want to take away the user's choice of margins.

As for line-height, I experimented with removing, but have reinstated, as without line-height being set you may end up having no choice but too tight or too spaced. It is the case on the above-mentioned reader for example. But if you set line-height (in em) to what you think is aesthetically desirable then this is reflected in the reader, effectively giving you access to inbetween measures that are in any case relative to the font size, if you alter it.

As for line-height, get rid of it it. Kobo has a setting for Line spacing and if you set it, you'll once again ruin the user's choice.

As for default units, I have seen people use pt in ebooks, which so far as I know is solely a print measure. I always use em. 12pt only equals 1em for 12pt type. For 10pt type 1em is 10pt. I have no idea how ereaders use pt, or whether they do, but em is better as a relative unit.

Do not use px or pt. Use em or %. But some publishers overuse %. Mostly you want to use em as % can change based on the device being used to read the eBook. A text-indent of 5% is smaller on a PW3 and larger on a Kindle Oasis. A text indent of 1.2em is the same on both devices.

So please don't fool around with margins or line height. Leave L/R margins at 0 and no added line height. And also don't add in paragraph spaces. You will make the reading experience better for more people then you would doing it the way you said earlier in this post. This is from experience.

[JSWolf]

Originally Posted by bookman156

That's precisely where you should use padding or you risk having your margin space overwritten simply because someone slightly changes the all-round page margin in their ereader. It seems to vary between ereaders, altering the page margin on the Lithium Reader in Android leaves your own other special margins intact, for example, but not in PocketBook Reader. Padding sidesteps the issue. In epubs I only use margin now for page margin (0.5em), setting to zero on the p tag, and in a transitional hr tag:

hr.transition {
    margin: 1.5em 40% 1.55em 40%;
    border: 0;
    border-bottom: 1px solid darksalmon;
}

Your 1.5em top/bottom margins are too large. That would make it slightly more then 3em. Too large for a section break. You want something like 0.9em top/bottom margins. Also, you should be making that line 2px as 1px can be a bit too thin on a 300dpi eInk screen. Also, darksalmon is a bad idea for eInk screens. Leave the line at the default color of black.

As for padding, you don't need it just in case someone decides to change the L/R margins. That is handle properly. I know Kobo handles it properly. As for @page, get rid of it. It's not needed. Don't monkey with the margins. Let us set our margins. As for padding, it's best used for a section break where you are just using blank space. Otherwise, there's very little need to use padding.

[bookman156]

That is a mistake. You do not want to alter the margins all around the screen. You really don't. You want to let the person reading set the margins if the program has that as an option. For example, Kobo Readers have the option to change the margins. You don't want to take away the user's choice of margins.

You misunderstand, although I'm not quite sure how, probably reading too quickly. That's what I was talking about. I'm talking about people altering the page margin in their own ereader and how that affects your own use of a margin on say an epigraph page, which as padding is unaffected.

As for line-height, get rid of it it. Kobo has a setting for Line spacing and if you set it, you'll once again ruin the user's choice.

I haven't seen any ereader where setting line-height prevents the reader altering it. Some ereaders ignore what I set anyway, others are benefited because you give access to a line-height that isn't available on the ereader itself.

Do not use px or pt.

Do you not use px for a hr rule? I wouldn't use px for anything else in an epub, and pt never, I was simply saying that I have seen it used.

Leave L/R margins at 0 and no added line height.

Setting a 0.5em margin on the body does no harm, mostly overridden anyway by the device. Setting to 0 is also 'playing around with margins'. I have pointed out a good reason to use line-height.

As for @page, get rid of it. It's not needed.

I don't use that. That's an InDesign export thing. But margin on body is fine.

Your 1.5em top/bottom margins are too large. That would make it slightly more then 3em. Too large for a section break.

Don't agree at all. It's just right. It depends on the book, you shouldn't be so dogmatic about aesthetics. Maybe your aesthetic sense is different to mine. If you want to argue which is better, that's a matter for a boxing ring.

Also, you should be making that line 2px as 1px can be a bit too thin on a 300dpi eInk screen. Also, darksalmon is a bad idea for eInk screens. Leave the line at the default color of black.

Possibly. But I want a line that isn't over-visible. I frankly don't mind if it isn't very visible at all. It's mainly to hold the space for blind people in screen-readers. Sighted people are seeing the space more than the rule. I could even make it invisible, as recommended by the accessibility experts, but I'm less keen on that. It's a space that is respected, and if you see there is a thin grey faint rule there on your eink screen then good. But you may be reading it on an Android reader and be able to see it in colour. And then 2px is certainly too thick. Swings and roundabouts.

[bookman156]

Aesthetics is a moveable feast. I have tried your 0.9em suggestion. At first I thought, no, too crammed. But then looking at it I thought, hmmm, maybe.

One can do no more than say one is willing to rethink everything. That is the only way to decide, to discount or accept ideas after living with them for a while.

[enuddleyarbl]

Originally Posted by bookman156

Aesthetics is a moveable feast. I have tried your 0.9em suggestion. At first I thought, no, too crammed. But then looking at it I thought, hmmm, maybe....

I use a triple-asterisk version of hr with 0.9em top/bottom margins:

hr {
/* Thematic break to use 3 asterisks between parts of story */
  margin-top: 0.9em;
  margin-bottom: 0.9em;
  border: none;
}
hr::before {
  content: "***";
  display: block;
  text-align: center;
}

I was actually wondering if that spacing might be too much. So, your 1.5em top/bottom does sound a bit much to me, too.

You mentioned padding on an epigraph page. Could you post your padding settings for that?

@JSWolfe: you mentioned @page. I just leave what Calibre sticks in there.

@page {
  margin-top: 0;
  margin-left: 0;
  margin-right: 0;
  margin-bottom: 0;
}

At all zeroes, I assumed that's not a problem (especially since I've got the same setting in my body, html setting). Should I delete that or just leave it?

EDIT: And for padding in hr, are you saying I should be using padding-top/padding-bottom set to 0.9em each instead of margin-top/margin-bottom?

[bookman156]

I was actually wondering if that spacing might be too much. So, your 1.5em top/bottom does sound a bit much to me, too.

I test my code in a web-book before going to epub. What I have found is that 1.5em is fine for normal PC screen size, but below 480px, ie a smartphone, then 0.9em works better. So I have changed it to 0.9em in the epub but have two versions depending on screen size on the web-book.

[bookman156]

EDIT: And for padding in hr, are you saying I should be using padding-top/padding-bottom set to 0.9em each instead of margin-top/margin-bottom?

No, you can't have padding on an hr tag, has to be margin. But that margin won't be collapsed in an epub because it is on the hr tag. But margin on a p tag can be collapsed so use padding there.

[bookman156]

You mentioned padding on an epigraph page. Could you post your padding settings for that?

Here is my various epigraph CSS:

p.epigraph {
    padding-top: 8em;
    text-indent: 0;
    text-align: center;
}

p.epigraph1 {
    padding-top: 0.8em;
    text-indent: 0;
    text-align: center;
}

p.epigraph2 {
    padding-top: 2em;
    text-indent: 0;
    text-align: center;
}  

p.epigraphleft {
    padding-top: 8em;
    text-indent: 0;
    text-align: left;
}

p.epigraphright {
    padding-top: 0.8em;
    padding-right: 1em;
    text-indent: 0;
    text-align: right;
}

The 0.8em bits are for the attribution name with a little space after the quote. The 2em is for a second epigraph on the same page as an 8em one. Obviously I may alter depending on length of epigraph after testing.

I originally had the padding as margins, but altering the margin of the page in an ereader can totally collapse an epigraph margin so it's now at the top of the page instead of where I want it to be. By using padding it is unaffected.

[JSWolf]

Originally Posted by bookman156

You misunderstand, although I'm not quite sure how, probably reading too quickly. That's what I was talking about. I'm talking about people altering the page margin in their own ereader and how that affects your own use of a margin on say an epigraph page, which as padding is unaffected.

The programs that adjust the margins keep the all the margins correct while adjusting the overall L/R margins. Padding isn't used much.

I haven't seen any ereader where setting line-height prevents the reader altering it. Some ereaders ignore what I set anyway, others are benefited because you give access to a line-height that isn't available on the ereader itself.

I have a Kobo. It has the option to adjust the line height. But If you have a line height in CSS, it no longer adjusts.

Do you not use px for a hr rule? I wouldn't use px for anything else in an epub, and pt never, I was simply saying that I have seen it used.

I use em and %.

hr {
  margin-top: 0.9em;
  margin-right: 40%;
  margin-bottom: 0.9em;
  margin-left: 40%;
  border-top: 2px solid;
}

Setting a 0.5em margin on the body does no harm, mostly overridden anyway by the device. Setting to 0 is also 'playing around with margins'. I have pointed out a good reason to use line-height.

On my Kobo, I can change the L/R margins. But I can only increase from what you've set in the eBook. So if you set a .5em margin, I cannot make that any smaller.

I don't use that. That's an InDesign export thing. But margin on body is fine.

Setting a margin on body is fine as long as it's zero.

Don't agree at all. It's just right. It depends on the book, you shouldn't be so dogmatic about aesthetics. Maybe your aesthetic sense is different to mine. If you want to argue which is better, that's a matter for a boxing ring.

It's not just an aesthetic. Think about those that might be reading this on a smallish phone screen. 3em would be too large.

Possibly. But I want a line that isn't over-visible. I frankly don't mind if it isn't very visible at all. It's mainly to hold the space for blind people in screen-readers. Sighted people are seeing the space more than the rule. I could even make it invisible, as recommended by the accessibility experts, but I'm less keen on that. It's a space that is respected, and if you see there is a thin grey faint rule there on your eink screen then good. But you may be reading it on an Android reader and be able to see it in colour. And then 2px is certainly too thick. Swings and roundabouts.

I did try 1px at first. It was too think on a 300dpi eInk screen. 2px is a good size.

[bookman156]

I have a Kobo. It has the option to adjust the line height. But If you have a line height in CSS, it no longer adjusts.

You can override the publisher's font on a Kobo but not the line-height? That's bad design if so. I'll have to ask a friend with a Kobo whether my stuff is screwed up because of it.

On my Kobo, I can change the L/R margins. But I can only increase from what you've set in the eBook. So if you set a .5em margin, I cannot make that any smaller.

Interesting, though I can't imagine you'd want to go smaller than 0.5em. If you set it to zero, isn't it the case that in some readers the book will open with the text jammed up against the edges of the screen?

[JSWolf]

Originally Posted by bookman156

You can override the publisher's font on a Kobo but not the line-height? That's bad design if so. I'll have to ask a friend with a Kobo whether my stuff is screwed up because of it.

You don't have to ask your friend. I just told you how it works.

Interesting, though I can't imagine you'd want to go smaller than 0.5em. If you set it to zero, isn't it the case that in some readers the book will open with the text jammed up against the edges of the screen?

Some people like the text close to the edge of the screen and some like it close to the edge.

The way I have mine set, 0.5em would be larger then I have it. I have it close to the edge, but not at the edge.

[bookman156]

You don't have to ask your friend. I just told you how it works.

My friend will tell me whether he finds my line-height fine. Not everyone sees a need to continually alter settings on their device. Sometimes they're happy with what comes with the epub and prefer this kind of fine-tuning to the limited settings on the device. On my Kindle, which completely ignores CSS line-height, you have a choice of three line-height settings for all books. Not very bespoke is it? Ideal leading depends on font x-height. And on PocketBook Reader I could only get the line-height I liked by writing the CSS for it myself, which it can still alter. But why alter it when it is actually fine now I have addressed it, unlike what was possible before I set line-height in CSS. People don't take paper books back to the shop because they're so horrified by the leading. Perhaps too much fuss is being made of this.

[JSWolf]

Originally Posted by bookman156

My friend will tell me whether he finds my line-height fine. Not everyone sees a need to continually alter settings on their device. Sometimes they're happy with what comes with the epub and prefer this kind of fine-tuning to the limited settings on the device. On my Kindle, which completely ignores CSS line-height, you have a choice of three line-height settings for all books. Not very bespoke is it? Ideal leading depends on font x-height. And on PocketBook Reader I could only get the line-height I liked by writing the CSS for it myself, which it can still alter. But why alter it when it is actually fine now I have addressed it, unlike what was possible before I set line-height in CSS. People don't take paper books back to the shop because they're so horrified by the leading. Perhaps too much fuss is being made of this.

The thing is, this is an eBook. It's not a pBook where the only choices you have is to read it or not. Some Readers and programs have options to change some of the way the eBook looks. The things you should not set are line-height, margins, and a font-size for the main body text. You cannot go just on Pocketbook Reader as that;s just one program. So you have to set things for the way it works for most. And that means margins to 0, no line-height and default font size for the main text.