-
Notifications
You must be signed in to change notification settings - Fork 77
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
Enhancement: [Inline Editable] Add appearance="minimal" property #1597
Comments
Is this still a valid request @capeoples ? |
@macandcheese yes we have a few places where we could use inline-edit but don't because it destroys the established visual hierarchy. Not sure what the API for this would look like but we're still interested for sure. |
Could your team provide examples of what they’d need visually? Choosing from a set of icons (like the split-button experience where you select from a pre existing set - in this case add, check, etc) or is more control than that needed? A similar question for color of primary button - we could allow a choice for the main button from our set of button colors (besides red). The cancel button should remain IMO, allowing that to be something like a garbage can could be conflated with deleting the row (which, I guess you could wire up)? Short of slotting custom buttons it would be nice to have at least some set of pre defined options to keep these consistent even when teams need to adjust slightly. |
I think the main case is a secondary interface on the calcite background color with more transparent elements (would be great to have a more minimal input style for this as well). A lot of times it's a list where every single element has an inline edit functionality. (Editing abcabc folder name below) You could argue that we could use the inline edit as is here, but it feels pretty aggressive. |
Makes sense... some thoughts / options: In the past we've heard concerns over a "minimal" input type - I agree that would be a nice solution to leverage here. Maybe that is something we can re-visit, since it applies in this case but also in the "normal" input component. Would you be ok deferring to the provided icons at all times (read: does the check / clear ever need to be customizable)? Would you be ok if there was a prescribed "secondary / subtle" inline-editable appearance that allowed another visual option but stopped short of explicit customizability of each button? |
Yeah, that's fine. Would be better to be consistent about the icons used anyways.
Yes. I think it's probably easier if calcite just provides a slightly more subtle style. Personally I don't need super fine grained control over each button, just a way to turn the volume knob down a bit in general. |
Excellent. Let's repurpose this issue as "add a secondary / subtle" appearance style to the inline-editable component. This would align with other components that have an "appearance" prop, where we provide consistent alternatives to our default styles. |
Nice, in my mind this is very similar to something like the accordion's |
Description
For the inline editable component, it would be ideal to be able to update the button styles for the "x" and "✔️" to be any supported button style. This will enable this component to fully adapt to whatever design/workflow is needed.
Which Component
Inline editable > controls enabled
Example Use Case
In the create new item workflow in Online, a user could want to create a new folder to store the item in. We need the confirm/cancel icons to support this, but it would not be appropriate for the "✔️" to use the solid button style as it's contained in a workflow that already has a primary/solid action button.
cc @paulcpederson
The text was updated successfully, but these errors were encountered: