# Support dark color scheme **URL:** \ **Category:** Product Ideas\ **Tags:** not-priority, not-aligned\ **Created:** [September 7, 2026, 3:49pm UTC](https://discuss.liferay.com/t/support-dark-color-scheme/936 "2026-09-07T15:49:52Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![ole](https://avatars.discourse-cdn.com/v4/letter/o/fbc32d/32.png) [@ole](https://discuss.liferay.com/u/ole)\ **Post date:** [September 7, 2026, 3:49pm UTC](https://discuss.liferay.com/t/support-dark-color-scheme/936/1 "2026-09-07T15:49:53Z")
**Make liferay portal support OS/browser-native color scheme switching** Switching between light and dark color scheme is a feature supported by all major browsers. It has thoroughly matured and is becoming ever more popular. However, at the moment it is very tricky/hacky to implement a nice dark scheme in Liferay, using no-code/low-code approaches like content pages and style books. **What is your proposed solution?** When in the editor for Content Pages or the editor for Style Books, there should be a switch for dark mode. Very much like the switch between screen sizes in the Content Page editor, it should enable the user to define alternative settings (in the case of editing a Content Page) or values (when editing a Style Book) for when the browser is signalizing the use of dark mode, the equivalent of using `@media (prefers-color-scheme: dark)` in CSS. If the user does not define alternatives, everything defaults back to the use of the “regular” light mode settings/values. It would make sense to allow the definition of an additional “default value for dark mode” in the frontend token definition, anlongside the “normal” default value, but that is not a strict must. P.S. this is my first contribution to [discuss.liferay.com](http://discuss.liferay.com). If this is not the correct place for this feature request, please let me know. ---
**Author:** ![Victor\_Ware](https://dub1.discourse-cdn.com/flex014/user_avatar/discuss.liferay.com/victor_ware/32/119_2.png) [@Victor\_Ware](https://discuss.liferay.com/u/Victor_Ware)\ **Post date:** [September 8, 2026, 7:01pm UTC](https://discuss.liferay.com/t/support-dark-color-scheme/936/2 "2026-09-08T19:01:28Z")
We have a new Beta feature in our 2026.Q3 release for Dark Mode, can you take a look and give us your feedback? [Using Dark Mode - Liferay Official Documentation - Liferay Learn](https://learn.liferay.com/w/dxp/personalization/experiences/using-dark-mode) ---
**Author:** ![ole](https://avatars.discourse-cdn.com/v4/letter/o/fbc32d/32.png) [@ole](https://discuss.liferay.com/u/ole)\ **Post date:** [September 11, 2026, 1:56am UTC](https://discuss.liferay.com/t/support-dark-color-scheme/936/3 "2026-09-11T01:56:09Z")
Hi Victor, thank you for your reply! I have looked at the feature you pointed out and it is exactly _complementary_ to what I am suggesting. The documentation you linked states > `Dark Mode restyles the administration interface only, including the Product Menu, the Global Menu, menus, and the Control Panel. Site pages keep their own theme and don’t go dark, so site visitors see no change. The Page Editor works the same way: its toolbars and side panels go dark, while the page you’re editing keeps the site’s theme.` What I am suggesting is affecting the theme/style book, and therefore the pages. Technically, the user of the editor for style books would be able define an alternative set of values that apply when `@media (prefers-color-scheme: dark)`. In the UI of the style book editor, I imagine a simple switch, that lets the editor toggle between editing the two different sets (values for normal/light mode vs. values for dark mode). The editor for a content page would also feature such a switch, to implement the same functionality for the values that can be defined directly on the fragments. Selectively defining different values is already supported by the content page editor UI, namely for different screen sizes. Therefore, making the editor UI reflect different value sets is likely a functionality that just needs to be extended by a new dimension. ---
**Author:** ![ole](https://avatars.discourse-cdn.com/v4/letter/o/fbc32d/32.png) [@ole](https://discuss.liferay.com/u/ole)\ **Post date:** [September 14, 2026, 2:21am UTC](https://discuss.liferay.com/t/support-dark-color-scheme/936/4 "2026-09-14T02:21:23Z")
Hello again, Victor, I went ahead and implemented this feature as I imagined it. The result sits on a branch of my liferay-portal fork and is ready to be turned into a PR: [GitHub - olee87/liferay-portal at dark-color-scheme · GitHub](https://github.com/olee87/liferay-portal/tree/dark-color-scheme) The feature has four parts: 1. The content page editor UI features a new switch to toggle between light and dark mode. The values defined in dark mode are separate from the ones defined in light mode, very much like the separate values for different screen sizes. 2. The style book editor features a new switch behaving equivalently. 3. Frontend token definitions may now optionally define a separate default value for dark mode. 4. the classic theme has been slightly changed to fully benefit from this ability and it comes equipped with a full set of dark default values for it’s tokens, effectively serving as a working example of how to set up dark mode. Apart from this, the following points are worth mentioning: - both editors simulate the dark/light mode based on the state of the switch in the editor and ignore the browser’s style directives. - an effort has been made to not have this feature collide with the dark mode of the admin UI (LPD-57922) - a feature flag guards this entire feature - even when acitvated, the entire feature is completely backwards compatible and there are sensible fallbacks so the non-usage of this feature results in no visual change at all. **Visuals** : Content Page Editor: ![Screenshot 2026-09-12 at 20-30-42 Home - Liferay Development (Editing)](https://europe1.discourse-cdn.com/flex014/uploads/liferay/original/1X/c1e756c742880ada5dd72ccb7604af4b83a3bf8f.jpeg) ![Screenshot 2026-09-12 at 20-31-29 Home - Liferay Development (Editing)](https://europe1.discourse-cdn.com/flex014/uploads/liferay/original/1X/3a02be9bda8ae690cd7516e848b130dd85d27cd9.jpeg) Style Book Editor: ![Screenshot 2026-09-12 at 20-32-13 Style Books - Liferay Development](https://europe1.discourse-cdn.com/flex014/uploads/liferay/original/1X/e91da7cad20199cd6274e562f636c44f502573a0.jpeg) ![Screenshot 2026-09-12 at 20-33-29 Style Books - Liferay Development](https://europe1.discourse-cdn.com/flex014/uploads/liferay/original/1X/893bf730550e25397e7c87f9ce26b44d997ecc52.jpeg) resulting page: ![Screenshot 2026-09-12 at 20-35-00 Home - Liferay Development](https://europe1.discourse-cdn.com/flex014/uploads/liferay/original/1X/19a0116e7f7889cf11820386daadeb6230ec52db.jpeg) **Request** : In order to create a proper PR, I understand I will need an LPS ticket which i cannot open myself (?) - also, the feature flag is called LPS-000000 as of right now. an obvious place holder that will be changed, once I have a proper ticket. I am very interested in using this feature myself and would be delighted to help with what it takes for this to make it into the next release. What are the next steps? Thank you and best regards, Ole ---
**Author:** ![Marcos](https://dub1.discourse-cdn.com/flex014/user_avatar/discuss.liferay.com/marcos/32/409_2.png) [@Marcos](https://discuss.liferay.com/u/Marcos)\ **Post date:** [September 15, 2026, 3:36pm UTC](https://discuss.liferay.com/t/support-dark-color-scheme/936/5 "2026-09-15T15:36:15Z")
Hi Ole, first of all, thank you. Taking the time to write this up and to build a working proposal is a very valuable contribution, and it is exactly the kind of feedback that helps us prioritise. Sorry as well for the detour: the page Victor linked covers the administration dark mode only, which is not what you asked about in March. I am not sure you have had the chance to see it, but with 2026.Q3 we also shipped a second theme, Prism, that already carries the double value per token. It is behind the same Beta flag (Dark and Light Mode, LPD-57922, or Clay’s Global Frontend Token Definitions, LPD-84497), and once the flag is on it becomes the default theme for new sites. Its frontend-token-definition.json defines the colour tokens as pairs, for example `light-dark(#fff, #111116)` for `white` or `light-dark(#f7f8f9, #272833)` for `gray-100`; 158 of its 305 tokens work that way. Clay resolves them through `color-scheme` and the `data-color-scheme` attribute on `html`, and the Style Book colour picker accepts `light-dark()` values since Q3, so a Style Book based on Prism can already hold a light and a dark value for every colour token. ![image](https://europe1.discourse-cdn.com/flex014/uploads/liferay/original/1X/aca3abac213f169ba942ba7a1174496c7f813e1d.jpeg) What Prism does not offer yet is a comfortable way to manage those double tokens: today you write the pair in the token field. That is deliberate for now, and the reason is the paragraph below. We do not want to be prescriptive about how each site solves light and dark, or whether it needs more skins (High Contrast variants are coming for the administration and whatever we build has to scale to four colour schemes, not two), and the same goes for whether the scheme should follow the operating system or a control on the site. That is also why we split the themes: Classic stays exactly as it was, so nothing breaks for existing sites, and Prism is the example of how a theme collects dark and light values on top of Clay tokens. And I do mean an example, not the way to do it. The token pair in Prism is one option; a theme can just as well ship two Style Books and switch between them, or resolve the scheme in its own CSS with `prefers-color-scheme`, or expose only the tokens it wants to expose and keep the rest fixed. In fact, other customers have implemented dark mode in completely different ways, and those are just as valid. Our job is to make sure the token system does not get in the way of any of them, not to pick one for you. One more piece that may help: with the flag on, the Product Menu has a global light/dark switch (the moon/sun button). It stores the choice in the session of the signed-in user and writes it as `data-color-scheme` on the `html` element, which is what Clay and the Prism tokens react to. If your theme picks that attribute up the way Prism’s `portal_normal.ftl` does, editors and administrators switch schemes with that button while they work, and no extra switch is needed inside the page editor: the page simply renders whatever the Style Book resolves to for the active scheme. Note that this covers signed-in users only. For the anonymous visitor of the site, whether the scheme follows the operating system or a control you add is still your decision, which is exactly the point above about not being prescriptive. ![image](https://europe1.discourse-cdn.com/flex014/uploads/liferay/original/1X/9080cb7a4850607386aef7b8e7775df5c6519beb.png) The editing experience for the tokens themselves is designed and on the roadmap: a light/dark switch in the Style Book editor, which is where we believe colour tokens should be managed, rather than in the page editor. We will take your feedback into account as we finish that work, in particular the need you describe for editors to manage both schemes without leaving the low-code tools. Thanks again for pushing on this. Prism token definition, for reference: modules/apps/frontend-theme/frontend-theme-prism/src/WEB-INF/frontend-token-definition.json in master. ---
**Author:** ![ole](https://avatars.discourse-cdn.com/v4/letter/o/fbc32d/32.png) [@ole](https://discuss.liferay.com/u/ole)\ **Post date:** [September 15, 2026, 11:20pm UTC](https://discuss.liferay.com/t/support-dark-color-scheme/936/6 "2026-09-15T23:20:39Z")
Hey Marcos, thank you for your response and your thorough explanation! I understand your point of not wanting to be prescriptive. My intuition in this regard would be not to force, but actually yes to guide the developer to a preferred way of implementing multi-color-scheme themes. And as you describe it, LPD-57922 does not seem unopinionated (e.g. the admin gets a UI switch rather than using the browser color theme; my preference would be to have my browser propagate the color scheme) - but of course this is a matter of taste. I also realize my proposed solution breaks down in the face of more than two color schemes. I agree that colors should generally be managed in the style book. Your answer has made me curious though about how you would approach other aspects of color schemes. For example, when we implemented a dark mode for our custom theme, we had to deal with box shadows that were not supposed to appear in dark mode. This is a case where I think it would be more suitable to decide on a per-fragment-basis, although sure, this could still be solved with frontend tokens. How about displaying a different image in dark mode vs. in light mode? This is clearly outside of the realm of style books. Is there a good low-code/no-code way to achieve this today? I will make sure to take a close look into LPD-5792 and I am curious to follow the further development of this. Once again, thank you for taking the time for your detailed answer! ---
**Author:** ![Marcos](https://dub1.discourse-cdn.com/flex014/user_avatar/discuss.liferay.com/marcos/32/409_2.png) [@Marcos](https://discuss.liferay.com/u/Marcos)\ **Post date:** [September 16, 2026, 9:44am UTC](https://discuss.liferay.com/t/support-dark-color-scheme/936/7 "2026-09-16T09:44:53Z")
Thanks Ole, fair points. On being “unopinionated”: it is deliberate, and the reason is practical. The moment we bless one way of doing light/dark as the good one, we slightly invalidate every other way, and we have already met customers who chose different solutions or who need more than two colour skins. So, for now, we keep the token system open and Prism as one worked example inheriting our admin UI Tokens. That may well evolve as we learn from cases like yours. On the admin switch: the safe control for now is an explicit light/dark choice. We started by inheriting the OS preference and decided, for the time being, to give users a specific control over that decision instead. The ideal end state is Auto / Light / Dark, which we are evaluating internally. On your two cases: box shadows are already covered with Prism example, since boxShadow, boxShadowSm and boxShadowLg are Style Book tokens; a value such as `0 .5rem 1rem light-dark(rgb(0 0 0 / .15), transparent)` keeps the shadow in light and removes it in dark. For images, our own answer in the administration is not to swap files but to make the artwork token-aware: we are modernising the illustrations as inline SVG whose fills and strokes come from the colour tokens, so one asset renders correctly in Light, Dark and both High Contrast skins. You can see the approach here: [Illustration — Vanilla Lexicon](https://liferay-design.github.io/lexicon-vanilla/prototypes/illustration.html) . For photographic or bitmap images that genuinely need two versions there is no low-code path today; it takes a small custom fragment with two image editables and a CSS rule on `[data-color-scheme="dark"]` or `prefers-color-scheme`. Your feedback is very valid and it is going into our notes for this topic. Thanks again for the follow-up.