Add inside label position to InputControl

[andrewhayward]

What?

This change adds a new LabelPosition value of inside to InputControl, allowing consumers to render the label visually inside the field.

Resolves #55963

Why?

As noted in #55963, a use case has come up where a field needs to visually contain its label. This is not currently possible, and as such encourages consumers to use the prefix prop instead. This not only means that the field is less likely to have an accessible name, as the label prop may well get forgotten, but the visual label will not pass focus to the input.

How?

The change adds an additional value of inside to the LabelPosition enum. This is checked inside InputBase, which renders the label element inside as appropriate. Minor changes have been made to the CSS to accommodate this, but existing labels have not changed. Prefix values will also continue to work as before, appearing between any inside label and the input.

Testing Instructions

This shouldn't impact existing labels, as nothing around their implementation has changed. Prefixes shouldn't change either, although the CSS controlling their appearance has been updated slightly.

To test the inner label:

1. Navigate to InputControl in Storybook (likely here).
2. Confirm that setting labelPosition to inside works as expected
3. Confirm that adding a prefix works as expected
4. Confirm that having both doesn't break
5. Confirm that the input field has an accessible name

Additionally:

1. Navigate to SelectControl in Storybook (likely here)
2. Confirm that setting labelPosition to inside works as expected

Testing Instructions for Keyboard

This change should make no difference to keyboard interaction. This can be confirmed by tabbing through the control, with and without an inside label. The focus should move to the input, as normal.

[ciampo]

I noticed that, when the label position is set to inside but the label prop is still empty, the inner label component still renders an empty label element, which also causes the select element to shift slightly to the right.

I wonder if we should avoid rendering a label at all when its contents are empty?

[chad1008]

I had the same thought/observation as @ciampo regarding the shift with an empty inside label, but it tests well and looks good to me otherwise!

[ciampo]

Overall, this is nice work! It probably needs some design feedback around the style of the label in the new inside position.

But since #56001 seems to tackle the immediate product need, we can probably pause work on this and resume if/when we'll be needing such feature at the components level

[andrewhayward]

For the sake of completeness I've added some logic to check for the presence of a label value before rendering either the original label or the new inside version.

But to @ciampo's point, this can be put on hold until a wider use-case arises. Will work on #56001 to resolve the specific issue at hand.

[github-actions]

Flaky tests detected in cbe90bb.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6825085894
📝 Reported issues:

• [Flaky Test] Overlay menu interactions #51537 in /test/e2e/specs/editor/blocks/navigation-frontend-interactivity.spec.js

[andrewhayward]

Closing this, as it's no longer required. Should interest in #55963 resurface, this PR can be revisited.