Improve <calcite-input> suffixes and prefixes

[hcampos-professional]

Check existing issues

• [X] I have checked for existing issues to avoid duplicates

Description

When using a <calcite-input> or <calcite-input-number> with a prefix-text or suffix-text, users are finding it difficult to understand that the suffix and prefix are not clickable. Matters complicate further if the clearable property/attribute is set, since the button looks so similar to the suffix and prefix:

Another issue is that, when multiple inputs are placed next to each other, the suffixes and prefixes won't necessarily have the same with, which doesn't look great.

After some internal discussions, a proposal was floated: placing the suffix and/or prefix inside of the input itself. Here is a mockup of the proposal:

Acceptance Criteria

• When prefix-text and/or suffix-text are specified, they should appear inside of the input instead of inside a bordered container.

Relevant Info

No response

Which Component

• <calcite-input>
• <calcite-input-*>

Example Use Case

The use case we're exploring at the moment is displaying multiple numerical values of a tool stacked vertically, each value with its unit displayed as a suffix-text. In this scenario, having all the suffixes with different widths and having the units appear clickable is not desirable.

Priority impact

p3 - want for upcoming milestone

Calcite package

• [X] @esri/calcite-components
• [ ] @esri/calcite-components-react
• [ ] @esri/calcite-design-tokens
• [ ] @esri/eslint-plugin-calcite-components

Esri team

ArcGIS Maps SDK for JavaScript

[macandcheese]

We may need to explore ways of making the prefix visually distinct from the input content. Suffix doesn’t suffer from the same issue in default alignment but will if alignment is set to end.

It may still be nice to offer way to set the width of these via css property to ensure consistent widths, either when prefix/suffix or both are used. You might still end up with the “width stagger” depending on set up.

Could you add some mockups of these other states to add to the proposed design, and possibly some explorations of focus area? Would clicks on the inert suffix / prefix focus the input ?

[Anastasiia-Boleiko]

The proposal looks great, +1 from the ArcGIS Urban team. The current number input with a unit looks like: In our case it's fine if a unit is close enough to the input value.

[macandcheese]

The proposal looks great, +1 from the ArcGIS Urban team. The current number input with a unit looks like: In our case it's fine if a unit is close enough to the input value.

I think a persistent "trailing suffix" like shown here (but visible during entry) could be nice to explore.

[Anastasiia-Boleiko]

The current number input with a unit looks like:
In our case it's fine if a unit is close enough to the input value.

I think a persistent "trailing suffix" like shown here (but visible during entry) could be nice to explore.

Hi there! 👋

Could you please clarify when we can expect the input component such an update? It's important for ArcGIS Urban app for proper planning and prioritization.

[geospatialem]

Hi there! 👋

Could you please clarify when we can expect the input component such an update? It's important for ArcGIS Urban app for proper planning and prioritization.

@Anastasiia-Boleiko Thanks for reaching out, relayed on your note to the design team. Designers will be prioritizing efforts for a future milestone late next week (dev work would be in a separate milestone). Stay tuned for additional updates in the future.

[github-actions[bot]]

cc @geospatialem, @brittneytewks

[SkyeSeitz]

Design specs can be found in this Figma file for the following two css vars to set a fixed width on the prefix/suffix container:

--calcite-input-prefix-width --calcite-input-suffix-width

Though changing the design of the prefix/suffix affordance to better distinguish them from clickable buttons is something we are currently exploring, it would be a breaking change we would need to reserve it for a major release. You can check out the design specs here as we gather feedback to finalize the proposal.

[hcampos-professional]

While it's would be a great addition, having only a CSS var will force apps to measure the max width of their prefixes/suffixes and then set the var accordingly. It would be great it Calcite provided a mechanism to do that OOTB, either as a utility or some property that would "link" multiple inputs in order to sync their prefixes and suffixes.

[Anastasiia-Boleiko]

Hi there! I noticed that the planned enhancement should enable visual alignment of prefixes and suffixes. However, the current solution does not address our specific issue. We are looking to transition to Calcite Input while maintaining clean forms without excessive clutter. I'm curious if you have any plans regarding the "trailing suffix" or a similar UI?

[hcampos-professional]

For the record, I would also be in favor of @Anastasiia-Boleiko's proposal, and see the "same width prefixes/suffixes" as a stop-gap measure.

[SkyeSeitz]

While it's would be a great addition, having only a CSS var will force apps to measure the max width of their prefixes/suffixes and then set the var accordingly. It would be great it Calcite provided a mechanism to do that OOTB, either as a utility or some property that would "link" multiple inputs in order to sync their prefixes and suffixes.

For sure, @hcampos-professional - agree and I believe this could be most likely introduced as a part of a Form or Input Group component. @jcfranco, thoughts? Is this something that has come up in those conversations thus far?

Thanks for the feedback, @Anastasiia-Boleiko! Yea, while the trailing suffix poses a few specific hurdles, we are currently exploring it and similar improvements documented in this file, where our next step is to gather feedback on a solution we could implement at a major release.

[Anastasiia-Boleiko]

Thank you so much for sharing the details, that's really helpful!😊 So, if I understand correctly, depending on the feedback collected, the earliest release of the feature (trailing suffix) is expected to be in May 2024, right?

[SkyeSeitz]

Hey @Anastasiia-Boleiko sorry for the confusion! The exploration is in early stages so no concrete plans are set on further UI changes to the prefix/suffix, but if we decide to move forward with styling updates, a new issue will be created and targeted for a breaking change release.

[Anastasiia-Boleiko]

Hey👋, We are also looking into Inline Editable component. According to the docs, the default slot is calcite-input. However, when we add a suffix (codepan example), or change the type to number (codepan example), the component no longer appears as an Inline Editable.

Do you consider a new look of suffix or any other property to have a "transparent" display (without wrapping box) within the Inline Editable component? 😊

[hcampos-professional]

Another related pattern that appeared in some internal proposals is to have the suffix be a "dropdown" (or at least clickable) to allow users to select units, for example. If the suffix needs to be clickable or an actual select/dropdown, it may speak in favor of the current design where it already looks clickable.

That being said, the UI could be achievable by using the action slot of the <calcite-input>, except that slot is currently meant for a <calcite-button> and not a <calcite-select> or <calcite-dropdown>: https://codepen.io/hccampos/pen/mdZXXbP?editors=1000

[github-actions[bot]]

Installed and assigned for verification.

[DitwanP]

🍡 Verified on 2.13.0-next.9 https://codepen.io/Ditwan-Price/pen/abgxyNW?editors=1100