SfButtonGroup Doesn't Wrap (Mobile)
I have an SfButtonGroup which works wonderfully and as expected. Good work out there. 😃👍 However, there is a problem with the text wrap in mobile:
Is there a way to make the buttons wrap/scroll? Thank you for any assistance you can provide.
Thank you for any assistance you can provide.
Hi Mike-E
Thank you for reaching out to us.
You can achieve the desired responsive behavior in the SfButtonGroup component by using either wrapping, horizontal scrolling, or a hybrid approach that adapts based on screen size. Below are the different implementation options:
Wrap Buttons on Mobile
Apply a custom class to allow buttons to wrap within the container:
|
<SfButtonGroup CssClass="custom-wrap"> <ButtonGroupButton>😃 Digital</ButtonGroupButton> <ButtonGroupButton>🧠 Generated</ButtonGroupButton> <ButtonGroupButton>🎨 Traditional</ButtonGroupButton> </SfButtonGroup>
.e-btn-group.custom-wrap { flex-wrap: wrap !important; justify-content: flex-start; }
|
Horizontal Scroll on Mobile
If wrapping is not preferred, you can make the button group scrollable:
|
<div style="overflow-x: auto; width: 100%;"> <SfButtonGroup CssClass="custom-scroll"> <ButtonGroupButton>😃 Digital</ButtonGroupButton> <ButtonGroupButton>🧠 Generated</ButtonGroupButton> <ButtonGroupButton>🎨 Traditional</ButtonGroupButton> </SfButtonGroup> </div> <style> .e-btn-group.custom-scroll { overflow-x: auto; flex-wrap: nowrap !important; white-space: nowrap; -webkit-overflow-scrolling: touch; } .e-btn-group.custom-scroll .e-btn { display: inline-block; min-width: max-content; } </style> |
Responsive with Media Queries (Hybrid)
Combine both wrapping and scrolling using media queries for a fully responsive solution:
|
<SfButtonGroup CssClass="responsive-group"> <ButtonGroupButton>😃 Digital</ButtonGroupButton> <ButtonGroupButton>🧠 Generated</ButtonGroupButton> <ButtonGroupButton>🎨 Traditional</ButtonGroupButton> </SfButtonGroup>
<style> .e-btn-group.responsive-group { flex-wrap: wrap !important; justify-content: flex-start; } @media (max-width: 768px) { .e-btn-group.responsive-group { overflow-x: auto; flex-wrap: nowrap !important; white-space: nowrap; } }
</style> |
These approaches ensure that the SfButtonGroup adapts well across screen sizes, providing consistent and accessible experience on mobile devices.
Regards,
Saranya D
Hi @Saranya, thank you so much for this. It is appreciated. As I understand it, the SfTab component has an OverflowMode to handle these scenarios, correct? Is there a reason why SfButtonGroup does not have the same?
Thank you for your continued assistance.
Hi @Sarayana,
Are there plans to make your controls more consistent with their APIs? I hope you can understand the concern.
Thank you,
Michael
HI @Sarayana, thank you for any update you can provide.
Thank you,
Michael
Hi Michael ,
The ButtonGroup component is designed as a lightweight wrapper to group related buttons with minimal layout. Unlike components such as Tab, which include properties to manage responsiveness and content overflow, the ButtonGroup does not currently have such a built-in mechanism.
This is by design, as the layout behavior for button groups is intended to be handled using standard CSS approaches. This allows developers to implement wrapping, scrolling, or other responsive behaviors based on their specific requirements. Furthermore , We have also discussed this scenario with our internal teams to explore the possibility of handling such cases more effectively through built-in options in the future.
Regards,
Mallesh
Hi Mallesh,
Thank you very much for your detailed explanation and for providing some context. I understand the control is by design, and I am pointing out that the design is inconsistent across controls. I also appreciate that some controls are wrappers and others are components, but to me, as a user, I do not care -- or am not aware of this distinction until you point it out -- I simply want to use all controls the same and have them feature the same consistency. This is especially so since one provides excellent behavior with a simple property assignment.
Thank you for your continued consideration in this matter, and for all your efforts out there. If you can, please create a feedback/vote to track so that others can provide their further input to improve your controls.
Hi Mike,
Upon further review, we would like to clarify the differences in behavior between the SfTab and SfButtonGroup components.
The SfTab component includes built-in layout and overflow management capabilities because it is designed for structured navigation across dynamic content. Tabs are expected to adapt to varying content sizes and screen resolutions automatically, which is why features like OverflowMode are integrated.
In comparison, the SfButtonGroup component is intentionally kept lightweight and minimal. It is designed to offer flexibility, enabling developers to define custom layout behaviors using standard CSS techniques. This allows the component to fit seamlessly into a wide range of UI designs without enforcing a fixed overflow or wrapping strategy.
As a result, behavior such as text wrapping or horizontal scrolling is expected to be managed via CSS based on the application’s layout needs. The approaches shared earlier—wrapping, scrollable layout, or responsive media queries—are recommended to ensure optimal behavior across device sizes.
This distinction in design intent is what leads to differences in built-in functionality between components like SfTab and SfButtonGroup.
Hi Mallesh,
Thank you for your continued discussion and valuable dialogue. It is greatly appreciated. I see that you reference "light-weight" and "minimal" as design qualities, but from a user's perspective, nothing in the control seems to signify this, which leads to the confusion. That is, nothing about the control in the actual design and/or code (namespace, base control, etc.) seems to denote lightweight or minimal. The only way that I, as a customer, know that this quality exists is if I jump onto your forums and ask why there is a difference in behavior between this control and another found in your same control set offering.
I hope that makes sense. I know you as a designer understand there is a difference, but for me as a user, there is no obvious distinction, only that you have seemingly defined one set of (convenient) properties for one control, while relegating another set of (inconvenient -- as well as error-prone and costly) properties via CSS in another.
Do you have documentation on your website that clearly lists what is intended to be lightweight vs not-lightweight? Maybe this would help in further understanding the design decisions here from a user's perspective.
As both controls are prone to overflow, it would seem they would both have overflow properties baked into your design to account for this scenario with each control. Otherwise, there is an inconsistency in your API design and the resulting suboptimal experience (and confusion) for the users using your product to build their application(s).
Thank you for any further consideration toward addressing this perceived inconsistency in your API.
Hi Mike ,
We apologies for any inconvenience caused , we have logged a feature request to provide “ Need to provide support to add Scroll bar in ButtonGroup component in mobile mode ”. However, this feature is not planned for immediate implementation. We evaluate all feature requests during our planning phases based on factors such as demand, feasibility, and overall priority.
You can track the status of this feature request using the following link:
To help prioritize this feature, we encourage you to vote for it and share any additional specifications or suggestions as comments on the feedback portal.
Disclaimer: “Inclusion of this solution in the weekly release may change due to other factors including but not limited to QA checks and works reprioritization.”
Regards,
Mallesh R
Hi Mallesh! Thank you very much for your consideration. I understand there are other priorities, but at least now others running into the same issue can see that you have at least captured and considered it. i greatly appreciate your exellent support!
Hi Mike-E
Thank you for the update. Please get back to us for assistance in the future.
Regards,
Shereen
- 12 Replies
- 4 Participants
- Marked answer
-
MI Mike-E
- May 10, 2025 02:08 PM UTC
- Jul 9, 2025 04:26 AM UTC