Is there an existing issue or feature request for this?

• I have searched the existing issues and feature requests.

What area does this improvement affect?

User Interface

What actions does this improvement affect?

No response

Description of the idea or improvement

Add an optional decimal input mode to the controlled text field. Apply the
hint to the native shadow input while retaining the existing text, validation
and native form contracts across all supported consumers.

Current limitations or challenges

The field always uses the regular text keyboard. Domus needs a decimal
keyboard for exact localized task base points in vypdev/domus#111.

Expected impact

Mobile users can enter a decimal amount using their device keyboard.
Applications can continue to parse comma and period separators according
to their own policy, using the same shared field.

Alternatives considered

No response

Version of copilot

No response

Additional context or comments

Owning SDD is specs/shared-ui-foundation.md. The reviewed develop base is
202fe15. CI and Branch Sync passed at
that commit. Preserve the baseline cases and use the four new
decimal-field-C01 through decimal-field-C04 identities from the seed.

Decimal keyboard for controlled text fields

• Status: Draft
• Owners: ha-ui maintainers
• Scope: Opt-in decimal input mode on the shared single-line text field
• Open decisions blocking readiness: none

1. Executive summary

Consumers can ask the shared text field to suggest the device's decimal keyboard.
The field continues to carry the exact controlled string.

2. Problem, current behavior, and evidence

The shared renderer uses a native text input with no decimal keyboard hint.
Domus task base points need exact localized decimals on mobile in
Domus #111.

3. Actors, surfaces, and terminology

Consumers use direct browser elements or one of the four existing framework
adapters. The decimal mode is a native keyboard hint. The consumer owns
numeric parsing, locale, precision and allowed range.

4. Goals, non-goals, and fixed invariants

5. Current versus proposed product journey

The app opts in through its existing shared field state. A touch user can
enter a local decimal separator. Desktop keyboard input, paste and editing
continue to send the same controlled strings.

6. Functional behavior and state model

Allow the optional typed inputMode: 'decimal' state key. Reflect the
selected hint on the internal input with native inputmode; omit the attribute
when no mode is set. Reject unsupported state values using the existing
field validation. Preserve type="text".

7. User-facing configuration

Each application chooses the field mode and keeps its existing labels,
description, validation and error content.

8. Clean Architecture design

Keep state validation in the framework-neutral field contract. The core
renderer applies the native attribute. Framework adapters forward existing
state and use the same renderer.

9. UI/UX and content contract

The hint targets mobile text entry. Retain the visible label, keyboard focus,
error association, disabled state and native form behavior. A device chooses
the actual keyboard layout.

10. Failure, recovery, and cleanup

Invalid configuration follows existing field errors. Input state changes
retain the controlled value and leave the app's recovery flow in charge.

11. Security, permissions, and privacy

The renderer uses a validated literal attribute. Application authority and
numeric validation remain with the consumer.

12. Observability and operational UX

Confirm the effective mode on the internal input in actual Chromium. Record
the exact packed cohort and application version in adoption evidence.

13. Compatibility, migration, rollout, and rollback

The field key is optional. Existing source and rendered input continue to
work with the field state absent. Publish the reviewed prerelease cohort
through the repository's npm workflow. Applications pin an exact version.

14. Testing strategy and numeric budget

Minimum four distinct cases. Preserve every existing case and alias in the
owning SDD. The following four fully qualified IDs are new.

{{SDD_CASE_BUDGET}}

15. Documentation and discoverability

{{SDD_FILE_NAVIGATION}}

16. Acceptance scenarios

An app opts in and enters 2,25 on an accessible shared field. The input
advertises decimal mode and the controlled app receives the original
string. An existing text field continues to behave as before.

17. Requirements traceability

{{SDD_REQUIREMENT_CASES}}

18. Implementation sequence

Add the validated optional state, map it to the native input, verify packed
consumers, publish the cohort and exercise it in Domus.

19. Definition of Done

Pass the repository's exact-head checks and verify the published cohort in
the scoped Domus workflow.

20. References and decisions

The shared field owns presentation and controlled text. Decimal points
semantics stay in Domus. The existing adapters remain state bridges.