InDesign epub code cleanup

[paperwhite13]

Hello, I’m a fairly experienced typesetter working in InDesign and I've recently been asked to begin producing epubs. Is there a guide somewhere about cleaning up InDesign code? For instance, I’ve seen people saying nested divs are bad, but I don’t exactly know why and what I should do about it. I got a couple of more questions, but I’ll wait to see if there isn’t such a guide first that already answers them. Thank you!

[Turtle91]

Here is the Adobe help page for exporting to ePub.

As for a guide on how to cleanup what it produces… I’m not aware of one other than the various examples people use here. I’d search the threads for any specific question and then ask if you can’t find it. There are some online tools that claim to do the job automagically… beware, here there be dragons… some may work fine, others could leave you with just as big of a mess as you had to begin with. Also, be aware that you lose all control of your document whenever you upload it to the web…who knows what gets done with it?? That may be an issue if you are working with copyrighted material.

In general, you want to use correct semantic markup and keep it as simple as possible.
- Use a paragraph, <p>…</p>, to denote a paragraph… not a <div>.
- Use a header, <h1-6>…</h1-6>, to denote headers… not a paragraph or div.
- Do NOT use a header <h> just to make a section bold or centered.
- Do NOT use a class to denote the style of a standard paragraph… that should be done in the stylesheet. Eg. Use <p>, not <p class="normalpara">
- Use <em> or <i> to denote emphasized or italic text (there IS a difference) not <span class="italic">; same with <strong> and <b>.

You can use find/replace to cleanup most of that fairly easily. For example:
Find: <div class="para">(.*?)</div>
Replace: <p>\1</p>

There are plenty of techniques people use. I imagine you will get lots of (differing?) advice here. Just try and differentiate when someone is giving a styling preference vs. when they are giving a best practice.

Keeping the styles simple, and the html clean, makes the book much more likely to display properly in the widest number of devices/apps.

[Turtle91]

To specifically address the nested <div>s question:

There is nothing technically wrong with using nested <div>s. The book will pass inspection and display properly.

The issue is using tags that are not semantically correct. Some parsers rely on the correct tags to work - the parser can't tell the difference between <div> and <div class="header">... For example, some accessibility software wouldn't be able to do it's job properly if it can't tell the difference between a header and a div.

When editing your code, especially if you plan on doing a lot of it, it makes it much easier if you don't have to mentally parse what the heck is going on. With simple html you can just see the blond, brunette, red-head.

Spoiler:

Using CSS, both of the options below can display identically, but which would you rather see (and have the renderer crunch through):

<div class="blockquote">
  <div style="margin:0.86% 0.00% 0.00%; text-indent:1.7em; line-height:131%;
    font-size:1.0rem"> <span style=" font-size:1.0rem">Roses are red,</span></p>
  <div style="margin:0.86% 0.00% 0.00%; text-indent:1.7em; line-height:131%;
    font-size:1.0rem"> <span style=" font-size:1.0rem">Violets are blue,</span></p>
  <div style="margin:0.86% 0.00% 0.00%; text-indent:1.7em; line-height:131%;
    font-size:1.0rem"> <span style=" font-size:1.0rem">This HTML
    <span class="italic">sucks</span>,</span></p>
  <div style="margin:0.86% 0.00% 0.00%; text-indent:1.7em; line-height:131%;
    font-size:1.0rem"> <span style=" font-size:1.0rem">So…what can you do?</span></p>
</div>

-OR-

<div class="poem">
  <p>Roses are red,</p>
  <p>Violets are blue,</p>
  <p>This HTML <em>sucks</em>,</p>
  <p>So…what can you do?</p>
</div>

In this case I used <em> so that a TTS device would actually emphasize the word, rather than using <i> which would simply slant the letters slightly.

[Turtle91]

Sorry...I had to maker another post so that I could get to my 3000 posts!! It was really annoying me saying 2999...

[JSWolf]

Originally Posted by paperwhite13

Hello, I’m a fairly experienced typesetter working in InDesign and I've recently been asked to begin producing epubs. Is there a guide somewhere about cleaning up InDesign code? For instance, I’ve seen people saying nested divs are bad, but I don’t exactly know why and what I should do about it. I got a couple of more questions, but I’ll wait to see if there isn’t such a guide first that already answers them. Thank you!

In terms of formatting, an eBook is not a pBook (paper book) so don't do things you would for a pBook. For example, don't make the chapter headers too large. Don't have any overall left/right margins as the software will allow us to set left/right margins. Don't use any line height as the software or fonts will allow us to set the line height. Don't use drop-caps or a large first letter as these do not work in too many cases. When you have a section break, do not use blank space. Put something in the space to mark the section break. Keep the main font size at the default size. Also, when you have offset text, use a <nblockquote> and not a <div> and doi not make offset text a smaller font size. Do not use embedded fonts. Where you want a sans-seif font, use font-family: sans-serif; in the CSS. Use a proper cover image and not a generic cover image. DO not put anything in the copyright that's related to pBooks such as the statement about the book not having a cover. Use high-resolution graphics of at least 1600 lines and this include the cover and the titlepage images.

That should be enough for now.

[Turtle91]

Originally Posted by JSWolf

In terms of formatting, an eBook is not a pBook (paper book) so don't do things you would for a pBook. For example, don't make the chapter headers too large. Don't have any overall left/right margins as the software will allow us to set left/right margins. Don't use any line height as the software or fonts will allow us to set the line height. Don't use drop-caps or a large first letter as these do not work in too many cases. When you have a section break, do not use blank space. Put something in the space to mark the section break. Keep the main font size at the default size. Also, when you have offset text, use a <nblockquote> and not a <div> and doi not make offset text a smaller font size. Do not use embedded fonts. Where you want a sans-seif font, use font-family: sans-serif; in the CSS. Use a proper cover image and not a generic cover image. DO not put anything in the copyright that's related to pBooks such as the statement about the book not having a cover. Use high-resolution graphics of at least 1600 lines and this include the cover and the titlepage images.

That should be enough for now.

This is what I meant by differentiating between someone's opinion and best practice.

Legend
red = opinion
blue = ok to do under certain circumstances
green = best practice

- chapter header size can be whatever you want to express the style you are trying to achieve...just remember that a lot of people read on small screen sizes (phones) and you may have an unwanted display if your chapter header takes up the whole screen...or worse, only has on line of textr at the bottom.

- in general, don't set left/right margines and/or line-height for the entire book...it is certainly ok to use them for small sections of text.

- you can certainly use a large first letter/dropcap if that is what you need stylistically for that book. Just make sure you test on your target devices/apps to make sure they support it, or, better yet, have fall-back coding (media-queries) to cover the devices that don't look so good.

- I mostly agree with having some kind of fleuron as a section break rather than blank space. With a reflowable ePub you just don't know where the space will appear. If it's at the bottom, or top, of the screen the reader may not know that a section break has occured without a fleuron. A fixed format ePub doesn't have that concern.

- use a <blockquote> to surround a block-quote (semantically correct). A <div> is used for a generic section of text that does not have a more semantically correct tag to use.

- you certainly can make offset text smaller, especially if you are using a font that is larger by default. Again, remember some users use small screens to read, so don't go crazy with the change in font size.

- you most certainly CAN use embedded fonts, but, again, realize some devices may not support it. Test for your target market and provide fall-back coding if there is a chance it could be read on devices that don't support embedded fonts.

- I concur about the copyright page, but that is more of an annoyance than anything...it's not as if anyone actually READS the copyright page The funniest thing I see on the copyright page is the Printer's Key.....
10 9 8 7 6 5 4 3 2 1


Cheers!

[Karellen]

Originally Posted by Turtle91

The funniest thing I see on the copyright page is the Printer's Key.....
10 9 8 7 6 5 4 3 2 1

Nice clear explanations in your second post. I'm definitely in the "Keep the tags simple" camp and tend to default to naked tags, though I know some members believe that is a throwback to the 90's? (I don't really know what that means so it'd be nice if someone explains why that is. I **think** it was DNSB that said it, could be wrong...)

That Printer's key, I thought that was the Release number or print run. So if the "1" is visible, then the pbook is the first release / edition / print run; "2" is the second print run etc. Is that not the case?

And I disagree with the enlarged first letter comment. I've never seen it as a problem. The enlarged first letter is the start of a chapter or scene bread, so there is nothing above it to interfere with.

[paperwhite13]

Thank you everyone for the very helpful comments!

Adding to my story

I’ve already exported two epubs and due to some deadline concerns, I’ve skipped the "Map text styles to HTML and CSS tags" step entirely, so it’s all a bunch of <p class="...">.

<div>s only actually come up on two pages as simple class="Basic-Text-Frame" and as nested divs where footnotes/endnotes appear

<div class="_idFootnotes">
<div id="footnote-154" class="_idFootnote" epub:type="footnote">

There are no <div class="para">s, fortunately

I could go back to InDesign and map the text styles properly, but I've made some edits in the epub directly, so I’d rather make the changes here, and I guess that’s what I was asking in the first place -- if it’s possible to change the relevant p classes to h1, h2 etc.

I am fairly competent with regex, that’s one of the boons of using InDesign for so long

I am forced to use embedded (unencrypted) fonts, that’s my publisher’s request. A couple of readers show the document very nicely, fonts and drop caps included -- Calibre Viewer, Lithium on Android--, while others don’t -- FB Reader, KO Reader on my Kindle, SumatraPDF (the latter doesn’t show *any* formatting at all, which is a little worrying)

I have to say I am less concerned with accessibility at the moment (there are almost no rules or laws to support it in my region and ebook market is shrinking anyway here), and more with wider compatibility, although I understand they go hand in hand. I don’t want to pick up bad habits, of course, but if using <em> everywhere instead of <i> or <span class="italic"> gets me wider compatibility, that’s what I'm after at the moment, even if in some places italic would be semantically correct instead of emphasis.

I usually use a dinkus (* * *) for a section break, what would the semantically correct way to tag this? The little accessibility reading I've done suggests mapping this to <hr>, which would explain why many ebooks I've read have both a horizontal line, and a fleuron -- which I find a little annoying, strictly from a presentation point

Thank you everyone again!

[Turtle91]

Originally Posted by Karellen

Nice clear explanations in your second post. I'm definitely in the "Keep the tags simple" camp and tend to default to naked tags, though I know some members believe that is a throwback to the 90's? (I don't really know what that means so it'd be nice if someone explains why that is. I **think** it was DNSB that said it, could be wrong...)

I think that came around when the external css stylesheet made its debut in '96. The idea is that all styling goes on the stylesheet and then you only need to reference what style you need. "Naked tags", at the time, would be the 'old way' and therefore 'bad'.

As is normal when a new process gets started, zealots will push it HARD. So a naked tag <p> would be wrong, where a <p class="normal-paragraph"> would be more 'proper'. That is also the time when a lot of these software suites were created...like InDesign in '99... They put classes on everything!

As is also normal after a few years of getting used to a new process, fixes are made and a new balance point is found. Except the software had already been written, and it works, so why spend the money to change it?

A 'normal paragraph' is what makes up 98.7% of a chapter. Why have <p class="normal-paragraph"> when it is easier just to have that as a naked tag <p>?? When cleaning up a book's code, that is what I consider 'low hanging fruit', easy to fix, and makes a big improvement in readability.

Spoiler:

Which one is cleaner and easier to read/edit?

<p style="text-indent:1.2em; text-align:left; font-weight:normal; font-size:1em; ">This is a normal paragraph.</p>
<p style="text-indent:1.2em; text-align:left; font-weight:normal; font-size:1em; ">This is a normal paragraph.</p>
<p style="text-indent:1.2em; text-align:left; font-weight:normal; font-size:1em; font-style:italic; text-decoration:underline; color:red">This is a red, underlined, italic paragraph.</p>
<p style="text-indent:1.2em; text-align:left; font-weight:normal; font-size:1em; ">This is a normal paragraph.</p>
<p style="text-indent:1.2em; text-align:left; font-weight:normal; font-size:1em; ">This is a normal paragraph.</p>

-OR-

css:
p.normal-paragraph {text-indent:1.2em; text-align:left; font-weight:normal; font-size:1em;}
p.red {color:red}
p.underline {underline}
p.italic {italic}

html:
<p class="normal-paragraph">This is a normal paragraph.</p>
<p class="normal-paragraph">This is a normal paragraph.</p>
<p class="normal-paragraph red italic underline">This is a red, underlined, italic paragraph.</p>
<p class="normal-paragraph">This is a normal paragraph.</p>
<p class="normal-paragraph">This is a normal paragraph.</p>

-OR-

css:
p {text-indent:1.2em; text-align:left; font-weight:normal; font-size:1em;}
p.emphasized {font-style:italic; text-decoration:underline; color:red}

html:
<p>This is a normal paragraph.</p>
<p>This is a normal paragraph.</p>
<p class="emphasized">This is an emphasized paragraph.</p>
<p>This is a normal paragraph.</p>
<p>This is a normal paragraph.</p>

Originally Posted by Karellen

That Printer's key, I thought that was the Release number or print run. So if the "1" is visible, then the pbook is the first release / edition / print run; "2" is the second print run etc. Is that not the case?

You are correct, it is an edition, or printing run, etc. My understanding was that, originally, the typesetters kept the plates(??) for a book and when a 2nd printing was needed they would simply chisel off the number of the last run, leaving: 10 9 8 7 6 5 4 3 2 _

That is obviously not needed in today's eBook world where you can simply change the "edition" or "version" by updating the copyright page with something as simple as "V2.5" or "Second Edition".

[Turtle91]

Originally Posted by paperwhite13

...

I could go back to InDesign and map the text styles properly, but I've made some edits in the epub directly, so I’d rather make the changes here, and I guess that’s what I was asking in the first place -- if it’s possible to change the relevant p classes to h1, h2 etc.

Yes, it is absolutely possible...and highly encouraged! Just remember to add the appropriate css for the h1, h2 to your stylesheet. This is where strong reg-fu comes in handy!

Originally Posted by paperwhite13

I have to say I am less concerned with accessibility at the moment (there are almost no rules or laws to support it in my region and ebook market is shrinking anyway here), and more with wider compatibility, although I understand they go hand in hand. I don’t want to pick up bad habits, of course, but if using <em> everywhere instead of <i> or <span class="italic"> gets me wider compatibility, that’s what I'm after at the moment, even if in some places italic would be semantically correct instead of emphasis.

Understandable. I'm not sure what region you are in, but there are some regions that have already passed laws, like Europe, that mandate accessibility. If your book is going to one of the big distributers (Amazon, Kobo, etc) then they will probably require it. Luckily some enterprising programmers around here have created a plugin to automagically fix a lot of those accessibility concerns. If you use Sigil to edit your ePub then here is the link to that plugin.

Originally Posted by paperwhite13

I usually use a dinkus (* * *) for a section break, what would the semantically correct way to tag this? The little accessibility reading I've done suggests mapping this to <hr>, which would explain why many ebooks I've read have both a horizontal line, and a fleuron -- which I find a little annoying, strictly from a presentation point

<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.

Spoiler:

Adjust the image, margin, height, and letter spacing as desired
CSS:
hr {border:none; margin:1em auto; text-align:center; letter-spacing:1em}

/* using an image fleuron*/
hr.ChDiv1 {
  height:2em;
  background: transparent url("../Images/img_ChDiv.svg") no-repeat center;
  background-size: auto 100%;
  overflow: hidden;
  page-break-inside: avoid;
  break-inside: avoid;
}
/* using symbols*/
hr.ChDiv2:after {content:'◆◆◆◆◆'}

hr.ChDiv3:after {content:'***'}

hr.ChDiv4:after {content:'♥♥♥'}


HTML:
  <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p>

  <hr class="ChDiv1"/>

  <p>Suspendisse fermentum nec mauris sit amet laoreet.</p>

  <hr class="ChDiv2"/>

  <p>Phasellus nec lorem dignissim, sodales lorem ac, luctus nulla.</p>

  <hr class="ChDiv3"/>

  <p>Donec viverra ut sem at ornare. Fusce neque augue, dignissim.</p>

  <hr class="ChDiv4"/>

  <p>Sed vehicula massa id vulputate mollis.</p>

Edit:
The slight offset from center you see with the fleuron is because, in this example, I left the letter-spacing for all <hr>s. If you use a fleuron image, just remove the letter-spacing and the image will be perfectly centered.

[JSWolf]

Originally Posted by Turtle91

This is what I meant by differentiating between someone's opinion and best practice.

Legend
red = opinion
blue = ok to do under certain circumstances
green = best practice

- chapter header size can be whatever you want to express the style you are trying to achieve...just remember that a lot of people read on small screen sizes (phones) and you may have an unwanted display if your chapter header takes up the whole screen...or worse, only has on line of textr at the bottom.

- in general, don't set left/right margines and/or line-height for the entire book...it is certainly ok to use them for small sections of text.

- you can certainly use a large first letter/dropcap if that is what you need stylistically for that book. Just make sure you test on your target devices/apps to make sure they support it, or, better yet, have fall-back coding (media-queries) to cover the devices that don't look so good.

- I mostly agree with having some kind of fleuron as a section break rather than blank space. With a reflowable ePub you just don't know where the space will appear. If it's at the bottom, or top, of the screen the reader may not know that a section break has occurred without a fleuron. A fixed format ePub doesn't have that concern.

- use a <blockquote> to surround a block-quote (semantically correct). A <div> is used for a generic section of text that does not have a more semantically correct tag to use.

- you certainly can make offset text smaller, especially if you are using a font that is larger by default. Again, remember some users use small screens to read, so don't go crazy with the change in font size.

- you most certainly CAN use embedded fonts, but, again, realize some devices may not support it. Test for your target market and provide fall-back coding if there is a chance it could be read on devices that don't support embedded fonts.

- I concur about the copyright page, but that is more of an annoyance than anything...it's not as if anyone actually READS the copyright page The funniest thing I see on the copyright page is the Printer's Key.....
10 9 8 7 6 5 4 3 2 1


Cheers!

I've given no opinion. Its all best practices. Remember, an eBook is different to a pBook. So what works for a pBook does not always work for an eBook. For example, having most of the screen taken up with a simple chapter heading is bad practice. A lot of people rea don their phone and the screen being smallish, you can lose most of that to an overly big chapter heading.

I mentioned the overall L/R margins. Of course it's OK to have L/R margins for offset text and other specific things.

As for line-height, there's no need for it as you're not going to be using a dropcap of large first letter. A large first letter does not work properly on a Kindle because you cannot set the line-height to be smaller. So the first line of the chapter and/or section has a different space to other lines. And since Kindles are basically fixed with a line-height, why bother? With a Kobo, I can change the line-height to what I want. Why cripple that?

Dropcap or large first letter don't really work well. Change the font and/or change the line-height and it's a fail. Plus, when they fail, they look awful.

<blockquote> just works. If you like the default, you don't need extra CSS. IT's better then a <div> about the offset text.

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. You need to use padding to have the space not get swallowed. Also, in a pBook you get *** when the space hits the top/bottom of the page. I've seen this translated over to the eBook. So you get *** in the middle of the page and you can still have the space at the top.bottom and again, it's swallowed-up. That's why I do prefer something in that space. But what I really dislike is when there is a graphic used and there is a seperate file for every occurrence of that graphic. I like my idea of a 2px 60% wide black line. I use an <hr/> with the appropriate CSS for this. Looks good and works well. Plus, I don't need any graphics for it.

Most embedded fonts do not work well. A common font is Adobe Garamond Pro and it's a disaster on an eInk screen as it's way too light. Also, on a Kindle, most people won't see your embedded fonts as they don't switch to Publisher Font. There are some cases where an embedded font works, but that will only really work with ePub.

Why do you want pBook specific stuff in the eBook? For example, a note saying that if you got the book without a cover is illegal is senseless.

What I do wish we had on all eBooks is the version number so if it gets updated and we download it again, we'll know it's a newer version.

One thing I did leave out. Do not use % where em will work better.

I do think following my instructions will give a rather good looking eBook.

[JSWolf]

Originally Posted by Karellen

Nice clear explanations in your second post. I'm definitely in the "Keep the tags simple" camp and tend to default to naked tags, though I know some members believe that is a throwback to the 90's? (I don't really know what that means so it'd be nice if someone explains why that is. I **think** it was DNSB that said it, could be wrong...)

That Printer's key, I thought that was the Release number or print run. So if the "1" is visible, then the pbook is the first release / edition / print run; "2" is the second print run etc. Is that not the case?

And I disagree with the enlarged first letter comment. I've never seen it as a problem. The enlarged first letter is the start of a chapter or scene bread, so there is nothing above it to interfere with.

In most cases, the large first letter with make that line have a different line-height from the rest of the paragraph on a Kindle. There's no way to fix that even if you edit the eBook's code.

[JSWolf]

Originally Posted by Turtle91

I think that came around when the external css stylesheet made its debut in '96. The idea is that all styling goes on the stylesheet and then you only need to reference what style you need. "Naked tags", at the time, would be the 'old way' and therefore 'bad'.

As is normal when a new process gets started, zealots will push it HARD. So a naked tag <p> would be wrong, where a <p class="normal-paragraph"> would be more 'proper'. That is also the time when a lot of these software suites were created...like InDesign in '99... They put classes on everything!

As is also normal after a few years of getting used to a new process, fixes are made and a new balance point is found. Except the software had already been written, and it works, so why spend the money to change it?

A 'normal paragraph' is what makes up 98.7% of a chapter. Why have <p class="normal-paragraph"> when it is easier just to have that as a naked tag <p>?? When cleaning up a book's code, that is what I consider 'low hanging fruit', easy to fix, and makes a big improvement in readability.

Spoiler:

Which one is cleaner and easier to read/edit?

<p style="text-indent:1.2em; text-align:left; font-weight:normal; font-size:1em; ">This is a normal paragraph.</p>
<p style="text-indent:1.2em; text-align:left; font-weight:normal; font-size:1em; ">This is a normal paragraph.</p>
<p style="text-indent:1.2em; text-align:left; font-weight:normal; font-size:1em; font-style:italic; text-decoration:underline; color:red">This is a red, underlined, italic paragraph.</p>
<p style="text-indent:1.2em; text-align:left; font-weight:normal; font-size:1em; ">This is a normal paragraph.</p>
<p style="text-indent:1.2em; text-align:left; font-weight:normal; font-size:1em; ">This is a normal paragraph.</p>

-OR-

css:
p.normal-paragraph {text-indent:1.2em; text-align:left; font-weight:normal; font-size:1em;}
p.red {color:red}
p.underline {underline}
p.italic {italic}

html:
<p class="normal-paragraph">This is a normal paragraph.</p>
<p class="normal-paragraph">This is a normal paragraph.</p>
<p class="normal-paragraph red italic underline">This is a red, underlined, italic paragraph.</p>
<p class="normal-paragraph">This is a normal paragraph.</p>
<p class="normal-paragraph">This is a normal paragraph.</p>

-OR-

css:
p {text-indent:1.2em; text-align:left; font-weight:normal; font-size:1em;}
p.emphasized {font-style:italic; text-decoration:underline; color:red}

html:
<p>This is a normal paragraph.</p>
<p>This is a normal paragraph.</p>
<p class="emphasized">This is an emphasized paragraph.</p>
<p>This is a normal paragraph.</p>
<p>This is a normal paragraph.</p>

The third example is much easier to read. But one thing needs to be done to keep it simple The text-align: left, font-weight: normal, and font-size:: 1em all have to go. They are excess code.

[JSWolf]

Originally Posted by paperwhite13

Thank you everyone for the very helpful comments!

Adding to my story

I’ve already exported two epubs and due to some deadline concerns, I’ve skipped the "Map text styles to HTML and CSS tags" step entirely, so it’s all a bunch of <p class="...">.

<div>s only actually come up on two pages as simple class="Basic-Text-Frame" and as nested divs where footnotes/endnotes appear

<div class="_idFootnotes">
<div id="footnote-154" class="_idFootnote" epub:type="footnote">

There are no <div class="para">s, fortunately

I could go back to InDesign and map the text styles properly, but I've made some edits in the epub directly, so I’d rather make the changes here, and I guess that’s what I was asking in the first place -- if it’s possible to change the relevant p classes to h1, h2 etc.

I am fairly competent with regex, that’s one of the boons of using InDesign for so long

I am forced to use embedded (unencrypted) fonts, that’s my publisher’s request. A couple of readers show the document very nicely, fonts and drop caps included -- Calibre Viewer, Lithium on Android--, while others don’t -- FB Reader, KO Reader on my Kindle, SumatraPDF (the latter doesn’t show *any* formatting at all, which is a little worrying)

I have to say I am less concerned with accessibility at the moment (there are almost no rules or laws to support it in my region and ebook market is shrinking anyway here), and more with wider compatibility, although I understand they go hand in hand. I don’t want to pick up bad habits, of course, but if using <em> everywhere instead of <i> or <span class="italic"> gets me wider compatibility, that’s what I'm after at the moment, even if in some places italic would be semantically correct instead of emphasis.

I usually use a dinkus (* * *) for a section break, what would the semantically correct way to tag this? The little accessibility reading I've done suggests mapping this to <hr>, which would explain why many ebooks I've read have both a horizontal line, and a fleuron -- which I find a little annoying, strictly from a presentation point

Thank you everyone again!

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. One way to do it that works well is to make the tap zone the word and the footnote symbol. I like this... last word[*] That makes it a lot easier to tap. And you do not use any sort of subletting. As for the footnotes/endnotes, do the same thin in reverse and do not make them up against the margin. Use at least a 1.5em L/R margin.

<p class="somereallyuselessclass"> should be just <p>. Your Basic-Text-Frame should be changed for a <blockquote>. * * * for a section break looks like you don't have a clue how to do it so it looks good.

What embedded fonts are you using/ Most will not work well on an eInk Reader and on a Kindle will never be seen by most Kindle users who read your book. The drop cap has to go as it will not work in too many cases. I bet on my Kobo it will be a fail given the settings I like to read with.

As to the section break, you need to use <hr.transition> for accessibility. The following code works well.

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

And you do not need to go back to InDesign to fix any of this. You can do it in calibre and/or Sigil much easier.

Do not forget to have an NCX ToC.

[Turtle91]

Originally Posted by JSWolf

The third example is much easier to read. But one thing needs to be done to keep it simple The text-align: left, font-weight: normal, and font-size:: 1em all have to go. They are excess code.

Please re-read my post... especially the explanation points below. We agree on most things, you just tend to tell everyone to do it a certain way because that is how you like it on your device, not because it's wrong or because it can't be made to work.

The example I gave, that you quoted above, was an example of using inline styling vs. css classes. It was not meant to tell people to style things any particular way.
Having said that, text-align:left is perfectly fine under certain circumstances, like forcing a left-alignment for stylistic purposes. Setting default font weight and size is also perfectly acceptable...it sets a baseline from which you can change with specific classes. Are they necessary - maybe not, but are they wrong - no.