Skip to content
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

Global dark modes? #75

Closed
JayPanoz opened this issue Jan 22, 2020 · 6 comments
Closed

Global dark modes? #75

JayPanoz opened this issue Jan 22, 2020 · 6 comments

Comments

@JayPanoz
Copy link
Collaborator

Similar to high contrast mode in Electron to some extent.

There is a media query for dark modes now, and the question is whether we should try to do something clever or not with it.

At first sight, the discussion will revolve around the following questions/issues:

  • should night theme be the default theme if the global dark mode is set? (iBooks does that)
  • overriding this default night theme + possible side effects?
@JayPanoz
Copy link
Collaborator Author

As a precision:

should night theme be the default theme if the global dark mode is set? (iBooks does that)

this is also about predictability for implementers. Maybe it’s a better option to let them set that themselves because it makes it easier to manage than a default in CSS.

@danielweck
Copy link
Member

I have a preference for letting the host application decide when to apply the "dark theme" in ReadiumCSS. I assume both native apps on iOS/Android and Electron-based desktop apps "listen" to system-wide changes for dark vs. light modes, which in turn triggers some re-rendering of the app user interface. If ReadiumCSS triggers its own separate switch based on the CSS Media Query (arbitrary timing), this may result in some perceivable "flash" between the webview-rendered content and the app's own UI chrome. Reminder: an Electron-based app renders its UI in a webview as well (using HTML + CSS + Javascript + SVG, etc.), but EPUB content documents are rendered by inner / embedded webviews, so there is some degree of seamless synchronization.

@JayPanoz
Copy link
Collaborator Author

Yeah I’m sharing your point of view because of these reasons.

Moreover, if you take a look at the os_a11y module, it has the potential to become a huge bag of bones, and suddenly, Readium CSS would introduce unpredictability and possible edge cases making it a lot harder to manage for implementers.

@JayPanoz
Copy link
Collaborator Author

JayPanoz commented Feb 5, 2020

So this issue is paused and we will revisit it later, once we know how it can be handled on iOS and Android.

@JayPanoz
Copy link
Collaborator Author

@mickael-menu Not urgent but I’m doing a little bit of triage given I’m quickly init’ing a doc of features that were considered but not implemented (re #84).

When you have some spare time, could you confirm these docs make it sound like it will be manageable in Android/iOS?

Since our use case (applying light/dark mode to EPUB contents) is not directly addressed, I prefer to have a confirmation as we would prefer to handle it outside ReadiumCSS given the issues it would create for implementers.

@mickael-menu
Copy link
Member

I agree with both of you, better let the app control this. It might not be Dark Mode ready and then it would be weird to have the content automatically switch. Also a user might want to have an automatic Light/Dark mode switch system-wide, but keep a white background for ebooks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants