Tooltip position absolute vs fixed?

[EHackettTriCore]

Describe the Bug

The tooltips since their position is set to fixed they scroll on the page if you scroll after exposing them. This is coming from their position being set to fixed vs absolute.

Steps to Reproduce

Create a page with a tooltip that's taller than the browser window and scroll while tooltip is exposed.

Expected behavior

Tooltips location is relative to it's starting location

Screenshots

Environment

Please complete the following information:

• Device: Desktop
• OS: Mac
• Browser: Chrome
• Version: 71.0.3578.98

[100stacks]

Thanks @EHackettTriCore for submitting this issue!

Will provide any updates/feedback after discussing with the HelixUI team. 👍

[CITguy]

• Sadly, we have to use position: fixed; to work around issues that arise when positioned elements are nested within one another (e.g. Tooltip in a Popover, Popover in a Modal, etc.).
• Additionally, things get complicated when a positioned element has one or more scrolling ancestors. This complicates how we add collision detection in order to apply "smart" repositioning logic.
• Finally, position: absolute; on a positioned child within a scrollable container prevents the child from escaping the parent container (meaning that the parent container would clip visibility of the child). (See CodePen BvVzWd) This severely limits styling capabilities.

Recommendation

Please ensure that the <hx-div> elements are the only elements styled to scroll. Positioned elements listen for scroll events from the document in order to recalculate their fixed position. Because scroll events don't bubble, <hx-div> was added to encapsulate logic needed to retarget scroll events to the document level. The <hx-tabpanel> element was also updated to retarget scroll events.

[CITguy]

Looking at the markup in the gif, it looks like you may be using old syntax for tooltips, which is why the scroll event listener doesn't know what to track against when you scroll.

Helix tooltips used to allow interaction with its contents (such as links), but this was in violation of the promise that the ARIA "tooltip" role defines.

A contextual popup that displays a description for an element.
ARIA 1.1 "tooltip"

Tooltip content is supposed to be descriptive in nature, not interactive. As such, Helix tooltips were updated as a breaking change in v0.15.0-rc.0 to no longer have click-to-toggle behavior and instead focuses on describing an element. If you need to interact with elements within your tooltip, I would suggest using a Popover instead.

If your tooltip is purely descriptive, you'll need to update your markup. As of v0.15.0-rc.0, Tooltips are configured via their own for attribute (not via an <hx-disclosure>) to tell the tooltip which element it describes (and thus which element to listen for events). As a result of this change, you can use any element as a target, not just <hx-disclosure> like before.

before

<hx-disclosure aria-controls="my-tooltip">
  <hx-icon type="help-circle"></hx-icon>
</hx-disclosure>
<hx-tooltip id="my-tooltip">
  This is an old tooltip. (T_T)
</hx-tooltip>

after

<hx-icon id="help-icon" type="help-circle"></hx-icon>
<hx-tooltip for="help-icon" position="top-center">
  This is a new tooltip! (^_^)
</hx-tooltip>

[CITguy]

Closing. Result of confusion between the various v0.15 release candidates. Will address in the v0.15.0 release notes.