Auto tooltip position

[blm768]

Fixes #105

Basic testbench is here.

Proposed Changes

• Tooltips' position prop now accepts the value "auto".
• Auto tooltip positioning picks the side that maximizes how much of the tooltip is visible onscreen.
• To break ties, auto positioning favors the default tooltip position.

Open Questions

• This solution assumes an arrow size of zero rather pulling the value from CSS.
  • Is that good enough given that the arrow size is generally small?
• Should we add a small margin around the edge of the viewport so the tooltip doesn't run right up against it?
• Should auto be the default value for the position prop?

To Do

• [x] Test on mobile browsers; they handle viewports differently when zooming.
• [ ] Backport to Vue 2

[jtommy]

I'll review soon in order to answer to all open questions.

[netlify[bot]]

❌ Deploy Preview for oruga-documentation-preview failed.

Name	Link
🔨 Latest commit	cfdcc8ab98c9adfb7639fd7ade53a6cce815d215
🔍 Latest deploy log	https://app.netlify.com/sites/oruga-documentation-preview/deploys/633377ca4b7af4000831d3ac

[codecov[bot]]

Codecov Report

Base: 66.49% // Head: 65.99% // Decreases project coverage by -0.49% :warning:

Coverage data is based on head (f3ee632) compared to base (159201e). Patch coverage: 13.95% of modified lines in pull request are covered.

:exclamation: Current head f3ee632 differs from pull request most recent head cfdcc8a. Consider uploading reports for the commit cfdcc8a to get more accurate results

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #372      +/-   ##
===========================================
- Coverage    66.49%   65.99%   -0.50%     
===========================================
  Files           61       61              
  Lines         4396     4438      +42     
  Branches      1162     1170       +8     
===========================================
+ Hits          2923     2929       +6     
- Misses        1372     1408      +36     
  Partials       101      101              

Impacted Files	Coverage Δ
packages/oruga/src/components/tooltip/Tooltip.vue	21.91% <13.95%> (-3.09%)	:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

[blm768]

Any thoughts on the open questions? I'm still interested in getting this merged if it'll add value.

[jtommy]

You are completely right, after the new release I'll give a try

[jtommy]

This solution assumes an arrow size of zero rather pulling the value from CSS. Is that good enough given that the arrow size is generally small?

Yes, I think it's right... if anything we can add a prop to customize it (low priority)

Should we add a small margin around the edge of the viewport so the tooltip doesn't run right up against it?

Can you make an example?

Should auto be the default value for the position prop?

Probably in the next breaking release

@blm768 good job 👍, are you able to support the Vue 2 version too?

[blm768]

Should we add a small margin around the edge of the viewport so the tooltip doesn't run right up against it?

Can you make an example?

Right now, we let the tooltip use its preferred position as long as it doesn't extend outside the viewport. In the first example in the image below, the tooltip is fully within the viewport, but it does run into the edge, so if it had a drop shadow, the shadow might be cut off by the viewport edge. If we consider that enough of a problem that we should do something about it, we could switch to an alternate position (shown here in gray) when the tooltip gets within, say, 5 pixels of the edge rather than at the point it actually crosses the edge.

Are you able to support the Vue 2 version too?

Yep. I'm starting on that right now.

[blm768]

OK, I've put in the Vue 2 changes, and those seem to be working as expected. I also made a small change to how we compute the isWebKit flag so we can compensate for Edge's misbehavior.

[blm768]

I've also made the commit messages a little more descriptive.

[blm768]

OK, fixups are squashed in.

[jtommy]

@blm768 thanks a lot! I'll add an example in the docs-next too

[jtommy]

@blm768 do you think we might use the same approach on dropdown? It might be really helpful to add that feature to it and components that use it (datepicker, etc)

[blm768]

Do you think we might use the same approach on dropdown?

I haven't looked too closely at the source yet, but I imagine it'd be possible to generalize this to work pretty much the same way with dropdowns. Depending on how we want them to behave, we might use different rules for repositioning them, and we might need to make more effort to handle long dropdowns (e.g. scroll to bring them onscreen, test cases where they're simply too long to fit onscreen) than we would for long tooltips just because dropdowns tend to run longer overall. At the very least, the check for whether the element is offscreen should be basically the same for both kinds of controls.