Open mitc7862 opened 2 years ago
@benelan @jcfranco - noted as high priority. Mitch has available cycles to help with design if needed.
From design standpoint - would need to figure out how to display this / position the slot amongst other unnamed content slotted in label - the inline / inline-space-between layouts would need to be considered.
It is achievable currently: https://codepen.io/mac_and_cheese/pen/LYddREp?editors=1000
But the label's click handler focuses the child control when clicking on the slotted actions - maybe an opt-out class consumers could use to exclude slotted elements like actions as shown above could be an interim fix / helper?
Hi All
Any update on this issue , we are looking to use this for showing analysis help for parameters. Can we have it for Online release 10.3?
Adding the slot will require a major refactor, and will be prioritized after next month's release. cc: @ashetland, @Elijbet
Once prioritized the effort should be coupled with https://github.com/Esri/calcite-components/issues/2793 and https://github.com/Esri/calcite-components/issues/4155.
Design consideration here must include the inline and inline space between layout types of label.
Is there a need for a slot at both start and end positions as noted in issue #4155 (pictured below), or are we looking for just an end slot shown in the above examples?
Follow-up includes:
For analysis R03 release we are hoping this issue can be addressed. We did a custom implementation analysis-label
but we are running into a11y issues, before we continue updating our custom component we are hoping if calcite-label is enhanced we can use it from the design system instead of having our own analysis-label. As it is a core design system UI, we may otherwise miss other features going into calclite-label
if we use our custom label component .
We need slot for showing help which is a fundamental UI experience in Analysis Tools.
Analysis Help is shown on every tool parameter label and parameters that are required , show required UI indicator with a red dot as shared above.
Adding the required prop to Calcite Label will be tackled with epic #4598. Slots will need to be handled separately at a later time due to refactor considerations.
Recommend using a red asterisk instead of a red dot as the dot would be too similar to other Calcite indicators noting selection or active states. Asterisks are also a normalized standard for marking required fields, see this NNGroup article.
Design specs are available in this Figma file showing each scale using a medium-weight asterisk and a 2px gap.
The above Figma file has been updated to remove the 2px gap and instead add 2px of inline padding to the asterisk. This was to increase its hover area size. After some digging, it looks like there is a fair mix of use of tooltips or html labels (native tooltip) showing "Required" on hover as well as many implementations that do nothing, relying on just the presence of the asterisk. Using Calcite Tooltip on hover is likely more consistent, but an html label could also work in this case.
The asterisk would not need to be keyboard focusable, but aria-required should be used for assistive technologies.
cc @geospatialem, @brittneytewks
Logging this as ready-for-dev
, but leaving myself assigned for when we tackle the slots. Multiple designs for this exist with final details to be ironed out when we're ready to do it.
@ashetland Going to remove your assignment so a developer picks this issue up, but you should receive notifications as updates roll in. For developers - if you pick up this issue, please consult with Aaron on next steps.
Thanks @geospatialem!. Adding the Figma link again for adding required
to Calcite Label so it doesn't get lost in the thread.
Initial discussions and accommodations will sought in the next few weeks to create a solution before the end of the milestone.
Thank you all for your continued patience and invaluable feedback on this matter. After extensive discussion on both the design and implementation, we've determined that this request can't be accomplished without introducing breaking changes for existing use cases or by introducing a diverging usage pattern for required-label scenarios.
Our upcoming work on #4598 aims to incorporate built-in labels into form components, helping to simplify the label usage story and to decouple it from being used for layout. An additional internal component might be required to handle the required affordances, related slots, styling and layout (the crux of this issue). We are still looking into this, so it won't likely be available before the built-in label work is completed. Rest assured, we'll keep you posted with any significant developments.
We understand that this has been a recurring concern from our users, so I'd like to share a preliminary version of what the supporting component could look like: https://codepen.io/jcfranco/pen/LYMOXOq?editors=1011. This can be adopted outside of calcite-components
and might serve as a potential placeholder until our official supporting component is rolled out.
cc @macandcheese @ashetland @skyeseitz @geospatialem @brittneytewks
cc @geospatialem, @brittneytewks
Blocked by the efforts of a built-in label across form components via https://github.com/Esri/calcite-design-system/issues/8572, targeted in the January milestone.
Description
We need a better way to indicate to users when fields are required in order to run an analysis tool. We also need the ability to let users show parameter-specific help. Both of these needs could be met by enhancing the calcite label component to have the following:
Acceptance Criteria
Required property:
Action slot:
Relevant Info
This enhancement is needed for the Analysis "min ship", which is slated for the 10.3 online release.
Which Component
Calcite Label for
Example Use Case
No response