InDesign epub code cleanup

[Turtle91]

<h1-6> tags are set to determine the level of header:

h1
  h2
  h2
    h3
    h3
  h2
    h3
    h3
  h2
    h3
    h3
    h3
    h3

You can certainly style, and use the bare tags so that you have a baseline. Then when you need to define the class, you don't need to duplicate work. If you don't have any special circumstances you don't need to have a class.

Jon...this is an example...you can change it however you want. You DON'T need to tell anyone that you think it's ugly or wrong...

h1, h2, h3, h4, h5, h6 {text-align:center; text-indent:0; font-weight:bold; margin:1 auto}
h1 {font-size:1.5em}
h2 {font-size:1.3em}
h3 {font-size:1.2em}

h2.title {text-transform:uppercase}
h2.ack {text-decoration:underline}

[paperwhite13]

Originally Posted by nabsltd

By directly styling the h1, you have to "undo" the base formatting for the "special" chapters. You would then use something like h1.normalchapter and h1.specialchapter.

I guess this is something I still don’t understand. Why not use the bare (L.E.: styled) h1 for the normal chapter, and h1.specialchapter for the rest? Why is there a need for a h1.normalchapter?

Originally Posted by nabsltd

But, if you are going to do that, why bother restricting to h1? If you decide you need to change the level of headings down or up, then the stylesheet has to be changed to match. Without restricting to a single element and a class, instead only using a class, it's more flexible.

This is also something I don’t understand yet, sorry Especially the 'why bother restricting' part. Do you mean you could reuse the class for the other headings?

[Turtle91]

He said that was his own personal preference. That is OK. I’m assuming that he learned his techniques when it was heavily pushed to have classes for everything, but it’s not required.

Do what’s comfortable to you, and what passes epubcheck.

[DNSB]

Originally Posted by paperwhite13

I guess this is something I still don’t understand. Why not use the bare (L.E.: styled) h1 for the normal chapter, and h1.specialchapter for the rest? Why is there a need for a h1.normalchapter?

This a a matter of personal preference. I tend to prefer using classes for most items since it makes it easier when I go back to make changes to know what to change and keeps me from having to override other settings.

Originally Posted by paperwhite13

This is also something I don’t understand yet, sorry Especially the 'why bother restricting' part. Do you mean you could reuse the class for the other headings?

Yes, you can. Since I like headers centered, bold and with spacing above and below, I do have a h1...h6 class for that. I then add font size, styling, etc. in separate classes much as in @turtle91's example above. When I find myself with multiple classes removing bits from the base class, it's time to look at the base class.

One horrible example was an ebook I was looking at where the base paragraph class includes font-style: italic; and almost every paragraph style added font-style: normal;. It was a lot simpler to remove the italic styling and add it to the few paragraphs styles that did not have font-style: normal;.

Again, this is my personal preference. Most people have them though, unlike certain posters, they don't seem to regard them as if they had been brought down from the mountain top engraved on stone tablets.

I like to use h1 for volumes, h2 for parts inside a volume and h3 for chapters inside the parts which is just my personal preference. I find it makes it easy for me to create nested ToCs but there are other ways of reaching the same end.

If someone uses different preferences and the ebook still renders properly, more power to them. I'll look at their stylesheets and see if there is anything in them that I want to file the serial numbers off of and add them to my toolbox.

[Sarmat89]

It makes no sense to use <h#> tags for anything. They were intended for technical documentation, where there is a strict hierarchy of headers having the corresponding inline numeration, and which can be indexed to build the tables of contents.
Books, however, do not have a hierarchy of headings (what level is 'Epilogue', for example), their headers are not numbered (a separate element is used which combines the number with some descriptive text, they can have very long subheadings, which are grammatically connected to the heading itself. That means they cannot be put into ToC automatically, unless another extra element is added, the title attribute. It is better to represent headers as what they are, a set of paragraphs, without inapplicable abstractions.

[paperwhite13]

Originally Posted by Turtle91

He said that was his own personal preference. That is OK. I’m assuming that he learned his techniques when it was heavily pushed to have classes for everything, but it’s not required.

Do what’s comfortable to you, and what passes epubcheck.

Got it now, great, I thought I was doing something wrong.

[paperwhite13]

Originally Posted by DNSB

This a a matter of personal preference. I tend to prefer using classes for most items since it makes it easier when I go back to make changes to know what to change and keeps me from having to override other settings.



Yes, you can. Since I like headers centered, bold and with spacing above and below, I do have a h1...h6 class for that. I then add font size, styling, etc. in separate classes much as in @turtle91's example above. When I find myself with multiple classes removing bits from the base class, it's time to look at the base class.

One horrible example was an ebook I was looking at where the base paragraph class includes font-style: italic; and almost every paragraph style added font-style: normal;. It was a lot simpler to remove the italic styling and add it to the few paragraphs styles that did not have font-style: normal;.

Again, this is my personal preference. Most people have them though, unlike certain posters, they don't seem to regard them as if they had been brought down from the mountain top engraved on stone tablets.

I like to use h1 for volumes, h2 for parts inside a volume and h3 for chapters inside the parts which is just my personal preference. I find it makes it easy for me to create nested ToCs but there are other ways of reaching the same end.

If someone uses different preferences and the ebook still renders properly, more power to them. I'll look at their stylesheets and see if there is anything in them that I want to file the serial numbers off of and add them to my toolbox.

Thank you!

[paperwhite13]

Originally Posted by Sarmat89

It makes no sense to use <h#> tags for anything. They were intended for technical documentation, where there is a strict hierarchy of headers having the corresponding inline numeration, and which can be indexed to build the tables of contents.
Books, however, do not have a hierarchy of headings (what level is 'Epilogue', for example), their headers are not numbered (a separate element is used which combines the number with some descriptive text, they can have very long subheadings, which are grammatically connected to the heading itself. That means they cannot be put into ToC automatically, unless another extra element is added, the title attribute. It is better to represent headers as what they are, a set of paragraphs, without inapplicable abstractions.

Maybe, but DAISY Consortium does require the use of header tags for acccessiblity. And leaving aside that not all books are fiction books with an epilogue, one could say that an hierarchy can easily be approximated -- I would put Epilogue on the same level as a regular chapter.

[JSWolf]

Originally Posted by nabsltd

This causes problems if the letter has a descender. Using (1 / font-size) causes the renderer to deal with descenders correctly.

I've never had a problem with a line height of 0. But not matter which line height you use, it won't work on a Kindle. They get ignored. KFX even ignores the metadata in a font for the line height.

For eBooks that use the "small-caps for enough of the first line to fill a 6-inch screen, but look stupid on a Scribe because the intent is to affect the entire first line", I use the following all the time and it works perfectly on my Scribe:

.para-firstinchapter {
	text-align: justify;
}
.para-firstinchapter::first-line {
	font-variant: small-caps;
	font-size: 120%;
	line-height: 0.8;
}
.para-firstinchapter::first-letter {
	font-size: 200%;
	line-height: 0.5;
}

This is absolutely not true. You don't understand how line-height works in an inline element. It's not an absolute. It tells the renderer "use this when computing what this inline element does to the absolute line height of the entire line". You can't reduce the absolute line height of body text below 1.2 on a Kindle, but you can make sure that a character or two of a larger font does not contribute to the calculation to make it larger.

You can see in the attached screenshot that the Kindle renders the same space between each line, despite the large first character, and overall larger font size that my code uses. Note that the "H" in "He" is 13 pixels high, while the "E" in "English" on the next line is only 11 pixels. The whole first line uses a larger font, but the line spacing is 25 pixels (baseline to baseline). This is actually 2 pixels less than the line spacing in the rest of the page, likely due to the exact way Kindle determines the value.

It looks like the first line has less space then the rest second line. Is this KFX or KF8? Does it work on Kindles other then the Scribe or PW5? What does it look like without the line-height in CSS?

I don't need to see a blank space at the top of a page...it's a new page, and the paragraph isn't indented. That enough cue for me to know it's a section break.

a non-indented paragraph may not be enough to know it's not a continuation of the paragraph from the previous page. There needs to be a way to differentiate. So space or something in between such as (what I use) a 2px 40% wide line.

Again, you don't understand how this has been done for years. Physical books do use an first line indent based on em, so the indent is the same on a hardback or a paperback. That's one case where "em" is the right way to state a length. A margin change, on the other hand (like for a blockquote), is the same size relative to the page (i.e., smaller absolutely in a paperback), so it's better to use percent.

I understand fully. I also understand that % is wrong. With em, the indent is exactly the same no matter the screen size. That's what's correct. What's correct is to keep the indent the same no matter the screen size. Amazon uses a 7% indent and that's awful. If you find a % that;s the size I use now on a 7" screen, it's going to be too large on a 10.3" screen. In ALL cases % is no good on an indent and in most cases a % is no good for a margin.

[JSWolf]

Originally Posted by Turtle91

He said that was his own personal preference. That is OK. I’m assuming that he learned his techniques when it was heavily pushed to have classes for everything, but it’s not required.

Do what’s comfortable to you, and what passes epubcheck.

I do what makes less code bloat. And <h1 class="chapter"> for every chapter is code bloat when I just used <h1>.

[Quoth]

Originally Posted by JSWolf

I do what makes less code bloat. And <h1 class="chapter"> for every chapter is code bloat when I just used <h1>.

It's not really bloat. It's readable and because of zip tokenisation it may only add less than 16 bytes even if there are 1000s of chapters (e.g. a Bible).

However I do agree that up to a point KISS is a good principle. But I've had to maintain arcane 70s style C using compact muliple statements on one line and also C++ written as if the programmer was more at home with Modula-2 or Ada. I know which I prefer editing.

A technical document might use the same style for every h1 (and any h level will use a suitable style).

A novel might have h1, h2 or h3 for all the chapter 'titles', but due to limited levels on TOC and TOC layout might use the same level h for other headings with a different style.

On a separate issue:
Some novels don't have any chapters at all in the body, though there may be named scene breaks with a paragraph in a different style (Dune) or simply a first paragraph style. In such a case the source could have either a handmade TOC or <hx> with no text but a title attribute because a TOC/Navigation system is more needed in an ebook than a paper book.

[JSWolf]

Originally Posted by Quoth

It's not really bloat. It's readable and because of zip tokenisation it may only add less than 16 bytes even if there are 1000s of chapters (e.g. a Bible).

However I do agree that up to a point KISS is a good principle. But I've had to maintain arcane 70s style C using compact muliple statements on one line and also C++ written as if the programmer was more at home with Modula-2 or Ada. I know which I prefer editing.

A technical document might use the same style for every h1 (and any h level will use a suitable style).

A novel might have h1, h2 or h3 for all the chapter 'titles', but due to limited levels on TOC and TOC layout might use the same level h for other headings with a different style.

On a separate issue:
Some novels don't have any chapters at all in the body, though there may be named scene breaks with a paragraph in a different style (Dune) or simply a first paragraph style. In such a case the source could have either a handmade TOC or <hx> with no text but a title attribute because a TOC/Navigation system is more needed in an ebook than a paper book.

Discworld has section breaks but no chapters.

[paperwhite13]

Originally Posted by JSWolf

Discworld has section breaks but no chapters.

And the retail (probably old) epubs ToCs jump from "Begin Reading" to "About the Author", those section breaks aren’t navigable

[Quoth]

Originally Posted by JSWolf

Discworld has section breaks but no chapters.

Most Discworld novels. I meant to mention that.

[Quoth]

Originally Posted by paperwhite13

And the retail (probably old) epubs ToCs jump from "Begin Reading" to "About the Author", those section breaks aren’t navigable

I'd name them and make them work, if I had them. I have most of his books on paper and all of Discworld, so I don't have any on ebook. The recent Humble Bundle was only USA.