[Tooltip] Use media queries for applying "mobile styles"

[eps1lon]

Replaces .touch class with @media (pointer: coarse) .MuiTooltip-tooltip.

Instead of applying the mobile styles depending on the input modality we apply them by the pointer granularity. That way we use less JS and are sure we don't have any CM problems (reading from a ref during render should be safe here but not trivial to determine).

caniuse data

[mui-pr-bot]

Details of bundle changes

Generated by 🚫 dangerJS against 626b3e8

[oliviertassinari]

The original incentive for not using @media (pointer) is that per the specification this accounts for the primary pointing device. You can have a Windows Surface 3 with a fine pointer that has the primary input device (a mouse) but also use the touch device when you want to use it as a tablet as a secondary pointing device. So IMHO, it's a step backward. I don't understand why. What's wrong with the current logic? I have noticed that you have tried to remove this part in a couple of iterations.

[eps1lon]

So any-pointer would be fine in your opinion? Just trying to figure what problem you're trying to solve.

[eps1lon]

I don't understand why. What's wrong with the current logic?

What part of the PR description is unclear to you?

[oliviertassinari]

From my perspective:

• the margin-top should be based on the object that hovers the anchor of the tooltip. mouse vs finger vs stylus, etc.
• the "density" of the tooltip should be screen width based, not pointer-based.
• [Tooltip] The default offset of popper changes for different screen sizes. #23363 (comment) is going in the right direction

reading from a ref during render should be safe here but not trivial to determine

So there are no issues (safe)?

[eps1lon]

the margin-top should be based on the object that hovers the anchor of the tooltip. mouse vs finger vs stylus, etc.

So the current approach is already not correct in your opinion. That's a good starting point. Since neither the current nor the media query approach are perfect we should go with the CSS solution since that has less overhead.

So there are no issues (safe)?

No, it's unclear. Since reading from a ref during render is generally unsafe and we have an alternate, concurrent safe, CSS approach we should use that instead of trying to figure out if an unsafe pattern is safe.

If we use JS we need a rationale for it and I haven't seen one.

[oliviertassinari]

If we use JS we need a rationale for it and I haven't seen one.

The rationale I see is that: CSS has no primitives that allow us to know if action comes from a mouse or a touch. We can work around it with JS. It seems that we have to find the least worse option. The drawbacks of each option:

1. width media query (before): It doesn't work with tablets and desktop with touch screens (I have no idea what happens with a stylus).
2. pointer media query (PR): It only accounts for the primary pointer. It fails when the user uses a secondary pointer, or when the primary pointer is not the actually most frequently used on the device.
3. JS touch logic (HEAD): the UI can be wrong (mouse gap instead of touch gap) in some edge cases with CM. I can also reproduce without CM in some cases. Maybe could solve it with a React state?

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/mui-org/material-ui/gqwbxgzy7
✅ Preview: https://material-ui-git-feat-tooltipdimensions.mui-org.vercel.app

[eps1lon]

This is definitely incorrect implementation and doesn't even implement the expected behavior in all cases. But considering that it seems like it's more important to use the original implementation, I'm not going to argue further. It's impossible to argue against "the initial implementation is correct" sentiment.

[oliviertassinari]

I think that it's a dilemma, I have seen 3 options #23453 (comment) with each its own drawback.

For the next step, we could wait for a developer to open an issue, and discuss it further at this point? For instance, maybe we could move from reading a ref in the render to reading a React state.