-
-
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
[RFC][Joy][Tabs] The default design of tabs is not the common we could expect #36782
Comments
Appreciate for the feedback! One of the core principle of Joy UI is unopionated in terms of design. We try to ship as less CSS as possible and leverage the global variant concept. I believe that Joy UI will bring great experience for customization, that's why I spend so much time adding common examples to ensure that customization is straightforward and I feel that the Tabs with an indicator should be a customized version of the current Tabs. Talking about the default design, I found a lot of popular examples that looks like toggle button group: |
I agree with @marcpachecog here. This is a component where Joy feels weirdly opinionated, and before the example was there it was honestly a pain in the a-- to overwrite the styling without breaking anything, especially for someone who wasn't yet familiar with Joy at the time. A tab design that has its own container will rarely work when someone wants to implement their own design language. The component also just looks... off(?), maybe because of the shadow of the individual tabs. Anyways, iOS's tabs don't look anything like this? The closest thing Apple's design guidelines have are Segmented Controls but they explicitly call that a button, not a tab. macOS does have this kind of design as its Tab View component, but that's not supported on iOS |
@Studio384 this is the iOS design (Tab views) I mentioned.
Really appreciate your feedback and it is true for me as well when I need Tabs that looks like the default of Material Design. I am afraid that if we change the default design of Tabs to look like Material, we will have the same issue when someone wants to customize the Tabs to look like iOS Segmented controls (that's the pain I have when I used Material UI). What we can do now is to remove the shadow from the Tab, then the customization should be easier by changing variants: <Tabs>
<TabList variant="plain">
<Tab variant="plain"> In the future, Joy UI will provide cc @danilo-leal |
I'd just like to point out that that control is very specifically not supposed to be used on iOS or any of its variants (as noted on that page). It's a macOS-only thing (and something Apple has been (slowly) moving away from). π
I see where this comes from, but I don't feel like just because it would have an underline would make it Material Design-ish. Fluent Design and various other design systems also use underlines for their tab controls and are in my opinion very distinct. I feel like these design systems differentiate more in how it animates and interacts (e.g. if MDs ripple effect is disabled, MUIs Tabs already feel like a very different design to me). Going with the current tab design just for the sake of "it shouldn't look to similar to Material's design" doesn't seem like a good argument to me. I'd say how a control looks should be decided in function of the components it appears next to, not in function of the components of another system. Not that that means underline-style tabs are the right decision or this segmented-style design is the wrong option to go with, just saying that it shouldn't be an argument for or against either. In the end, I don't really care what they look like and either style could look great. I just saw this issue and wanted to chime in to say that this current control indeed isn't that common and it felt a bit off compared to the rest of Joy, and that overwriting the styling of this component was a bit of a pain (for beginners), maybe it can be made a bit less complex/easier to customize without having to resort to throwing it all out and going with the unstyled variant. :) |
Thanks for the detailed feedback. I will take it into account on how to make it easy and flexible for customization. |
This is such an exciting issue β― thanks to both @marcpachecog & @Studio384 for chiming in and discussing it! I feel like, at the end of the day, Joy should optimize for what's most common out there, and the Tab look y'all have been suggesting is definitely, at least as far as I can see, the most common design there is. Even if you look outside of the realm of extensively documented design systems and start looking into tab usage across products, you'll see that's indeed the design: StripeVercelNotion@siriwatknp I feel like when it comes to the opinionated discussion we were having, this issue sheds light on it: the design tokens should be flexible but "avoiding to look like Material" is also not necessarily the end goal. Even with the same layout, different tokens can convey a different look and feel, and that can be good enough! So, in conclusion, I'd definitely make the default tabs, the ones you'd get out of the box, to be similar to the designs above. And every other component, too, as a principle: follow the most common layout out there and have other specific visuals as customization options (e.g. iOS tab views/group). π¬ |
@danilo-leal Alright, I have included this issue for the stable release! |
@marcpachecog Here is the preview of the revised Tabs https://deploy-preview-36843--material-ui.netlify.app/joy-ui/react-tabs/. in #36843 |
@siriwatknp Wow, it looks good! Great work :) I have some observations:
|
What's the problem? π€
When you think of a Tab component, your head will bring to you something like this:
But instead, the default design looks more like a ToggleButtonGroup component:
What are the requirements? β
No response
What are our options? π‘
No response
Proposed solution π’
Add a prop to select if you want the classic tab design or the toggle button group and let the classic one as the default.
Resources and benchmarks π
No response
The text was updated successfully, but these errors were encountered: