Replies: 3 comments
-
Thanks for the request. At this time, we'd prefer not to expose all (or most) of popup's properties to dependent components. It makes the API more confusing for users and it adds to our maintenance burden, since we have to support it indefinitely. If possible, I'd like to see a use case showing the problematic behavior so we can address it within the tooltip. Do you have a test case we can use to reproduce it? Thanks! |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
@claviska Thanks for the feedback. I created a pen to demonstrate the behavior: https://codepen.io/Dimitri-Goethals/pen/ExGzMRP Note that we are developing a web component which is integrated in layouts which are out of our control. So working with translation offset is not a proper solution I guess. It needs to work with dynamic surroundings. For this example I slimmed down the DOM tree a little bit based on the exact situation. Our component starts at the When you go to full-screen mode for our component, you will notice that position of the tooltips is off: I also included a fix by pressing the [Apply fix] button. It's a slimmed down version of what we implemented at the moment. This fix sets the shift properties of the underlying popup. |
Beta Was this translation helpful? Give feedback.
-
It would be helpful to expose shift, shiftBounday and shiftPadding in the Tooltip component. These properties exist on the underlying Popup component (see Popup - Properties), but are not exposed on the Tooltip.
We are currently facing an issue where we want the change the shift boundary, due to misplacement of the tooltips in certain scenario's (e.g. full-screen). Exposing properties to set these would be a clean solution.
We are currently accessing the encapsulated popup component, which is not without risks, since not part of the public API.
Beta Was this translation helpful? Give feedback.
All reactions