Repository navigation
Conversation
|
🚀 Deployed on https://pr-14178--ui5-webcomponents-preview.netlify.app |
GDamyanov
changed the title
👋 Heads-up: dev close is in effectThanks for the contribution! This repository is currently in dev close ahead of release This PR appears to introduce public-API changes (detected by diffing the Custom Elements Manifest against the latest published version on npm):
Could you please hold off on merging into If this change must ship in the current release, please request a review from one or two members of @UI5/ui5-team-webc so the team can sign off explicitly.
Posted automatically by the Dev Close Notice workflow. |
1 similar comment
👋 Heads-up: dev close is in effectThanks for the contribution! This repository is currently in dev close ahead of release This PR appears to introduce public-API changes (detected by diffing the Custom Elements Manifest against the latest published version on npm):
Could you please hold off on merging into If this change must ship in the current release, please request a review from one or two members of @UI5/ui5-team-webc so the team can sign off explicitly.
Posted automatically by the Dev Close Notice workflow. |
| this._formatter = NumberFormat.getFloatInstance({ | ||
| decimals: this.valuePrecision, | ||
| ...(!this._isDesktop && { | ||
| decimalSeparator: DEFAULT_DELIMITER, |
There was a problem hiding this comment.
Here we should add also minusSign and plusSign in the overrides.
Because for example In our CLDR assets, there are few locales that don't use an ASCII - minus sign.
Such are: sv, fi, nb, et, hr, lt, sl.
In those locales user with value={-5} gets the string "−5". The HTML value sanitization rule for type="number" turns any invalid string into "", so the field renders empty.
| return this.formatter.parse(formattedValue) as number; | ||
| } | ||
|
|
||
| _syncValueFromInput() { |
There was a problem hiding this comment.
This method is added to incSpin / decSpin and runs on every device, not only mobile. Is that expected ?
| return this.value.toString(); | ||
| } | ||
|
|
||
| get _isDesktop() { |
There was a problem hiding this comment.
This is checked in ~10 places. Most of them aren't needed.
- Attaching the language-change handler only on desktop is incorrect. The mobile formatter still depends on the locale, so it must be rebuilt on language change. Keeping the original unconditional code is both simpler and correct.
There was a problem hiding this comment.
There is an AI Suggestion for simpler implementation:
## Simpler implementation
`_isDesktop` is checked in ~10 places. Most of them aren't needed:
- **The two `_isDesktop ? _removeGroupSeparators(...) : value` ternaries** (lines 646 and 684) do nothing on mobile. `groupSeparator` already returns `""` there, and `"…".replaceAll("", "")` returns the string unchanged. Calling `_removeGroupSeparators` unconditionally behaves identically.
- **Attaching the language-change handler only on desktop** (lines 429–440) is incorrect. The mobile formatter still depends on the locale (see the minus sign above), so it must be rebuilt on language change. Keeping the original unconditional code is both simpler and correct.
- **`if (preventDefault) e.preventDefault()` in the mobile branch of `_onkeydown`** (lines 777–783) is dead code. That branch is only reached for single-character keys, while `preventDefault` is only `true` for named keys (ArrowUp, Escape, …), which return earlier. A plain `return` is enough.
- **The `delimiter` getter writes `this._delimiter = "."` on every call on mobile.** A getter shouldn't have side effects; just `return ".";`.
- **The flag is named after the device rather than the reason.** The real constraint is "the native input is `type="number"`, so values must be in machine format". A single getter such as `_useNativeNumberInput` driving `type`, `formatter`, `delimiter`, `groupSeparator`, and the keydown early return keeps that reasoning in one place. `DEFAULT_DELIMITER` is also misleading — it's a forced value, not a default.There was a problem hiding this comment.
Mobile devices are not locale aware, since we use we use NumberFormat with . as decimal separator for all locales and disable of grouping so thausand separator is not available in mobile devices
This branch was successfully deployed
2 participants
Summary
On mobile devices, ui5-numeric-input (and by extension ui5-step-input) previously used a plain text input, which opened the standard keyboard instead of the extended
numeric keyboard. This PR switches the component to use the numeric keyboard on mobile and ensures the number format is always compatible with it.
Changes
Extended numeric keyboard on mobile (input[type=number])
The inner input now uses type="number" on non-desktop devices instead of type="text". This causes mobile browsers to display their extended numeric keyboard (with
decimal point, minus sign, and digit keys) when the field is focused, improving usability significantly.
Locale-independent formatting on mobile
type="number" inputs require the value to be in a machine-readable format — the browser rejects locale-specific formats. To ensure compatibility across all locales: