Quote:
Originally Posted by mingsphinx
Because of the heterogeneity of the eReader space, the final product which the reader experiences can be somewhat unpredictable; particularly if one uses CSS.
|
Moon+ is a
horrible reader, and if it overrides your book at every step + doesn't follow the EPUB standards, then that problem's on
them. (Not to mention, it completely ignores/mangles SVG, ignores negative indents for poetry, etc.)
If you want an Android reader that follows the EPUB standards (
plus free TTS), use PocketBook Reader or Gitden.
A lot of this was written about in last year's topic:
"Epub-problems in tablets".
Quote:
Originally Posted by mingsphinx
To be absolutely certain that the final product looks similar regardless of the device used to render it, creators of eBooks are left with only the most basic tools like <b>, <i> and <u>.
|
No. You can still design fantastic (and Accessible) ebooks that work across devices.
See this
ebookcraft 2019 talk, "Building Ebooks that Last".
She worked as an editor at Houghton Mifflin for many years, and explains why it's best to use proper markup + follow the standards.
Around 19 minutes in, she even shows a recipe book split from its CSS, and shows the differences between a mess (using <p class="heading1">), and a properly marked HTML document (using <h1>).
Quote:
Originally Posted by mingsphinx
Unlike the style sheets which some eReaders will disregard, all eReaders I have looked it seem to respect these basic tags.
|
Your job, as ebook-maker, is to follow the standards and do your best.
Yes, you may even need to code some fallbacks for common use-cases/edge-cases, for example:
but you can only go so far.
If the ebook works properly on Kobo/B&N/Apple/Amazon (all the mainstream stores/readers), you'll be fine.
If the reader
still insists on using a program that disregards/overrides everything (like Moon+)... then that's not on you.
Quote:
Originally Posted by mingsphinx
Thank you but I am not trying to hack anything using HTML.
[...]
This brings me to my interest in the <a> tag. All eReaders that can display color which I have looked at will display a link as blue and all eReaders will underline a link. This means that the creator of a book can, in a somewhat sneaky way, trick the eReader into displaying text color other than say white font on black. If it can be made to work, this is a way of grabbing back some control. (Emphasis added) |
Like I said, using the <a> in this way is a hack + completely non-standard (and would break Accessibility).
HTML tags ARE NOT meant "for looks", they're meant to mark PURPOSE (semantics):
- <h1> = a heading, not "bigger font + bold"
- <em> = emphasis, not "make this look italics"
- <a> = a link within/between documents, not "blue + underline"
- <blockquote> = a long quotation, not "let me get some margins on both sides".
- [...]
Most browsers display that way by default, but lots of non-visible information gets carried over as well. For example:
- <h1-6> Headings allow proper navigation.
- A Screen Reader can jump to next chapter/section.
- Don't hackishly do <p class="heading1">.
- <em> can be spoken differently via Text-to-Speech
- A Screen Reader can separately list all <a> in a document, then use that to more easily navigate.
- Don't clog it with things that aren't links.
Proper <table> + <th> + <td> markup allows:
Code:
Name | Eggs | Bread
____________________
Joe | 2 | 2
Smith| 1 | 0
to be read out loud by a Screen Reader as:
"Name: Joe, Eggs: 2, Bread: 2"
"Name: Smith, Eggs: 1, Bread: 0"
not:
"Name Eggs Bread. Joe, 2, 2. Smith, 1, 0."
Wrong/Poor markup has been written about many, many times over the years. Here's a few of the latest:
And if you want to see what detrimental effects junk markup can do, see this talk given by a blind person:
ebookcraft 2019, "The User's Perspective: Accessibility Features in Action".