[Tooltip] The default offset of popper changes for different screen sizes.

[the5ereneRebe1]

The popper of the Tooltip have different offsets for different screen sizes, for screen size 375px and above the popper appears to be closer to the Tooltip child.

• The issue is present in the latest release.
• I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

The popper offset for screen size 375px and above is smaller that the offset for size 375px and below.

Expected Behavior 🤔

The popper offset for all screen size should remain the same.

Steps to Reproduce 🕹

Steps:

1. Visit https://t7hb4.csb.app/
2. Hover on the top right button on the header, and change the screen size.
3. The "change theme" tooltip is displayed below header for screen size 375px and below
4. It is displayed inside the header for screen size 376px and above.

Context 🔦

Your Environment 🌎

Tech	Version
Material-UI	v4.11.0
React	16.8.6
Browser	Chrome
TypeScript
etc.

[oliviertassinari]

@the5ereneRebe1 Thanks for the report. I can reproduce with v5. Yeah, we started to discuss this problem in: #23088 (comment) with @eps1lon. Maybe we should inverse the logic:

diff --git a/packages/material-ui/src/Tooltip/Tooltip.js b/packages/material-ui/src/Tooltip/Tooltip.js
index 9e967a2f1f..ce8887bf2b 100644
--- a/packages/material-ui/src/Tooltip/Tooltip.js
+++ b/packages/material-ui/src/Tooltip/Tooltip.js
@@ -75,11 +75,16 @@ export const styles = (theme) => ({
     borderRadius: theme.shape.borderRadius,
     color: theme.palette.common.white,
     fontFamily: theme.typography.fontFamily,
-    padding: '4px 8px',
-    fontSize: theme.typography.pxToRem(11),
     maxWidth: 300,
-    wordWrap: 'break-word',
-    fontWeight: theme.typography.fontWeightMedium,
+    padding: '8px 16px',
+    fontSize: theme.typography.pxToRem(14),
+    fontWeight: theme.typography.fontWeightRegular,
+    [theme.breakpoints.up('sm')]: {
+      padding: '4px 8px',
+      wordWrap: 'break-word',
+      fontSize: theme.typography.pxToRem(11),
+      fontWeight: theme.typography.fontWeightMedium,
+    }
   },
   /* Styles applied to the tooltip (label wrapper) element if `arrow={true}`. */
   tooltipArrow: {
@@ -105,42 +110,37 @@ export const styles = (theme) => ({
     },
   },
   /* Styles applied to the tooltip (label wrapper) element if the tooltip is opened by touch. */
-  touch: {
-    padding: '8px 16px',
-    fontSize: theme.typography.pxToRem(14),
-    lineHeight: `${round(16 / 14)}em`,
-    fontWeight: theme.typography.fontWeightRegular,
-  },
+  touch: {},
   /* Styles applied to the tooltip (label wrapper) element if `placement` contains "left". */
   tooltipPlacementLeft: {
     transformOrigin: 'right center',
-    marginRight: '24px',
-    [theme.breakpoints.up('sm')]: {
-      marginRight: '14px',
+    marginRight: '14px',
+    '&$touch': {
+      marginRight: '24px',
     },
   },
   /* Styles applied to the tooltip (label wrapper) element if `placement` contains "right". */
   tooltipPlacementRight: {
     transformOrigin: 'left center',
-    marginLeft: '24px',
-    [theme.breakpoints.up('sm')]: {
-      marginLeft: '14px',
+    marginLeft: '14px',
+    '&$touch': {
+      marginLeft: '24px',
     },
   },
   /* Styles applied to the tooltip (label wrapper) element if `placement` contains "top". */
   tooltipPlacementTop: {
     transformOrigin: 'center bottom',
-    marginBottom: '24px',
-    [theme.breakpoints.up('sm')]: {
-      marginBottom: '14px',
+    marginBottom: '14px',
+    '&$touch': {
+      marginBottom: '24px',
     },
   },
   /* Styles applied to the tooltip (label wrapper) element if `placement` contains "bottom". */
   tooltipPlacementBottom: {
     transformOrigin: 'center top',
-    marginTop: '24px',
-    [theme.breakpoints.up('sm')]: {
-      marginTop: '14px',
+    marginTop: '14px',
+    '&$touch': {
+      marginTop: '24px',
     },
   },
 });

[eps1lon]

I generally do not understand why the logic should change on touch screens. From personal experierence increasing size/offset does not change the potential problem hiding the tooltip. It assumes a pretty unnatural handling of touch devices. I don't think we established resources/research into this problem. Seems to be we're better off removing the logic until we have a good understanding of the problem for implementation and documentation.

[oliviertassinari]

the logic should change

Which visual change are you referring to and under which condition?

Do you agree that the proposed change is moving in the right direction? Moving the visual change of the tooltip from mouse vs touch pointer usage to screen width only?

[eps1lon]

I generally do not understand why the logic should change on touch screens.

Which visual change are you referring to and under which condition?

Any placement/size logic for the tooltip depending on screen size.

Do you agree that the proposed change is moving in the right direction?

No, it should be removed since there is no research into whether this logic does anything. I could not verify the rationale you provided.

[oliviertassinari]

it should be removed

@eps1lon What should be removed, the increase of font size? The change of the relative position between the anchor and the tooltip?

The current logic & UI display is inferred from https://material.io/components/tooltips and how Google implements the tooltip in its product (desktop & mobile). We could definitely put it under more scrutiny.

[the5ereneRebe1]

@eps1lon @oliviertassinari the difference in the relative position does not make any sense , maybe we should let a developer decide how much spacing he wants and add a attribute on Tooltip component to configure the spacing.

[oliviertassinari]

the difference in the relative position does not make any sense

@the5ereneRebe1 The difference is meant to leave space for a finger on touch interaction. You will find it in Google's product and Material Design spec.

[oliviertassinari]

I'm adding the "good first issue", looking closer, I believe the changes are going in the right direction, we increase the UI for the tooltip on smaller screens and leave more space for fingers (can happen on a large desktop screen). We match what has been done at scale by Google.

[hmaddisb]

hi, can I work on this? and just so I understand it correctly, it is decided that we should move on with the changes suggested in #23363 (comment) ?

[the5ereneRebe1]

@oliviertassinari I understand that but I had a use case where I had to make the relative position between the anchor and tooltip close to 0 and changing the popper offset value with reference to mobile view was causing an overlap on normal screen sizes, I solved this issue by detecting different screen sizes and applying different offset values. Is there an elegant way to handle this use-case.

[eps1lon]

You will find it in Google's product and Material Design spec.

Could you share some resources for that?

[oliviertassinari]

Could you share some resources for that?

@eps1lon Sure, I could gather the following.

Layout

Layout on large screens

• 

https://material.io/components/tooltips#specs

• 

https://mail.google.com/

Layout on small screens

• 

https://material.io/components/tooltips#specs

• 

On Android Google Agenda, Google Keep, Gmail

Gap

Gap on a fine pointer

The gap is around 10 to 14px.

• 

https://material.io/components/tooltips#specs

• 

https://material.io/components/tooltips#specs

Gap on a coarse pointer

The gap is around 30px.

• 

On Android Google Agenda, Google Keep, Gmail

[eps1lon]

I don't think change the layout depending on device in the Button? Shouldn't this be a separate discussion?

I can't find mentions of gap depending on pointer size in https://material.io/components/tooltips#specs

[oliviertassinari]

I don't think change the layout depending on device in the Button?

What do you mean?

I can't find mentions of gap depending on pointer size in https://material.io/components/tooltips#specs

Yeah, the new specs are worse than the initial ones. You can find this better describe in https://material.io/archive/guidelines/components/tooltips.html#tooltips-tooltips-desktop ("Top margin", "Touch UI" vs "Keyboard" vs "Cursor").

In the current one, you would need to measure the distance in px in the demos. In any case, we can reliably observe the difference on Google's product.

[eps1lon]

I don't think change the layout depending on device in the Button?

What do you mean?

The mockup is just so misleading. I thought this was the button. The archived version makes it more obvious, thanks 👍

However, it's not clear to me if the dimensions of the tooltip change because of the interaction modality or because of screen size. I have fairly big hands and think I hold a phone like most people. The dimension changes don't do anything for me. You would have to hold your finger exactly vertically. Seems to me this is just motivated by screen size.

[oliviertassinari]

it's not clear to me if the dimensions of the tooltip change because of the interaction modality or because of screen size

Agree, this part is open to interpretation. Considering that laptop screens can be touch interactive or even tablets, I find that basing the margin-top based on the touch and not the screen width would work better.

You would have to hold your finger exactly vertically

Yeah, I guess it's why tooltips on mobile are rarely used 😁. I think if the margin-top doesn't change, it's completely unusable, if it changes, it's almost Ok-ish but not great.

[oliviertassinari]

Another bug the proposed changes in #23363 (comment) fixes (the first one is the margin-top that depends on the screen width). See the actual look of the tooltip on an iPad when open programmatically:

vs the expected:

[eps1lon]

I think if the margin-top doesn't change, it's completely unusable, if it changes, it's almost Ok-ish but not great.

I've tested this. The margin change is way too small to make any difference. This spec sounds like it wasn't derived from actual user testing but purely theoretical conjecture.

[oliviertassinari]

The margin change is way too small to make any difference.

I almost agree. I have smaller than average fingers for a man, closer to what you could expect for an average woman. For me, it's almost OK but the margin could be increased. Google's Android applications have a wider gap. It seems that Flutter has the same issue flutter/flutter#25478.

[marianayap]

Hello! I'm interested in this issue and I'll like to know if is already taken to see the chance of taking it.
Thank you! I'll wait for the answer @oliviertassinari @the5ereneRebe1

[oliviertassinari]

@marianayap Thanks for the interest, the "first good issue" was added because #23363 (comment) seemed to be a straightforward solution.

However, @eps1lon challenged it in #23453. As for as I understand the situation, this comment summarizes the options and tradeoff: #23453 (comment).
I'm personally in favor of moving forward with the initial change proposed and option 3. to minimize the frequency and importance of the downsides (my hypotheses). We need to resolve the dilemma first.

[marianayap]

Hello @oliviertassinari, I review the dilemma and I don't know if I could aport more in the issue, but I definitely will love to try it or work in another one

[oliviertassinari]

@marianayap Ok sounds fair. For others, I think that we can apply #23453 (comment) as a first approximation. It's definitely an improvement compared to what we have now.

Then regarding the dilemma, I would personally prefer waiting for the Concurrent Mode issue to surface before considering it. If we could have a reproduction, to make it more tangible, that would be great, but even then, we could call it an "acceptable approximation" => YOLO.