Clicking near a label can focus its input

[nwhittaker]

Actual Behavior

Clicking anywhere within a <calcite-label> component, other than it's text content, shifts focus to the associated input.

Expected Behavior

Clicking anywhere within a <calcite-label> component, other than it's text content, does not shift focus to the associated input. Only clicks on the label's text content shift focus.

Reproduction Sample

https://codepen.io/nwhittaker-esri/pen/MWqRLdP

Reproduction Steps

1. Visit the sample and expand the width of the window, if needed.
2. Click anywhere within the cyan boxes other than where the label's text content is.

Reproduction Version

1.2.0

Relevant Info

No response

Regression?

No response

Priority impact

p4 - not time sensitive

Impact

Given the variety of layouts a label can exist in, the element can expand to contain a good deal of white-space by default. As a result, it can be difficult for the user to know they are clicking within that white-space and to anticipate the effect the click will have.

As a developer, native <label> elements have an inline display by default. As a result, it's easy to miss that the <calcite-label> component needs extra styling to wrangle any extra white-space. It can also make using the variant where the label encloses both the test content and input a non-starter.

Esri team

ArcGIS Field Apps

[geospatialem]

Research to compare between native label and calcite-label in the June milestone.

[jcfranco]

The main issue here is that calcite-label's display is not inline compared to label. If we put that aside, the focusable behavior (clicking anywhere on the label to focus the focusable child) is working as designed and is consistent with the browser's built-in element.

I'd be wary to change display any time soon, as this would be a breaking change with high impact since it's commonly used.

@macandcheese One workaround would be to set layout="inline" and display:inline-flex on <calcite-label>, but this would probably also need its container and associated elements' CSS/layout to be tweaked. @macandcheese, @driskull any other ideas?

As a developer, native <label> elements have an inline display by default. As a result, it's easy to miss that the <calcite-label> component needs extra styling to wrangle any extra white-space.

@geospatialem @macandcheese Maybe we should highlight this difference in the doc to at least make it more prominent.

[macandcheese]

Cool with documenting this for now. An issue with adjusting css is that currently Label functions as a layout container with pretty drastically different display modes (inline / inline-space-between / default).

Going forward, we could improve how we handle Label as a component altogether - wonder if we should look at that alongside validation story, the updates for required, hint text, etc., - could the Label functionality be accomplished by accepting label properties on expected components? The layout could still be accomplished but we could control the rendering of the label text and what clicks do what.

[nwhittaker]

For posterity, I updated the original codepen to better illustrate the difference between the <calcite-label> layouts vs. the native <label> element's default layout

[geospatialem]

Doc update has been installed for tomorrow's doc release. Modified the issue context and added the needs-milestone label for future considerations mentioned by @jcfranco and @macandcheese

One workaround would be to set layout="inline" and display:inline-flex on , but this would probably also need its container and associated elements' CSS/layout to be tweaked. @macandcheese, @driskull any other ideas?

and

Going forward, we could improve how we handle Label as a component altogether - wonder if we should look at that alongside validation story, the updates for required, hint text, etc., - could the Label functionality be accomplished by accepting label properties on expected components? The layout could still be accomplished but we could control the rendering of the label text and what clicks do what.

[driskull]

Seems like we could introduce a property to configure the display on label if necessary. By default we could leave it as inline-flex but when an appearance prop is modified it could go to inline.

[geospatialem]

Due to the wide use of label, team members will work towards a deprecation in the coming months and plan out a breaking change with a future release. A milestone will be assigned in the coming weeks.

[geospatialem]

Blocked by the label effort in https://github.com/Esri/calcite-design-system/issues/5079.