The idea is that the condition tags, if you don't condition them out in the preset, make it into the output, and you can create a css selector to apply a background colour (or other formatting as you wish) to text with that condition tag. It is manual and won't tell your reviewers exactly how something has changed, but allows you to mark the text that has changed. In RH2019 when I tested the concept it survived into Responsive/Frameless and Word output, but I haven't checked in RH2020+.
There are a few parts to set up first.
1. Create a draft output preset so you can generate (and potentially publish) without affecting your production output.
2. Create a condition tag that you'll use to mark your changed text. You could potentially get creative and have multiple with different types of formatting (for deleted vs changed for example), but in my opinion that's too much work, so I only opted for a single one. e.g. Group: Review. Tag: Changes.
3. Create a draft stylesheet that imports your main stylesheet (so all the formatting will look right) and includes only the following style definition:
[data-condition="<GroupName>:<TagName>"] { <formatting> }
e.g.
@1552174 url('main.css'); /* this assumes both stylesheets are in the same folder otherwise include relative path */
[data-condition="Review:Changes"] {
background-color: pink;
}
(You might be able to skip the import bit as I think New UI allows multiple stylesheets now, but this was how I had my test project set up.)
4. Create a draft master page and select the draft css as the stylesheet.
(I think if you go the multiple stylesheet route, you attach your main stylesheet here too, if you haven't attached it to every topic individually. But you might have to test as I haven't tried this and am not quite certain it works how I think.)
5. Select the draft master page in your draft preset. This ensures your draft stylesheet is applied to every topic in the draft output. We don't want to attach to each topic individually as then the formatting would show in the production output.
As you edit the topics, you mark the changed text with the condition tag.
Or you could choose to duplicate paragraphs, and mark the new paragraph only, so your reviewers can compare the old and new text on the same page. If you go this route, I'd recommend also creating a condition expression that excludes the review tag, and apply that to your production output preset. That will ensure your draft content can't accidentally make it in to production.
When your draft content is approved, you can publish without doing anything if you chose to apply the condition tag just to the changed text, but I generally recommend removing the tags from your content, so everything is clean for the next review.
If you chose the duplicated paragraph method, then you'll need to go through and delete the old paragraph, so it makes sense to remove the review tag at the same time.
It sounds a bit daunting initially, but actually works quite smoothly once everything is set up and you're used to the workflow.
(I think I actually read this method from the Flare forums years ago, but it's only just become a workable option in New UI.)