bug: author-defined text colors no longer rendering in all settings

[thedirk]

Bug in new release (0.29 Chrome App):

Expected Behavior

Previous releases in Readium performed as expected with regard to colored text.

In Settings > Style > Text & Background Color, any theme selected retained hard-coded color-coding (text colors defined by HTML span tags)... While default text colors (e.g., plain black text) varied according to theme.

In Settings > Layout > Scroll mode, hard-coded color text displayed as colored text throughout all three options.

Observed behavior

The current release of Readium does not perform as expected with regard to colored text.

In Settings > Style > Text & Background Color, only "Default Author Styles" properly displays text colors. All other themes for all text to "Theme Default" color.

In Settings > Layout > Scroll mode, hard-coded color text displays properly only on the "Auto" setting. Both "Document" and "Continuous scroll" settings force all text to default.

Steps to reproduce

1. First, create an EPUB with color text. (Mine is defined in the .xhtml text file, I haven't tested for CSS defined color text). Or, use my test file (below).
   For example:

   Here is some text in color

2. Then, import the EPUB into the Google Chrome Readium App.

3. Open it.

4. Change the settings (particularly Scroll Mode and Theme)—the color used to be stable throughout these options (as expected), and is no longer.

Test file(s)

https://drive.google.com/open?id=1wgQHQRZm3crGD9zYqgdYX7oEgf_KZKcY

Product

• Readium Chrome extension
  • latest official version available from the Chrome Web Store
  • Version 63.0.3239.84 (Official Build) (64-bit)
  • Windows 10 (64 bit)

[rkwright]

@danielweck @jccr
Confirmed that this is bug. Also verified that this is a REGRESSION. I only tested against 0.23, but it works fine there. In the latest (0.31-alpha) the theme overrides the user's specified colors. See the sample file here.

[danielweck]

Actually, the implementation of "themes" conforms to the expected behaviour ... if we accept that colour schemes consist in both a background and a foreground colour, consistently enforced into every part of the document.

I am personally open to revisit the definition of the feature, and to investigate ways to implement it correctly ... but if I remember correctly there were low-contrast issues because of background and foreground colours being selected from different sources, i.e. in cases where arbitrary / unpredictable author-specified colours where inadequately mixed with the forced background colour defined by the user-chosen theme. This is why we ended-up fixing the implementation by enforcing both background and foreground in the entire document, thereby overriding author styles entirely.

In a nutshell, if we allow authored colours to take precedence over the user-chosen theme, then we will re-open the issue of inappropriate colour combinations / low contrast / broken accessibility.

[danielweck]

Related issue: readium/readium-js-viewer#594

[danielweck]

Related issue: readium/readium-js-viewer#363

[danielweck]

Also see the technical solution we opted for to fix poor hyperlinks rendering:
readium/readium-js-viewer#203
readium/readium-js-viewer@4fb93be
readium/readium-shared-js@3907e7d#diff-103715cf0e3db43f218c7235fd2a18fb

[rkwright]

Hm I am reluctant to do so much work on R1 at this point.
Given that R1 now uses readium.css (in 0.31-alpha, correct?) is the behaviour of R2 the same? I'll test when I get upgraded to the current rev.

[danielweck]

I'm not sure whether "ReadiumCSS" background+foreground colour scheme takes precedence over entire documents, thereby discarding authored styles. @JayPanoz?