InDesign epub code cleanup

[JSWolf]

Originally Posted by Turtle91

Ummm. Not true. I exclusively use ePub 2 as I haven’t gotten around to learning ePub3 yet.

Yes, I can, and do. I’ll take a screen shot and post it when I get home.

Edit:
Looks like you changed your comment while I was writing mine . You had said that code was only good for ePub3, which is not true. We’ve had this discussion before where you think pseudo-selectors are only ePub3, they are not.

Also, here is a screenshot from my phone. I used the above code, ePub2, and have a large first letter, small-caps for the first line - all with no spans or forced uppercase.

On a Kobo that code will not work if reading the eBook as an ePub. It will work if you have the span. RMSDK will not render it unless you get to a late enough version and nobody with a Kobo has a late enough version. Sure will will work as KePup. But not everybody reads KePub.

[Turtle91]

Originally Posted by JSWolf

On a Kobo that code will not work if reading the eBook as an ePub. It will work if you have the span. RMSDK will not render it unless you get to a late enough version and nobody with a Kobo has a late enough version. Sure will will work as KePup. But not everybody reads KePub.

I don't have a Kobo to test on. But that doesn't really matter - just refer to my original statement that it is ok to use those techniques under certain circumstances and to test on your target device and provide fall-back coding if there is a possibility it won't work...


Sheesh - I feel like a broken record sometimes...

...and there I go dating myself.

A record is a ...nvm just look it up here:

[JSWolf]

Originally Posted by Turtle91

I don't have a Kobo to test on. But that doesn't really matter - just refer to my original statement that it is ok to use those techniques under certain circumstances and to test on your target device and provide fall-back coding if there is a possibility it won't work...


Sheesh - I feel like a broken record sometimes...

...and there I go dating myself.

A record is a ...nvm just look it up here:

If you are using the code for yourself and you know it will work, then it's OK to use. If you are selling the eBook then the fallback code should be used.

[Turtle91]

Originally Posted by JSWolf

If you are using the code for yourself and you know it will work, then it's OK to use. If you are selling the eBook then the fallback code should be used.

Duh. You can still use it for books you want to sell....Why do you think there are such things as media-queries???

Just remember, fall-back code is for use when the primary code doesn't work...it's a fall-back position. Put the code you want to use in there...then, if there is a chance it won't work, the fall-back code is the safety net.

[paperwhite13]

Originally Posted by Turtle91

<hr/> is the recommended method. I can only blame the programmers for showing both a line and the dinkus (didn't know it was called that!! ). Either the device/app programmers for not making their device function properly, or the book coder for not putting the proper css on their stylesheet.

Here is the method I use and I haven't seen it display both on my readers.

Thank you, you’re very kind to include the sample and the explanation, that’s exactly what I was looking for. Didn’t know it was possible to do that with <hr>, I guess I'm still stuck in the early 90s when it comes to HTML

I changed the p classes tags to <p>,<h1>-<h3>, it’s much cleaner now There is one thing I was wondering about - new chapter pages, which are styled like this:

1.
Chapter Title

2.
Chapter Title

Saying I want to keep the number and the dot, which are styled differently (in terms of size, margins and font type) than the Chapter Title, how should that be tagged semantically? Should it also be an <h1 class="chapter-number"> with different properties? Before that, I thought about making it <h4>

Originally Posted by JSWolf

I hope you didnt make the footnotes some dinky little 1 tiny character to have to try to find where to press on the screen. That is really bad form.

Do not forget to have an NCX ToC.

Don’t worry, on the contrary, they’re rather large I may be new to making ebooks, but for the past 15 years or so, 90% of the books I’ve read, both fiction and non-fiction, were ebooks, so I've bumped into various issues, small footnote references being one of them. [#] would be my preferred way as well, but the publisher has the final say so that’s that.

I don’t see how one could forget about the toc.ncx, but I guess it’s happened since you mention it

I’m in Eastern Europe and this books are mainly produced for the local market -- online ebooks stores, Scribd-like "ebook streaming" services with rather primitive ereader apps; they may end up on Google Play Books or even Amazon, but that’s not their main destination. In any case, I will try to tackle accessibility, but I'll just run them through DAISY Consortium’s Ace and fix each issue as it comes up, hopefully I’ll learn something new in the process. I was under a deadline to produce these epubs, and the publisher has seen them, but they’re not to be actually published yet, so I still have some time to tinker with them.

Thank you!

[nabsltd]

Originally Posted by JSWolf

Use a margin instead of a line height.

Margins only apply to block elements. You can't change the distance between lines of a single block using a margin.

And, accessibility says that you should not split what is logically a single block into multiple blocks. So, sometimes you have to adjust line-height for that block.

Maybe it works on your Scribe, but I know for sure that older Kindles would not work with a line height of 1.

That's because using line-height: 1; means "use the default line height for this inline element when computing the line height of the entire line". The correct line height to use is (1 / font-size). So, if the initial cap is 3em, then use a line-height of 0.33. For inline elements that use the same or smaller font size as the base text (like a superscript), line-height: 1; will work.

That's because the section break space was a margin and not padding. Padding works as the space does not disappear.

Padding has a different meaning in CSS than a margin. Margins separate two block elements, while padding separates the content of a block from its border. Just like you should not use <p>&nbsp;</p> to create a blank space between two paragraphs, you also should not use padding to change the amount of space between two blocks.

Does this appy to KF8 or just KFX?

For the firmware I have (fairly recent, as it's a Scribe), both. It might just be a Scribe thing.

I'm not meaning font size. I've seen many cases where the margin uses % and that changes based on the screen. So using em will be consistent regardless of the screen.

No, em for margin will vary based on the font size the user chooses in the UI for the reader. This will quickly get out of hand for larger font sizes, and leave a much less noticeable margin for small font sizes. It really gets bad with headings, even with a font size as small as 2em. If the margin is 4em (not unusual), and the chosen base font size is 2x the default, you end up with a margin that is 8x the height of a normal line., with the heading taking up 4x a normal line. That's 12 normal lines, which is half the screen on a 6" device. Using a margin of 15% would mean the start of the text would be the same as using em with a normal font size, but only 31% down the screen with the doubled font size.

Percent will always leave the same relative space on the screen, so that 10% will always be 1/10th of the height/width of the screen. This is how physical books have always done it...margins on paperbacks are smaller in absolute width than on a hardback, but are almost exactly the same percentage of the page.

[nabsltd]

Originally Posted by paperwhite13

I changed the p classes tags to <p>,<h1>-<h3>, it’s much cleaner now There is one thing I was wondering about - new chapter pages, which are styled like this:

1.
Chapter Title

2.
Chapter Title

In general, the code would be something like the following, but with the styles in the stylesheet file instead of inline:

<style>
.chapter-number {
  font-size: 2em;
  font-weight: bold;
  text-align: center;
}
.chapter-name {
  font-size: 1.2em;
  text-align: center;
}
</style>

<h1 class="chapter-number" title="1. The First Chapter">1.</h1>
<p class="chapter-name">The First Chapter</p>

This allows the following:

1. Styling the two lines differently.
2. Automatically generating a table of contents by looking at h1 elements.
3. Using p is more accurate than h1 or h2.

Some people will complain about my last point, but using either h1 or h2 is wrong because headers can be thought of as an outline as far as accessability is concerned. The chapter name is not really the same level as the number...it's more like content. But, it's definitely not at a lower level, which h2 would imply.

I've also seen multi-line chapter headings done another way, but I don't like it as much:

<style>
.chapter {
  text-align: center;
}
.chapter-number {
  font-size: 2em;
  font-weight: bold;
}
.chapter-name {
  font-size: 1.2em;
}
</style>

<h1 class="chapter" title="1. The First Chapter"><span class="chapter-number">1.</span><br />
<span class="chapter-name">The First Chapter</span></h1>

You still have to include the title attribute to generate the table of contents without any strange formatting, and you would have to use line-height in the .chapter selector if you wanted to change the distance between the two lines. The first way, you can just use margins.

[JSWolf]

Originally Posted by nabsltd

Margins only apply to block elements. You can't change the distance between lines of a single block using a margin.

In your example of chapter titles.

HTML

<h2>Chapter</h2>
<h2 class="ch">One</h2>

CSS

h2 {
  text-align: center;
  text-indent: 0;
  margin-top: 0.8em;
  margin-bottom: 0;
}
.ch {
  text-align: center;
  text-indent: 0;
  margin-top: 0.2em;
  margin-bottom: 0.8em;
}

And, accessibility says that you should not split what is logically a single block into multiple blocks. So, sometimes you have to adjust line-height for that block.

What's the difference in terms of accessibility?

[quote]That's because using line-height: 1; means "use the default line height for this inline element when computing the line height of the entire line". The correct line height to use is (1 / font-size). So, if the initial cap is 3em, then use a line-height of 0.33. For inline elements that use the same or smaller font size as the base text (like a superscript), line-height: 1; will work.[/quote

For a large first letter, a line height of 0 works. No need to have to figure anything out. This works for ePub. But on a Kindle, you cannot use a line height as small as you are saying as it won't work. That's the problem.

Padding has a different meaning in CSS than a margin. Margins separate two block elements, while padding separates the content of a block from its border. Just like you should not use <p>&nbsp;</p> to create a blank space between two paragraphs, you also should not use padding to change the amount of space between two blocks.

Padding works if you insist on having blank space for a section break. Margins can get swallowed. There's no visual difference except if the padding falls at the bottom/top of the screen. If it does, then you do see the space.

For the firmware I have (fairly recent, as it's a Scribe), both. It might just be a Scribe thing.

Maybe. But for most Kindles a line height small enough to fix a large first letter won't work. It will be ignored.

No, em for margin will vary based on the font size the user chooses in the UI for the reader. This will quickly get out of hand for larger font sizes, and leave a much less noticeable margin for small font sizes. It really gets bad with headings, even with a font size as small as 2em. If the margin is 4em (not unusual), and the chosen base font size is 2x the default, you end up with a margin that is 8x the height of a normal line., with the heading taking up 4x a normal line. That's 12 normal lines, which is half the screen on a 6" device. Using a margin of 15% would mean the start of the text would be the same as using em with a normal font size, but only 31% down the screen with the doubled font size.

The thing with em is that I have my Libra 2 and you can have your scribe and the indents will be exactly the same at the same font size. With %, we'd have different indents. I've seen many Kindle eBooks using a 7% indent. That's too large. I like a 1.2em indent. But if you do want a slightly larger indent, I think 1.5em would do.

Percent will always leave the same relative space on the screen, so that 10% will always be 1/10th of the height/width of the screen. This is how physical books have always done it...margins on paperbacks are smaller in absolute width than on a hardback, but are almost exactly the same percentage of the page.

Yes, it will be relative. But not the same. The one thing I don't mind (other then for images) is the 40% line I use for section breaks. I don't mind if it's a different length on different screens.

[Turtle91]

Originally Posted by paperwhite13

There is one thing I was wondering about - new chapter pages, which are styled like this:

1.
Chapter Title

2.
Chapter Title

Saying I want to keep the number and the dot, which are styled differently (in terms of size, margins and font type) than the Chapter Title, how should that be tagged semantically? Should it also be an <h1 class="chapter-number"> with different properties? Before that, I thought about making it <h4>

I agree with much of nabsltd’s reasoning and answer, although I use a slightly different technique. I’ll put the basics here and provide a better example when I get home on my computer.

CSS:
h3 {yadda yadda}
h3 span {display:block; yadda yadda}

HTML:
<h3>1. <span>Chapter One Title</span></h3>
<h3>2. <span>Chapter Two Title</span></h3>
<h3>3. <span>Chapter Three Title</span></h3>

That keeps everything simple, clean, and semantically correct. It also lets automated table of contents generators do their thing because they ignore the <span>. You can also easily format any manner of heading, including the number and Title separately, using css. You can even include images in the header, if you wish, without cluttering up the header html.

There is no need to use a class in the heading because the css can positively identify each part without it.

I used an <h3> here because that is generally how my book levels work out, you could use any <h>:

h1 - cover
  h2 - front matter
    h3 - chapters
  h2 - back matter
h1 - back cover if there is one

[paperwhite13]

Thank you all for your replies! I understand your reasoning, especially if the TOC gets generated at the end, but keeping in mind my case -- I already have the TOC generated from InDesign, what would be wrong about using this? Wouldn’t it be semantically correct? I though I was just getting the hang of this

h1 {
	font-family:"Font1", sans-serif;
	font-size:2em;
	font-style:normal;
	font-weight:normal;
	border-width:0;
	margin-bottom:5%;
	margin-left:0;
	margin-right:0;
	margin-top:10%;
	text-align:center;
	text-indent:0;
	padding:0;
}
h1.chapter-no {
	font-family:"Font2", serif;
	font-size:1em;
	margin-bottom:0;
	margin-top:5%;
}
------------------
<h1 class="chapter-no">1.</h1>
<h1 id="_idParaDest-3"><a id="_idTextAnchor005"></a>>Chapter Title</h1>

[Karellen]

Not sure if you noticed, but you have one too many > in this line...

PHP Code:

<h1 id="_idParaDest-3"><a id="_idTextAnchor005"></a>>Chapter Title</h1> 


[paperwhite13]

Originally Posted by Karellen

Not sure if you noticed, but you have one too many > in this line...

PHP Code:

<h1 id="_idParaDest-3"><a id="_idTextAnchor005"></a>>Chapter Title</h1> 


Sorry, it’s not copied straight out of the epub, must've happened when I copied back the id’s after initially cutting them, for simplicity’s sake.

[Turtle91]

Originally Posted by paperwhite13

Thank you all for your replies! I understand your reasoning, especially if the TOC gets generated at the end, but keeping in mind my case -- I already have the TOC generated from InDesign, what would be wrong about using this? Wouldn’t it be semantically correct? I though I was just getting the hang of this

h1 {
	font-family:"Font1", sans-serif;
	font-size:2em;
	font-style:normal;
	font-weight:normal;
	border-width:0;
	margin-bottom:5%;
	margin-left:0;
	margin-right:0;
	margin-top:10%;
	text-align:center;
	text-indent:0;
	padding:0;
}
h1.chapter-no {
	font-family:"Font2", serif;
	font-size:1em;
	margin-bottom:0;
	margin-top:5%;
}
------------------
<h1 class="chapter-no">1.</h1>
<h1 id="_idParaDest-3"><a id="_idTextAnchor005"></a>>Chapter Title</h1>

Not all devices/apps use your ToC; some create their own ToC dynamically based on your headings.

In your case it would see two <h1>s in a row.

Depending on your target market you may not see any problem at all…. Or it could look kinda ugly.

[Karellen]

Originally Posted by paperwhite13

There is one thing I was wondering about - new chapter pages, which are styled like this:

1.
Chapter Title

2.
Chapter Title

Saying I want to keep the number and the dot, which are styled differently (in terms of size, margins and font type) than the Chapter Title, how should that be tagged semantically? Should it also be an <h1 class="chapter-number"> with different properties? Before that, I thought about making it <h4>

I also use the method mentioned by others in the previous few posts...

PHP Code:

  <h3>Chapter 1</h3>
  <p class="chapterh3">Divinity Avenue, Cambridge<br/>18 October, 1:00 p.m.</p> 


Which is then styled in the css as...

PHP Code:

h3 {
  display: block;
  font-size: 1.3em;
  font-weight: bold;
  font-style: normal;
  font-family: "Futura Std Medium", sans-serif;
  margin-top: 2em;
  margin-bottom: 0;
  text-indent: 0;
  text-align: left;
  /*  text-transform: uppercase;
  text-decoration: underline;*/
}
.chapterh3 {
  display: block;
  font-size: 1.2em;
  font-weight: bold;
  font-style: normal;
  font-family: "Futura Std Medium", sans-serif;
  margin-top: 1.5em;
  margin-bottom: 0;
  margin-right: 0;
  text-align: left;
  text-indent: 0;
  /*text-transform: uppercase;*/
  /*text-decoration: underline;*/
} 


Which then looks like the below image (for the current book I am reading)

Sometimes I will use the title tag to incorporate the chapter name with the chapter number in the TOC, but I didn't think it was necessary in this case, plus it would be too long for the TOC and make it wrap.

And the styling is easy to change with each book.
(note the enlarged first letter )

[paperwhite13]

Originally Posted by Turtle91

Not all devices/apps use your ToC; some create their own ToC dynamically based on your headings.

In your case it would see two <h1>s in a row.

Depending on your target market you may not see any problem at all…. Or it could look kinda ugly.

Oh, I see now. So they completely ignore the toc.ncx/toc.xhtml files? Are there many apps/devices that do that? I'm amazed they exist, given the emphasis on those files in the structure of an epub.

But other than that, would it be semantically correct to tag them as I did previously?