QVAC-19134 Frontend bug: infographic doesnt render correctly in Safari browser#2119
Merged
Conversation
Preview deployments for qvac-docs-staging ⚡️
Commit: Deployment ID: Static site name: |
Contributor
Tier-based Approval Status |
NamelsKing
approved these changes
May 19, 2026
Contributor
Author
|
/review |
Proletter
pushed a commit
that referenced
this pull request
May 24, 2026
…i browser (#2119) * doc: infographic - bug rendering in Safari browser * doc: infographic - bug rendering in Safari browser
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What problem does this PR solve?
The
Featuresinfographic on the docs home page (features-infographic.tsx) rendered correctly in Chrome but was broken in WebKit-based browsers (Safari/Epiphany):getBoundingClientRect()was correct; only the paint was wrong).Root cause: WebKit mis-paints HTML content inside
<foreignObject>when either (a) the<foreignObject>is significantly larger than its content, or (b) the inner HTML relies onposition: absoluteagainst an explicitly-sized wrapper. The original implementation used both patterns to give tooltips room to render outside the icon's bounding box, and to anchor them withbottom: calc(50% + 48px).How does it solve it?
Rather than fight the WebKit bug, the component is refactored to avoid the conditions that trigger it, while preserving the exact visual and interaction behavior the Chrome version had.
<circle>+ nested Tabler<svg>) and its hit-zone (transparent<circle>slightly larger than the icon) are now native SVG elements. No<foreignObject>involved for the icons themselves, so the bug cannot trigger.stroke="none". Without this, transparent hit-zone circles inheritstroke="currentColor"from the parent<svg>and paint a visible outline on top of every icon.<foreignObject>, but tightly sized and using natural flow. Each tooltip lives in its own conditionally-rendered<foreignObject>sized to fit the content (like the feature cards, which always rendered correctly). No moreposition: absolute; the platform tooltip uses flexbox (justify-content: flex-end) to pin to the bottom of its<foreignObject>, which is then positioned 8 SVG units above the icon — visually identical to the originalbottom: calc(50% + 48px).group-hover:ring-1halo on the inner dashed ring is reproduced as a sibling<circle>atR_INNERwhose stroke transitions betweentransparentandcurrentColoron hover.group-hoverbridge (which depended on DOM ancestry that no longer exists after the SVG split) and prevents the tooltip from unmounting while the cursor crosses the small gap between icon and tooltip.Verified visually in Chrome and Epiphany (WebKit); behavior is now identical in both.