Word export fails with `<table>` inside `<li>` and forces ugly workaround

Templates
,
1

Hi,

We’ve encountered an issue where placing a <table> inside a numbered list item (<li>) causes the Word export to fail. More specifically, the resulting Word document is flagged as corrupt or broken. This happens even though the HTML is perfectly valid according to the spec — a <table> is allowed inside a <li>.

Example:


1. The meeting decides...

{% newline %}

<table>...</table>

Generates:


<ol>

<li>The meeting decides...

<table>...</table>

</li>

</ol>

While this renders fine in browsers and is valid HTML, it seems the Silverfin Word export pipeline doesn’t support this structure. This leads to broken documents.

To work around this, I had to:

  • Stop using <ol> and <li> entirely.
  • Use a custom counter in Liquid.
  • Render numbers manually using 1), 2), etc., instead of 1. to prevent it from being interpreted as a list again.
  • Increment the counter manually after every item.

This workaround:

  • Makes the code more verbose.
  • Reduces readability.
  • Is more error-prone, especially with optional conditions.
  • Feels like a regression from using semantically correct and clean HTML.

Would it be possible to fix this limitation in the Word export? I understand that there might be edge cases with certain converters, but ideally, the platform could support valid HTML constructs — or maybe provide a cleaner fallback mechanism.

Thanks in advance!

Best regards,

Takis

2

Hi @Panagiotis_Issaris ,

Thank you for your detailed question and analysis!

Indeed, even though HTML supports tables in list elements, for some reason our Word download doesn’t allow this. However, I’m afraid to say that we are deprecating Permanent texts and download as Word feature in general. This means that we are supporting it for existing usage, but we won’t do any updates to it anymore.

Moreover, the download as Word feature has been added using an open-source solution, so even if we wanted to investigate and fix this it would be hard as it is not our codebase.

Finally, we did notice that any other text editor apart from Word does manage to open the .docx file. This might also serve as a workaround instead of complicating the Liquid code.

We could perhaps help you out with alternative solutions, based on the small code snippet I assume this concerns some kind of general meeting template? We could have a look in our codebase how we manage this in similar use-cases. For that I’ll need a little bit more info of what you are actually doing or a larger code snippet.

Thank you!

Kind regards,
Robin

3

Thanks for your clear reply!

I had also tried opening the .docx file in LibreOffice and Apple Pages — and while they do open it without flagging it as corrupt, the layout ends up being broken (e.g. letters shown one per line in some paragraphs). So unfortunately, suggesting an alternative editor isn’t really something I can propose to my customer. They’re a larger company, and as a freelancer/external developer, getting them to change their default word processor isn’t realistic.

As for the open-source tool being outside your codebase — I totally understand that this makes things trickier to change. That said, I’d almost say the fact that it’s open-source is a plus in this case :sweat_smile: If it had been closed-source, it’d be a dead end — but with open code, there might still be room for a small workaround or patch if the issue is easy to isolate =)

In the meantime, I’ve replaced the <ol>/<li> with a manual counter in Liquid to avoid breaking the export. That does work, but it’s definitely more verbose, harder to read, and more error-prone — especially when some items are conditional.

If you have a similar internal example or a different approach to achieve this, I’d be happy to share a bigger snippet or some context.

With friendly regards,
Takis

4

Hi @Panagiotis_Issaris ,

Thanks for the feedback.

So I have quickly checked how we handle similar situations in our codebase and indeed the counter in Liquid seems like the most common solution.

Moreover, I also noticed we didn’t specifically document <ol> and <li> as supported HTML attributes in our documentation, this issue being one of the reasons. They do work but not in all cases.

Hence, as a conclusion, doing a manual counter seems like the only possible solution right now. I will add it to our backlog of features we can look into, but I can’t make any promises for improvements in that respect soon.

Have a nice weekend!

Kind regards,
Robin