-
Notifications
You must be signed in to change notification settings - Fork 832
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better recognition of touch devices #1653
Conversation
This pull request is being automatically deployed with ZEIT Now (learn more). 🔍 Inspect: https://zeit.co/mui-org/material-ui-pickers/ei6e89ngg |
Test summaryRun details
View run in Cypress Dashboard ➡️ This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
Codecov Report
@@ Coverage Diff @@
## next #1653 +/- ##
=======================================
Coverage 89.76% 89.77%
=======================================
Files 73 73
Lines 2315 2317 +2
Branches 402 420 +18
=======================================
+ Hits 2078 2080 +2
Misses 190 190
Partials 47 47
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder about a potential inconsistency this prop can bring. In the CSS we will use sm
, with no way to have it configured. Do we need to expose a desktopModeBreakpoint
prop? What if it was hard coded?
What do you mean by? For example somebody can decide to show the mobile picker for tablets
|
Ok, so we have two different concerns:
It seems that it's should be the touch vs mouse pointer support that should determine what version to display. Maybe we are no looking at the right media query. What if we were using |
@oliviertassinari really, it is the best way to recognize touch devices. It works really nice for our case. Thanks for this idea! 💪 |
Todo figure out visual regression |
Regarding the limitation with Samsung phones, here is it: mui/material-ui#15000. You can use BrowserStack to try that out. |
@oliviertassinari also I want to handle the case when the user is on desktop, but the window is small (e.g. iframes or just resized window) Maybe we can make a hook |
@dmtrKovalenko Given that we only have a use case, for now, in the date picker, I think that we should keep the solution scoped to the date picker. Once 1. we find a solution, 2. that we stress test with the users of the date picker, 3. that we see a need outside the date picker, then, yes, definitely, I think that it would make a great addition to the /core or /utils package. |
This approach seems to do it. const ResponsiveWrapper: React.FC<ResponsiveWrapperProps> = ({
- desktopModeMediaQuery = '(hover: hover)',
+ desktopModeMediaQuery = '@media (pointer: fine)',
okLabel,
cancelLabel,
clearLabel, I have included @media to ease pattern search in the repository (between JS and CSS) The global document listener approach would be challenging if we need to wait for a first pointer interaction: https://stackoverflow.com/questions/23885255/how-to-remove-ignore-hover-css-style-on-touch-devices |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome. I'm excited, I can't wait to try it out in real life (publish) and the implication for updating the styles for desktop #1648 :)
/** Css media query when `Mobile` mode will be changed to `Desktop` | ||
* @default "@media (pointer: fine)" | ||
* @example "@media (min-width: 720px)" or theme.breakpoints.up("sm") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think of this variation to better match the style of the mono-repository for the description of the props?
/** Css media query when `Mobile` mode will be changed to `Desktop` | |
* @default "@media (pointer: fine)" | |
* @example "@media (min-width: 720px)" or theme.breakpoints.up("sm") | |
/** | |
* CSS media query when "mobile" mode will be changed to "desktop". | |
* | |
* @default "@media (pointer: fine)" | |
* @example "@media (min-width: 720px)" or theme.breakpoints.up("sm") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mobile
and Desktop
are used as prefixes for specific components (e.g. MobileDatePicker
) so it should be more clear for users. Isn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mobile
and Desktop
are used as prefixes for specific components (e.g. MobileDatePicker
) so it should be more clear for users. Isn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using Mobile
feels like it's a piece of code that can be used on its own. What about 1. MobileDatePicker
or 2. "mobile", I think that we would lose value if we try to compromise between these two options.
*/ | ||
desktopModeBreakpoint?: Breakpoint; | ||
desktopModeMediaQuery?: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you considered a shorter name for the prop?
desktopModeMediaQuery?: string; | |
desktopMediaQuery?: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the shorter variant is less expressive. What "desktop" means?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could be interpreted as "a media query for desktop", definitely not as good as the information we can provide in a description. Adding mode definitely provide extra context. I don't know. I was wondering about this tradeoff of information vs length for the props, e.g. openPickerIcon
, vs pickerIcon
.
Are you sure about this one? Yes, it solves the issue on mobile, but what about desktop? |
Yeah, because it needs for desktop a11y. We need to render outline for the focused element. (This is a problem of trap focus actually😮) And it is not a problem for desktop, because we are not doing missclicks thanks to mouse. On desktop you will probably never see it if not navigating through the Tab. But on mobile it is appearing all the time. |
I have added an extra description on #1664 to describe what I have observed. |
@oliviertassinari sorry for bringing this up, but i'm confused. The documentation states: fine This means that this media query matches desktop, and not mobile devices. And at the same time the name of the constant is |
This PR closes #1649
Also closes #1664
Description
Use
media (pointer: fine)
(https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pointer) which is the best way to determine touch devices. So use it to render mobile wrapper and hide focus outline.