• Resolved Seb

    (@sebastienrenaudeau)


    Hello,

    I’m using Glossary by CODEAT and I’ve run into a display issue with the tooltip.

    Description:
    The glossary tooltip is rendered with position: absolute. This works fine in most cases, but when the glossary term sits inside a container that has overflow: hidden the tooltip gets visually clipped by that container’s boundaries. Only the part of the tooltip that fits inside the parent’s box is visible; the rest is cut off.

    Best regards,
    Sébastien

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Author Daniele Scasciafratte

    (@mte90)

    Hi, I can confirm that is an issue that happens often with page builders and in our documentation we have some CSS workaround based by case but is not something that we can fix for everything by the plugin itself (because here are to many different bug reasons): https://docs.codeat.co/glossary/faq/#do-you-support-visual-composer

    Thread Starter Seb

    (@sebastienrenaudeau)

    Hi @mte90,

    Thanks for the quick reply and for the documentation link, I understand this is a common issue with page builders and that it’s not easy to fix for every possible layout.

    That said, I’d like to suggest a more structural approach: instead of relying on CSS overrides on a case-by-case basis (which requires identifying and patching every parent with overflow: hidden, and can’t cover all builder/theme combinations), would it be possible to render the tooltip element directly inside <body> rather than nesting it inside the glossary term’s container?

    This is the standard pattern used by most modern tooltip libraries (Tippy.js, Tooltipster, etc.): the tooltip markup is appended to the end of <body> when triggered, and its position is calculated with JS (via getBoundingClientRect() of the trigger term) rather than relying on position: absolute within the normal DOM flow. Since the tooltip would no longer be a descendant of the term’s container, it would automatically escape any overflow: hidden/auto on ancestor elements, regardless of the theme, builder, or layout used, without needing a specific CSS fix for each case.

    This would remove the need to document and maintain workarounds per builder, since the fix would apply universally at the plugin level.

    Would this be something you’d consider for a future version?

    Thanks again for your work on the plugin.

    Best regards,
    Sébastien

    Plugin Author Daniele Scasciafratte

    (@mte90)

    Hi Sebastien,
    sadly your solution is not something we can do.
    We edit the content of the page for SEO reasons as example but also because we parse the_content filter in WordPress so we can’t inject stuff outside that because it will breaks with everything around and creates more conflicts.
    We are not using JS libraries for tooltips but instead creating pure HTML so we can’t do what you are suggesting.

Viewing 3 replies - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.