Should we try to handle some “CSS hacks”?

[JayPanoz]

So, I can confirm that fixing (see PR #80 ) the performance issue related to the "blanket" application of background-color (sepia or night modes) on all elements in the document's body ... results in a "small" regression with borders / labelled outlines. I say "small", because in my tests the performance degradation was orders of magnitude more detrimental than the visually-annoying border outline (striked-through label).

Screenshots:

Of course, ideally we would find a solution to the performance issue that would not break publication documents ... but unfortunately I ran out of ideas (and time) so I settled for the workaround of applying a transparent background colour everywhere.

Also, note that my fix works in Chromium 80 (Electron 8) ... but your mileage may vary in other browser engines. I suggest using Children's Literature ( https://idpf.github.io/epub3-samples/30/samples.html#childrens-literature ) in order to test the performance impact of CSS design choices (including triggering the GPU 2D / 3D acceleration, in some cases, like I did in ReadiumCSS PR #80). That is because Children's Literature has a single relatively-large spine item in the reading order ( https://github.com/IDPF/epub3-samples/blob/master/30/childrens-literature/EPUB/s04.xhtml ), so when font-size is cranked-up between 150% or 200% for low-vision users, the CSS column pagination spans a great number of pixels on the horizontal axis (consequently, the browser engine's layout and rendering subsystem must then somehow optimize these textures in memory / on the graphics card, and it seems that some combination of CSS rules trigger a more performant render path)

Originally posted by @danielweck in #68 (comment)

[JayPanoz]

Thanks for the recap.

I say "small", because in my tests the performance degradation was orders of magnitude more detrimental than the visually-annoying border outline (striked-through label).

Yeah and it’s only one “CSS hack” we tried to handle here, I’m not sure we want to handle every conceivable CSS hack because they are de facto corner cases. For instance, we would have the same issue with leading dots in an ePub2-compatible way – using background-color.

[JayPanoz]

This issue was discussed during the Engineering call on March 25.

As a recap (sorry, no notes), it was agreed there are issues we won’t be able to fix properly given settings/overrides don’t have any proper standard/API, and unless you remove all styles e.g. Reader modes in browsers, covering 75–80% of cases with only CSS (no JS) is good enough.

Readium CSS has been doing its best to take authors’ intents into account so removing all styles is obviously something it won’t do, nor advise.