Macros cannot integrate with constantly changing Fabric styles

As part of our product, we have macros (dynamic and static) that ideally need to look the same as the non-macro content.

In other words, if the macro content is a Shakespeare sonnet, and the non-macro content is a Shakespeare sonnet, those sonnets should look more or less the same.

Since we cannot access parent styles from within our iframed dynamic content macros, we are forced to try to scrape non-documented Fabric styles into our own stylesheet.

This would be tedious by itself, but we are observing that the Fabric styles are constantly changing without any warning, meaning that we are essentially playing an unwinnable cat and mouse game trying to keep up.

To give an example with the most basic of things: font size. Text in Fabric used to be 16px in edit (preview) mode and 14px in output (display) mode. That has recently changed to be 16px and 16px. A week ago we also saw that text would get bigger or smaller depending on whether the page was full size or not - although this change appears to have been been reverted.

Static content macros should be unaffected though? Nope. We have recently seen that static content macros are now 14px in preview mode and 16px in display mode, making them look different to non-macro text. Code blocks are rendered differently depending on whether we are in static macro context or not. And the list goes on. Customers understandably expect their font sizes to be the same whether they are typing in a macro or not!

What do we want? Well for static macros, some effort on Atlassian’s side to make them look like the non-macro equivalent. Or at least regression testing.

And for dynamic macros, what we really, really need are published, updated Fabric stylesheets!

The current stylesheets are essentially obfuscated (I think via React), making attempts to reverse engineer them practically impossible.

If we were given a stylesheet we are aware that we might not be able to use it as-is (in part due to different markup caused by the legacy rendering engine), but it would be a huge help to proactively update our iframe styles.

Display mode:

Edit (Preview) mode:

6 Likes

Great post, thanks a lot for pointing this out in this manner @GeorgeSlater! This is actually a huge issue.

I hope Atlassian’s answer to this will not be along the lines of “Why don’t you just use Forge where this is handled for you?” which is of course dodging the problem at hand.

3 Likes

Excellent write up of our issues, @GeorgeSlater.

I’d like to add the following considerations as well:

  • Confluence page content stylesheets for Fabric and legacy pages should be hosted on a CDN for use in Connect iframes (we have asked for this multiple times before with no response)
  • The context of whether a dynamic content macro is being rendered in fabric or legacy pages should be available as URL context params and via the AP API – the correct CDN stylesheet URL to include could then be determined easily from these parameters
  • Static macro sfxml still doesn’t render using Fabric-friendly HTML, even when injected into a Fabric page, it’s as if it renders using the legacy page renderer
  • The same is true of the content body conversion REST API – it seems to only generate content compatible with the legacy page renderer

There seems to be virtually no consideration for how either static or dynamic macro content can match the styles of the parent page in the wide matrix of scenarios described above. Some attention to detail here would be greatly appreciated.

4 Likes