I can’t see that link you posted so I can’t check your markup, but TipTap is a bit more strict with it’s markup than TinyMCE, so it could be there is something in there it does not like which the browser is more relaxed about.
If you can post your table markup from TipTap that would help diagnose.
That fixed height: 223px is too short for 8 rows. Browsers treat table height as a minimum and just expand to fit, so it looks fine on the published site - but TipTap takes it more literally and squashes the rows down, which is what’s causing the overlap in the editor.
Remove the height off the style (leave the width, or remove the inline style altogether) and re-save and see if that resolves it.
Thanks. I hadn’t noticed the height there. That did resolve it (although not immediately: I had to save the change, then move off the node and onto a different one to force the RTE to update).
This leads to another question: why did it put a height on there in the first place, especially one that’s too small?
Edit: I can confirm that every affected page has the height specified. I’m going through and removing them all. Let’s see whether they turn up again at some point.
I’m not a content editor so I can’t say where the HTML came from. You made me wonder whether it might have been copy/pasted from Word, but I’ve tested that and it doesn’t add a height, and does add a “MsoTableGrid” class that isn’t present in the affected pages.
The site was upgraded through a few versions (from memory it was 8 → 10 → 13 → 17) so I wonder whether the upgrade process might have done something.
Creating a new table directly via the UI doesn’t appear to add a height attribute.
I guess at this point I’ll put it down to an upgrade bug, and will wait and see whether it happens again.
Hello!
My client recently reported similar issue, with 3 tables overlapping on each other.
After removing the tables, or moving them down, the text that used to be below them, starts to overlap with the first table. Unfortunately i’m unable to provide the screenshots.
We were unable to reproduce the issue at our test environment, so our bet i had to happen after recent migration from Umbraco 13 to 17.