Arrow position's incorrect with custom tooltip size #2253

Activity

1. RobbieTheWagner commented on Mar 1, 2023

   

   RobbieTheWagner

   on Mar 1, 2023

   Member

   More actions

   @anonimitoraf yes, I think that should work okay for setting the width. Is there a problem with it?
2. RobbieTheWagner

   added

   question

   on Mar 1, 2023
3. anonimitoraf commented on Mar 1, 2023

   

   anonimitoraf

   on Mar 1, 2023

   Last edited by anonimitoraf

   Author

   More actions

   I see, so the problem is the arrow, instead of pointing to the tooltip target, is shifted all the way to the right
4. chuckcarpenter commented on Jun 28, 2024

   

   chuckcarpenter

   on Jun 28, 2024

   Member

   More actions

   @anonimitoraf you would also need to adjust it's attachment placement. I wonder if this was using something like 'bottom-end'?
5. chuckcarpenter commented on Aug 13, 2026

   

   chuckcarpenter

   on Aug 13, 2026

   Member

   More actions

   Short answer to your actual question: yes, styling .shepherd-element is a reasonable way to set the tooltip width — that part matches what @RobbieTheWagner said above. Sorry we let the arrow half of this sit; @chuckcarpenter asked you a follow-up in 2024 and we never circled back.

   I haven't been able to reproduce your screenshots, so everything below comes from reading the current positioning code (15.2.3), not from a repro.

   How the arrow gets placed. Floating UI's arrow() middleware offsets the arrow toward the center of your target, but clamps it inside the tooltip — it can never leave the tooltip box. When the tooltip is much wider than the target and shift() has pulled the tooltip sideways to keep it on screen, the target's center can end up at or past the tooltip's edge, and the arrow parks at that edge. That's consistent with what your screenshots show, but I can't confirm it's what actually happened without your markup.

   One thing that makes that case look worse than it needs to: in shepherd.js/src/utils/floating-ui.ts the arrow middleware is created with padding: hasEdgeAlignment ? arrowOptions.padding : 0, and hasEdgeAlignment is true only for -start/-end placements. So on a plain bottom, the padding is forced to 0 and the arrow can sit flush against the tooltip's rounded corner (the element ships border-radius: 5px). That's only a few pixels either way — it doesn't cause the displacement, it just makes it uglier.

   Which placement were you using? @chuckcarpenter's question about bottom-end is still the useful one, because the behavior genuinely differs. On an aligned placement the arrow.padding option does take effect:

   tour.addStep({
     attachTo: { element: '.my-target', on: 'bottom-start' },
     arrow: { padding: 12 },
     text: '…'
   });

   To be clear about what that does and doesn't do: it changes how the tooltip aligns to the target, and it keeps the arrow 12px clear of the corners. It does not make the arrow reach a target that sits outside the tooltip's horizontal span — nothing can, since the arrow is a child of the tooltip.

   On max-width: 60%, two things worth double-checking:

   • .shepherd-element already ships width: 100%; max-width: 400px. Your rule has the same specificity, so which one wins comes down to stylesheet order.
   • The step element is appended to stepsContainer || document.body and positioned absolute, so the % resolves against its containing block: the nearest positioned ancestor, or the viewport-sized initial containing block if there isn't one. With the default document.body and no positioned ancestor that's effectively viewport-relative already — but if you pass a stepsContainer, or have a positioned ancestor, you'll get a different number than you expect. 60vw sidesteps the question entirely.

   One caveat if you're tempted to use custom middleware as a workaround: there's a known ordering bug (#3034) where user-supplied floatingUIOptions.middleware runs after arrow() and leaves the arrow data stale. A fix is open in #3477 but hasn't merged yet. It doesn't affect your CSS-only case.

   I'm going to close this as stale / no-repro on 15.2.3 rather than as fixed — the diagnosis above is inferred from the code, not verified against your app, and I'd rather not claim otherwise. If it's still happening, just comment here with a live example (StackBlitz/CodePen) and the placement you're using and we'll reopen and dig in properly. Apologies again for the long silence.
6. chuckcarpenter

   closed this as completedon Aug 13, 2026