We use Confluence at work. It has the option to render HTML embedded in the page. I haven’t tried to render a whole file attached to a page, but there might be a way to do that.
I’ve used it a bit to add my own forms into pages to create little tools for people in docs.
In the past we used Jive, and I had a rather involved HTML paged embedded there. I had to be careful with my CSS, as using any generic attribute level CSS would break the platform. I hope Confluence has protections against that, but haven’t tested it, as I got in the habit of avoiding that issue all together.
Every new wiki / knowledge management system I always compare against Confluence. I get the advantage of keeping your content in plaintext for portability but when I look back on how many times I've actually ported wiki content it's... maybe once? Most systems these days are handily capable of this, in any case.
Anyway, Confluence for all its flaw has so much power, is so much more pleasant to use, your business folks won't balk at it. As often as not, we have people from all parts of the company in there, reading and writing both, and it needs to be usable to people of all technical levels. Markdown wikis and their editors don't often meet this criterion, or they're missing on some key features (tables!!).
To me, Confluence's only real down side is that it's an Atlassian product. I wish I could find something to scratch the itch without feeling the need to buy into that whole ecosystem.
> I get the advantage of keeping your content in plaintext for portability
Portability is secondary for me. For me, the primary reason for keeping content in plain text is disaster recovery.
When my systems are down, when my applications aren’t working, if my documentation is also inaccessible, this makes things a lot harder.
If my documentation is primarily in plain text / markdown, it’s really easy to be able to read those docs again, even when everything else has fallen over.
I’ve made some of my tools with this in mind, because they are for a team that has to keep functioning during a disaster recovery situation.
I stubbornly kept the main page as HTML. All libraries are download and sourced locally, instead of using a CDN. I use as little server side as possible, and just use basic PHP when I must. The idea being that in a worst case scenario the users can simply open the index.html on their desktop had have 95% of the functionality. If they run something like xampp, they can get 100%. This app is basically their map to the rest of the infrastructure, with some helper tools. They’d be lost if it went down when they needed it most. That said, it’s never come to this in 15 years and there have been several big DR events in that time. I still like having it as an option in my back pocket.
I recently handed it off to someone else to manage. I should probably share this part of my philosophy as it seems like they are trending toward adding complexity and dependencies, because they’re hip and cool.
I’ve used it a bit to add my own forms into pages to create little tools for people in docs.
In the past we used Jive, and I had a rather involved HTML paged embedded there. I had to be careful with my CSS, as using any generic attribute level CSS would break the platform. I hope Confluence has protections against that, but haven’t tested it, as I got in the habit of avoiding that issue all together.