You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 17, 2020. It is now read-only.
all installed within an ember application. Imagine each of these mentioned addons above ships it's own set of themes. The final theme for your application will be theme x of addon a + theme y of addon b + ....
Composition all of the themes is already possible with current javascript, but is a manual task. However, it can be better supported from ember-makeup itself, maybe something like a ThemeCompositor class that helps with that (given there is a convention for a theme) and by that would only become declarative.
This theme composition can be used to handle some (or all?) of the cases where a context is being used. There would be then a base-theme with different variations (light and dark) which would then be composable, e.g.
That said it musn't be light and dark. A high contrast theme can and will be an important use-case (thinking of accessibility) but combinations are limitless.
A potential counterpart I see is that browsers might support light/dark mode through a standard (like safari is having the experimental one here) and then the css has a "switch" to show either variant. Yet this could also be made declarative and be put nicely together in the end anyway ;)
Dunno if I oversee a technical part here that conflicts with this idea.
The text was updated successfully, but these errors were encountered:
I am not sure, that this is something we would want to support in the first place. The point of this addon and how we want to use it is to have a single repository that contains all configuration.
This makes it easy to reason about and add new brand configurations. It gets much more complicated, once you start feathering this out into multiple addons, that each include their own configuration.
There will however be a "sort of" implicit schema validation, to ensure that tokens referenced by addons are resolved.
Regarding the user agent preferred light / dark mode: If the user did not explicitly select a color mode, we can read the prefers-color-scheme media query in browsers that support it. Otherwise we use the default setting, e.g. light.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Imagine this landscape:
all installed within an ember application. Imagine each of these mentioned addons above ships it's own set of themes. The final theme for your application will be theme x of addon a + theme y of addon b + ....
Composition all of the themes is already possible with current javascript, but is a manual task. However, it can be better supported from ember-makeup itself, maybe something like a
ThemeCompositor
class that helps with that (given there is a convention for a theme) and by that would only become declarative.This theme composition can be used to handle some (or all?) of the cases where a context is being used. There would be then a base-theme with different variations (light and dark) which would then be composable, e.g.
That said it musn't be light and dark. A high contrast theme can and will be an important use-case (thinking of accessibility) but combinations are limitless.
A potential counterpart I see is that browsers might support light/dark mode through a standard (like safari is having the experimental one here) and then the css has a "switch" to show either variant. Yet this could also be made declarative and be put nicely together in the end anyway ;)
Dunno if I oversee a technical part here that conflicts with this idea.
The text was updated successfully, but these errors were encountered: