-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
theme in a publication does not apply everywhere #68
Comments
Ah right so unlike night mode, sepia mode doesn’t override So the following is not used in sepia mode: readium-css/css/src/modules/ReadiumCSS-night_mode.css Lines 26 to 30 in 14f1044
The assumption was that it’s a light mode close to the default enough that asides with I’m not sure what the best option is though, as by fixing this issue, we will automatically lose this nuance in non-fiction. Note: I’m also wondering how this renders in night mode in both apps, since |
Ah thanks so I’ll have to fix that in night mode also. Otherwise, I guess it would help to gather opinions on the following:
So @llemeurfr and @danielweck for instance, since they were in the original issue. :-) |
Hi @JayPanoz, for sure, the iBooks rendering of this specific book (from Feedbooks) is far better. And we know that many publishers are using iBooks as a reference for finalizing their EPUBs. So I would be inclined to follow their choice and override background colors when themes are active, which would be better for accessibility purpose IMO. |
Thanks! It is my understanding too that sepia mode may be used quite a lot in dys so a11y is one of my concerns. |
@panaC I pushed fixes to the reading-mode-improvements branch so ReadiumCSS-after has been updated in dist (for all versions). Looks OK here but can you please confirm it’s also the case on your end before I merge on develop/master? @danielweck I also updated highlights (re #65) i.e. putting them at the very end of the after stylesheet, adding selectors for sepia/night-mode + |
I will create a special / temporary build of |
@panaC @danielweck Yikes, sorry for the delay, just emerging now and I can see the last comment was made on August, 5. Is the fix OK? It’s been sitting in a branch for months now and should probably be merged into production. |
Good point ... I need to revisit this! (will report back) |
Thanks. And just to be sure as I edited my previous comment, the fix is in the |
Thanks for the confirmation, I will merge into |
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) |
Thanks for the recap.
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 |
H.+G.+Wells+-+The+Time+Machine.epub.zip
The text was updated successfully, but these errors were encountered: