Confluence Cloud Theming Beta and GA

Hello again Marketplace Partners :wave:

Over the last 3+ months since we enabled user-driven themes for the Developer Canary Program (see post) we have added theming support for nearly all Confluence Cloud experiences that were previously missing. Additionally we have gathered feedback, polished existing token use, and even added a theming toggle in Presenter Mode.

As a reminder, apps that have not yet adopted theming will render poorly for users who have chosen to use dark mode. In our early rollout metrics, we’ve consistently seen over 60% of users turn to dark mode over light mode. See details below for how to adopt themes if you need more information.

We are also ready to share some timelines and details about the full rollout of theming to all customers as a Beta feature and then moving theming into General Availability (GA).


  • As early September 12 as all continuous release customers will have access to theming as a Beta feature and Light theme will become the new default theme. Customers on release tracks will get access to theming as part of the next bundled release after that.
  • Over the next couple weeks we will be monitoring feedback and working on some solutions for items we’ve received consistent feedback on:
    • dark mode support for admin-driven color scheme settings which affect the top navigation background color
    • better legacy editor/pages support in dark mode
  • As early as the end of September, we will transition into a phase of General Availability (GA) which indicates to all customers and you, our Marketplace partners, that we consider theming to be ready for mass, stable use. We expect that there will still be a few areas to refine but none that are preventing use of themes.
  • At the end of October, we plan to remove Original as a “theme” option - Light will remain the default.

:balance_scale: We’ve consciously chosen Light to become the new default as opposed to Match browser. This helps ensure more users have a good experience when viewing apps that don’t yet have support for dark mode.

Adopting Themes

In case you missed some of our earlier communication about how to add theming to your apps, we have recently finalized some documentation which formally solidifies theming in Confluence and makes no changes to the approach we’ve previously outlined.

Themes are driven by the Atlassian Design System’s “Design Tokens” which you can read more about and reference here.


  • Connect apps should follow the approach as detailed in Theming Connect Apps. In particular, Connect apps would need to invoke window.AP.theming.initializeTheming().
    • Invoke window.AP.theming.initializeTheming() as early as possible in your application startup to avoid any “flashing” of nonthemed elements before theming is applied. This will apply the appropriate data-theme and data-color-mode attributes to the tag based on the theme defined by Confluence.


  • Forge apps using UI Kit without any color customizations will automatically inherit tokens.
  • Forge apps using Custom UI will need to apply design tokens as described above. The implementation follows closely to what was described for Connect apps. See more about Theming Forge Apps. In particular, Forge Custom UI apps would need to invoke view.theme.enable():
    • Invoke view.theme.enable() as early as possible in your application startup to avoid any “flashing” of nonthemed elements before theming is applied. This will apply the appropriate data-theme and data-color-mode attributes to the tag based on the theme defined by Confluence, consistent with the solution described above for Connect apps.


For general feedback about the look and feel of themes, please use the feedback mechanism within the theme switcher within Confluence.

If you have questions about how to implement theming in your apps, please comment here in this topic.

If you have already added theming support or are planning to do so soon, please share your progress - we’d love to hear about it!

Hi @AlexWhite ,

We are implementing the theming, and have a question about the content security policy.

When we call window.AP.theming.initializeTheming();, new styles are loaded through all.js. We can allow this style loading in all.js by using 'unsafe-inline' in the CSP, but this is problematic with style injection attacks. What CSP is recommended to allow the style loading in all.js?

Hi @AlexWhite,

Thanks for all of the updates!

Just to check, are you still tracking a fix for the flash of white background for popup dialogs are that are opened via Connect webItems->target->type=dialog (and with chrome=false)?


Hi @marc I am checking with our design system and Connect teams and will get back to you on the question about the security of loading inline styles.

1 Like

@scott.dudley I investigated this particular use case and also saw the brief flash of unthemed background before theming was applied. This is because the dialogs are rendering content within the Connect app iframe and if theming isn’t initialized fast enough in the DOM, the default HTML page background (white) will show. This bit is mentioned in Connect Theming but I realize it’s easier said than done. One trick you may try is to set your html and body background to something like var(--ds-surface, #777) which roughly splits the difference between light and dark surfaces (somewhat hedging your bets) and would lower the perceived change when the styles are actually injected and applied. We are brainstorming some potential improvements on this startup logic and will be sharing them with our Connect and Forge teams.

Hi @AlexWhite,

Thanks for the investigation. From this end, the white flash seems to comes from before our iframe content is even loaded, so I am not sure of how we could impact this on the application side.

I tried creating an iframe with static colors (html { background-color: green; } body { background-color: red; }), and when the dialog loads, it flashes: white (for a long time), briefly green, and then stays red.

It looks like applying background-color: transparent to html and body tags will solve the last half of the problem for the dialog use case (ensuring correct display once the iframe is loaded but before theming is initialized). I believe Atlassian still needs to adjust something on its end while the iframe is waiting to be delivered. As I wrote above, this Atlassian piece currently looks like it is the majority of the delay.