Colored Text, EPUB, Android Dark Mode

[mingsphinx]

The CSS in my EPUB has a class where the color of the text is specified. I then use "<span class="xyz">abc</span>" to define which parts of the text I want highlighted by that color. The problem is that many EPUB readers actually seem to override the font specifications. Is there a way for me to force the reader to use my font specification?

[DNSB]

Originally Posted by mingsphinx

The CSS in my EPUB has a class where the color of the text is specified. I then use "<span class="xyz">abc</span>" to define which parts of the text I want highlighted by that color. The problem is that many EPUB readers actually seem to override the font specifications. Is there a way for me to force the reader to use my font specification?

The simple answer is no. There are quite a few epub renderers that pay minimal to no attention to embedded CSS. After all, the developer who created the renderer knows how every book should be displayed so no need for the embedded CSS. Look at Moon+ reader where the user has to dig into the preferences to enable CSS (at least as of about 8 months ago).

[Turtle91]

edit: Dang-it, ninja'd again!!

Some readers/devices think they know better how to display a book than the publishers that created them. Unfortunately, a lot of publishers prove them right... Also, there are many devices that simply can't display color - like eink...

Some of those readers/apps have the option to view in "publisher's mode", but that would require the user to select that option. Apart from that, you can't really "force" the reader to follow your css.

The best you can do is keep your css as simple as possible.... and possibly use media queries to determine how to style your spans.... a color display that is friendly to publisher's css => colored font; an older eink display => might need to be highlighted with an <em> tag with bold and/or italic styling.

[mingsphinx]

Originally Posted by DNSB

The simple answer is no. There are quite a few epub renderers that pay minimal to no attention to embedded CSS. After all, the developer who created the renderer knows how every book should be displayed so no need for the embedded CSS. Look at Moon+ reader where the user has to dig into the preferences to enable CSS (at least as of about 8 months ago).

Thanks.

[mingsphinx]

Originally Posted by Turtle91

edit: Dang-it, ninja'd again!!

Some readers/devices think they know better how to display a book than the publishers that created them. Unfortunately, a lot of publishers prove them right... Also, there are many devices that simply can't display color - like eink...

Some of those readers/apps have the option to view in "publisher's mode", but that would require the user to select that option. Apart from that, you can't really "force" the reader to follow your css.

The best you can do is keep your css as simple as possible.... and possibly use media queries to determine how to style your spans.... a color display that is friendly to publisher's css => colored font; an older eink display => might need to be highlighted with an <em> tag with bold and/or italic styling.

Most readers will allow a different color scheme for links. I am wondering if instead of defining the text with a <span> tag, would I get to use a different color in my texts by using a link <a> tag that has a null href?

[mingsphinx]

If I tag a segment of text as a link, most of the EPUB readers will make that text a different color (usually blue) and underline it. But the opening tag has to be <a href="xyz">. If the href is left out, then most readers will simply disregard the <a> tag and the text will be styled as with any text. If I set the href to null, meaning: <a href="">, then the readers will style the text as blue and underline it but then display an error when the link is clicked on.

Is there a way for the href to end up refering to that segment of text? It would be a complicated way of adding color to text but since there is no way at this point to get most EPUB readers to respect the css styling, this might be one work around.

[Notjohn]

Originally Posted by Turtle91

The best you can do is keep your css as simple as possible....

Substituting "life" for "css," I find this to be true of almost every situation I encounter.

[Turtle91]

Originally Posted by mingsphinx

Most readers will allow a different color scheme for links. I am wondering if instead of defining the text with a <span> tag, would I get to use a different color in my texts by using a link <a> tag that has a null href?

No, I wouldn't try and kluge together a different tag <a> just to get a color change...1) eink displays can't display color and 2) it is semantically incorrect.

The <em> tag is specifically designated for text that needs to be emphasized. If you don't define the styling you want for <em> it usually defaults to italics but you can designate the style however you want.

eg
em {color:red; text-decoration:underline}

If the device you are using doesn't respect the publisher's CSS then you could try giving in-line styling *shudder*

eg
<p>This sentence contains an <em style="color:blue">emphasized</em> word.</p>

That doesn't help with non-color displays....so, again, your best bet is to try media queries. Then you can have stuff like:

If this device is an eink:
em {font-weight:bold}

If this device isn't an eink, but can't display color:
em {font-style:italic}

all other devices:
em {color:blue}

with:
<p>This sentence contains an <em>emphasized</em> word.</p>

note: that is not the proper syntax for media queries...just giving the idea...but you can learn a little bit more about how to do them at the W3Schools website.

There is also a Sigil plugin, AddKindleMediaQueries that will add some code to get you started with kindle devices...you will need to figure out the other devices on your own.

Cheers,

[theducks]

Originally Posted by mingsphinx

Most readers will allow a different color scheme for links. I am wondering if instead of defining the text with a <span> tag, would I get to use a different color in my texts by using a link <a> tag that has a null href?

e-ink has no color (at least most of them)

Your idea of using a Link styling has merit for COLOR displays.
eg.

<style>
a:link {
  color: green;
  background-color: transparent;
  text-decoration: none;
}

a:visited {
  color: pink;
  background-color: transparent;
  text-decoration: none;
}

a:hover {
  color: red;
  background-color: transparent;
  text-decoration: underline;
}

a:active {
  color: yellow;
  background-color: transparent;
  text-decoration: underline;
}
</style>

[mingsphinx]

Originally Posted by Turtle91

No, I wouldn't try and kluge together a different tag <a> just to get a color change...1) eink displays can't display color and 2) it is semantically incorrect.

The <em> tag is specifically designated for text that needs to be emphasized. If you don't define the styling you want for <em> it usually defaults to italics but you can designate the style however you want.

eg
em {color:red; text-decoration:underline}

If the device you are using doesn't respect the publisher's CSS then you could try giving in-line styling *shudder*

eg
<p>This sentence contains an <em style="color:blue">emphasized</em> word.</p>

That doesn't help with non-color displays....so, again, your best bet is to try media queries. Then you can have stuff like:

If this device is an eink:
em {font-weight:bold}

If this device isn't an eink, but can't display color:
em {font-style:italic}

all other devices:
em {color:blue}

with:
<p>This sentence contains an <em>emphasized</em> word.</p>

note: that is not the proper syntax for media queries...just giving the idea...but you can learn a little bit more about how to do them at the W3Schools website.

There is also a Sigil plugin, AddKindleMediaQueries that will add some code to get you started with kindle devices...you will need to figure out the other devices on your own.

Cheers,

Thank you so much. The problem is that there are many eReaders on the market that will completely disregard CSS. Using tags like <em> or <i> will reliably get the machines to display the text in italics just as using <strong> or <b> will produce bold; but styling the <em> tag often fails because the eReaders will disregard the style sheets and only display the text in italics. It is better than using a special class of <p> or <span> because at least there is some change when <em> is used whereas when <p> or <span> is used the result is often nothing.

Without the styling, the final outcome can look very bad, almost unreadable at times. With the proliferation of OLED display cellphones, more and more people are using eReaders on their phones because Dark Mode display, which greatly reduces the phone's energy consumption, affords them hours of reading on a device they already have without having to purchase or carry around another one. The problem is that many of these eReaders will simply disregard CSS, because Dark Mode does require the phone to set its own color scheme, and anyone that relies on CSS to style their work runs the risk of creating the impression among their readers that their work is inferior.

I have found that only the <em> and <i> tags for italics and <strong> and <b> tags for bold are reliably rendered. The <a> tag is also reliable in that it will almost definitely be underlined and possibly made blue if the eReader can display color. But the problem with using the <a> tag is getting the href to refer back to the text that was highlighted as I mentioned above.

The underlying philosophy of what I am trying to do is simply to get to lowest common denominator and create documents that will display the same regardless of eReader.

[mingsphinx]

Originally Posted by theducks

e-ink has no color (at least most of them)

Your idea of using a Link styling has merit for COLOR displays.
eg.

<style>
a:link {
  color: green;
  background-color: transparent;
  text-decoration: none;
}

a:visited {
  color: pink;
  background-color: transparent;
  text-decoration: none;
}

a:hover {
  color: red;
  background-color: transparent;
  text-decoration: underline;
}

a:active {
  color: yellow;
  background-color: transparent;
  text-decoration: underline;
}
</style>

Thank you. I have become very shy about using any styles because many eReaders will disregard the styling. My desire to explore the possibilities of the <a> tag arises from how all eReaders will treat it. As a matter of convention, all eReaders will underline a link and those that can display color will usually make the text blue. So if I enclose part of the text with the <a> tag, I can at least be certain that the portion marked off will at least be underlined for all users. The only problem is getting the href to refer to the segment of text itself because if all I do is tell the machine to go to the html file that the segment of text is stored on, anyone clicking on the link will be brought to the start of that page which is frustrating if you are in the middle of it.

[Tex2002ans]

Originally Posted by mingsphinx

The CSS in my EPUB has a class where the color of the text is specified. I then use "<span class="xyz">abc</span>" to define which parts of the text I want highlighted by that color. The problem is that many EPUB readers actually seem to override the font specifications. Is there a way for me to force the reader to use my font specification?

I'm confused:

• Colors
• Highlighting
• Emphasizing
• Underlining
• Fonts

What's the ultimate goal here?

Can you show us an example picture of a document and what you're trying to achieve?

Originally Posted by mingsphinx

So if I enclose part of the text with the <a> tag, I can at least be certain that the portion marked off will at least be underlined for all users.

<u> is HTML for underline.

If underlining is what you want, that would achieve it. And every single reader/browser in the world would display an underline:

<p>This is a sentence with <u>underlined</u> text.</p>

Trying to hack links (<a>) to do this is a very, very bad idea.

Originally Posted by mingsphinx

The only problem is getting the href to refer to the segment of text itself because if all I do is tell the machine to go to the html file that the segment of text is stored on, anyone clicking on the link will be brought to the start of that page which is frustrating if you are in the middle of it.

... Are you trying to create an actual link? Or emphasizing? Or what?

If you're having trouble getting basic HTML links to work, I believe you're trying to jump too far into the complicated deep-end.

I would highly recommend learning some more of the basics of HTML first:

• What's a <p> tag?
• How does <img> work?
• How does <a> work? What's it used for?

Here's an example I wrote last year about <a>:

Post #3 in "hyperlink endnotes"

I even color coded the parts of a link red+blue in order to explain easier.

Originally Posted by Turtle91

Some readers/devices think they know better how to display a book than the publishers that created them. [...]

Some of those readers/apps have the option to view in "publisher's mode", but that would require the user to select that option. Apart from that, you can't really "force" the reader to follow your css.

The best you can do is keep your css as simple as possible....

Agree completely.

Follow the standards, code your book properly, and then if the user wants to use some crappy CSS-overriding-reader like Moon+, then that's on them.

[mingsphinx]

Originally Posted by Tex2002ans

I'm confused:

• Colors
• Highlighting
• Emphasizing
• Underlining
• Fonts

What's the ultimate goal here?

Can you show us an example picture of a document and what you're trying to achieve?



<u> is HTML for underline.

If underlining is what you want, that would achieve it. And every single reader/browser in the world would display an underline:

<p>This is a sentence with <u>underlined</u> text.</p>

Trying to hack links (<a>) to do this is a very, very bad idea.



... Are you trying to create an actual link? Or emphasizing? Or what?

If you're having trouble getting basic HTML links to work, I believe you're trying to jump too far into the complicated deep-end.

I would highly recommend learning some more of the basics of HTML first:

• What's a <p> tag?
• How does <img> work?
• How does <a> work? What's it used for?

Here's an example I wrote last year about <a>:

Post #3 in "hyperlink endnotes"

I even color coded the parts of a link red+blue in order to explain easier.

Thank you but I am not trying to hack anything using HTML. And thank you for pointing out the <u> tag which I missed earlier.

The problem is this: with the proliferation and increasing popularity of cell phone based eReaders, in particular with the advent of OLED enabled Dark Mode, more and more eBooks are being consumed by readers using their mobile phones. Some eReaders like Moon+Reader will repect CSS styling whereas other eReaders like Prestigo will not. There are many reasons to choose one eReader over another and no one app can be said to dominate the space. Prestigo for instance offers text-to-speech for free whereas one would have to pay for it in Moon+Reader. Because of the heterogeneity of the eReader space, the final product which the reader experiences can be somewhat unpredictable; particularly if one uses CSS.

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>. Unlike the style sheets which some eReaders will disregard, all eReaders I have looked it seem to respect these basic tags. Meaning that if you style your work only with these tags, it should then look more or less the same agnostic of the viewing device. I say more or less because aside from ignoring the document styling, some eReaders will force their own styling like increasing the line spacing.

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.

[Tex2002ans]

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

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

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:

• "Night Mode": Images-of-characters vs. Unicode Characters
• Musical Notes (via embedded font)

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.

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
  
  • Don't do <span class="italics">
• 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:

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:

• 2018 "Skeleton CSS"
• 2018 "Accessibility question: TTS and ligatures"

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

[DiapDealer]

Originally Posted by mingsphinx

To be absolutely certain that the final product looks similar regardless of the device used to render it ...

Therein lies a big part of the problem. You can't be absolutely certain in all cases.