-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
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
[SwitchBase] Ignore focus and blur events #18303
Conversation
Details of bundle changes.Comparing: e0dd45f...7f846b2
|
@rbrishabh Could we look for a solution that doesn't involve a new API? |
Okay sure. I will look into it! |
Thanks |
2ca1643
to
64d8b0a
Compare
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 have proposed a different approach in the last commit. Let me know what you think about it.
64d8b0a
to
7f846b2
Compare
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.
Why is this marked as ready to ship? I offered an alternative explanation of the issue in #18210 (comment). Please address this (is the explanation not correct?) before merging this PR
The label was meant to trigger this potential concern :). I thought #18210 (comment) was not directly related to this pull request as the behavior can be reproduced in codesandbox. What do you recommend here? |
I couldn't find a codesandbox. I guess you mean the demo in a codesandbox. This issue is fundamental to anything that moves focus on mouseup. This approach is not correct (obvious from the test that needs to be removed). I don't think we should change something in the SwitchBase. The focus styling on the FormControl is there to, well, signal focus-within. If I mousedown then focus is removed which means the FormControl should no longer display that it has focus-within. If we actually want to prevent blur on mousedown then the platform has a built-in solution with |
Yes, you are exact. I meant that we can open the docs demo in codesandbox and reproduce the issue.
I think that we should challenge the existence of this signal in the first place. I have been keen, for a long time, to explore if we shouldn't remove it, this is a good opportunity to explore it. I doubt that the form label should signal should be present because it's not a common pattern. It feels like a distraction. |
We can schedule this for v5, sure. It's not a good oppurtinity to explore this now. And then it would require, as you said, exploring this first: Is a :focus-within polyfill needed in core? What do the guidelines say about form groups etc. |
I couldn't benchmark a single design system that handles the focus (no matter the modality). For instance:
We can observe the same on Google products, e.g. Calendar: |
I could find a design system that handles the focus state:
Ok, let's move this to v5 |
@rbrishabh Thanks for raising, we would recommend customizing the focus and not focused state at the same time. |
@oliviertassinari @eps1lon Thanks! |
Fixes #18210
Hey @oliviertassinari!
The very first attempt to solve the issue. I just added a noFocus option that can be passed as a prop to Form Label Component. But it is still not a default for checkboxes, radios or switches.
Is this the correct way to go about this?
Thanks!