@sash011 2p apps built on Connect for the legacy editor have to explicitly add support in their app for dark mode. We have an internal test app which supports theming and shows correctly in dark mode while editing both bodied and body-less macros. See:
If you’re talking about the small graphic placeholder that is cream-colored in the editor - it’s a generated image that we did not necessarily consider “wrong” in dark mode, though it could be better. Considering the complexity in adjusting this logic to generate a more dark-compatible placeholder and the amount of users who would actually see this being extremely low (editing a legacy page, with a Connect macro, and in dark mode) it is unlikely this will get worked on. Adding dark mode support to the legacy editor at all was already something above-and-beyond considering the public stance on the legacy editor not receiving any new features.
Please let me know if I’m still missing your reference. In that case, a screenshot would be helpful.
Yes, this is exactly what I was talking about - light color headers for placeholders even when the dark mode is used
Does not feel right in my opinion. But if you think that " we did not necessarily consider “wrong” in dark mode", then “let it be”.
PS, we have quite a bunch of our customers who have migrated from server and continue to use the legacy editor, as they are mostly unhappy with the “modern one”.
Understood. We know there are still many users who feel very attached to the legacy editor for one reason or another. The entire Confluence Cloud organization is aware of this and continues to work in enhancements to the modern editor to address those gaps. As with most things, though, those have to be prioritized with other features and fixes. Furthermore, as of October 2023, we tracked that less than 8% of all page edits are legacy pages. The fact that we’ve previously outlined that the legacy editor would not receive new features (even though we did add a fair amount of dark mode support to it in the name of our customers and company values) and given the relatively low number of legacy page edits AND far lower number of legacy page edits in dark mode, we likely won’t be focusing on adjusting most of these gaps like the cream-colored macro placeholder mentioned above. That being said if it is something you feel strongly about, feel free to create a ticket on jira.atlassian.com under CONFCLOUD so that it can be voted on and triaged. Thanks for your partnership and understanding!
Hi @chhantyal I added a comment to the CONFCLOUD and tagged you.
Apologies for the delays on this one. The particular fix for this was quite complex and also had security implications as we needed to create a new sanitization exception to allow design tokens to pass through. I will also note that we had prioritized a dark mode fix with dynamic content macros first because it is used by 4.5x more apps than static content macros. That fix was recently released.
Nonetheless, I am happy to report that we are finally rolling out this fix! We are rolling it out cautiously because of the sensitive and widespread use of this logic. We will update the status of this issue once the rollout is complete in roughly a week.
Hi @marc No there is no change on that. @DanielDelCore can comment more on that. Because the previous change he mentioned required a 6 month notice, I believe he attempted an alternative solution but there was some pushback from some partners. That being said, I am going to loop in @SamLeatherdale from the Connect team who we’ve also had discussions with about requiring the CSP to include the Connect CDN for styles.
@chhantyal I’ve updated https://jira.atlassian.com/browse/CONFCLOUD-77050 and marked it as Closed/Fixed. You can now use CSS variables for Atlassian design tokens in your static content macros. Please confirm this is working for you when you next get the opportunity. Thanks for your patience on this tricky change.
Hi @AlexWhite I am going to sound harsh again, I am sorry.
You closed the ticket without even confirming if it is actually fixed. So much back and forth for nothing. Please give us a plain working code example, that’s all we are asking.
@chhantyal We confirmed the fix in our own test apps after the code changes were rolled out. This ticket is ONLY to support CSS variables for providing design tokens in the markup of static content macros.
An example template for a static macro using design tokens would look like this:
{{!< layout}}
<span
style="border-radius:4px;padding:4px;color:var(--ds-text-accent-lime, #32CD32);border-color:var(--ds-border-danger, #FFFF00);border-style:solid;"
class="cc-eco-test-macros-block-output">
Static Content Macro using design tokens for colors
</span>
If there are additional CSS properties you would like to use in static content macros that are currently being filtered out, please create a new Suggestion. It was only a bug that tokens were filtered out - not generically any CSS. We have strict whitelisting for security purposes - since static content macros are rendered directly into the Confluence page and not via iframe as is the case with dynamic content macros. We can evaluate additional whitelisting based on request and importance. The good news is that enhancing this sanitization will be simpler now that we have done it for the tokens.
ds-surface and ds-surface-overlay are two different colors (#1d2125 vs #282e33). Can you please fix one or the other to make them consistent? We want to try to match the system colors, but this leaves a colored band around the dialogs in one of these places because we can only use one color. (I suspect that ds-surface-overlay is the intended option for both places.)
