lightning-base-components 1.26.3-rc.0-alpha → 1.27.2-alpha

package/src/lightning/helptext/form-element.slds.css

@@ -1,5 +1,4 @@
 
-
 /**
  * sldsFormElementUtils.css and form-element.css have many similarities
  * however, they are used for very different use cases, and this is why
@@ -255,7 +254,9 @@
   display: block;
 }
 
-:host([data-render-mode="shadow"][variant='label-stacked']) .slds-form-element__label,:host([data-render-mode="shadow"][variant="label-stacked"]) ::part(rich-text-label),:host([data-render-mode="shadow"][variant='label-stacked']) .slds-form-element__control,:host([data-render-mode="shadow"][variant="label-stacked"]) ::part(rich-text-editor-container) {/* for rich text via lightning-quill */
+:host([data-render-mode="shadow"][variant='label-stacked']) .slds-form-element__label,:host([data-render-mode="shadow"][variant="label-stacked"]) ::part(rich-text-label),:host([data-render-mode="shadow"][variant='label-stacked']) .slds-form-element__control,:host([data-render-mode="shadow"][variant="label-stacked"]) ::part(rich-text-editor-container) {
+  /* for rich text via lightning-quill */
+
   /* @W-14518344 The following line still exists in SLDS-internal
       but it was removed here because it was causing the input
       component to not display it's bottom border
@@ -294,8 +295,7 @@
 /* Force inner child input to not have padding and margin.
 The parent (ex. lightning-input-field) will provide it instead */
 
-:host([data-render-mode="shadow"][variant='label-inline']) .slds-form-element,:host([data-render-mode="shadow"][variant='label-inline']) [variant='label-inline']
-{
+:host([data-render-mode="shadow"][variant='label-inline']) .slds-form-element,:host([data-render-mode="shadow"][variant='label-inline']) [variant='label-inline'] {
   padding: 0;
   margin-block-end: 0;
 }

package/src/lightning/helptext/help-text.slds.css

@@ -1,11 +1,10 @@
 
-
-  :host([data-render-mode="shadow"]) [part='help-text'] {
+:host([data-render-mode="shadow"]) [part='help-text'] {
   /**
     * The extra wrapper div creates a new formatting context which messes up
     * our consistent height and vertical alignment. We don't want this element
     * to inherit any styling so we pass through to the contents. This element
     * is for setting Styling Hooks only.
     */
-    display: contents;
-  }
+  display: contents;
+}

package/src/lightning/helptext/helptext.css

@@ -2,7 +2,7 @@
 
 /* TODO: check if this style can be removed once W-14915319 is closed */
 /* Styles required for Multi-Column Sorting Modal in datatable */
-:host(.modal_header)  .slds-form-element__icon {
+:host(.modal_header) .slds-form-element__icon {
     padding-top: unset;
     padding-left: var(--slds-g-sizing-2);
 }

package/src/lightning/icon/__docs__/icon.md

@@ -42,20 +42,20 @@ is available in your org.
 
 Adjust icon sizes using the `size` attribute with one of these values.
 
--   `medium` is the default size, which creates a 32px by 32px icon
--   `small` creates a 24px by 24px icon
--   `x-small` creates a 16px by 16px icon
--   `xx-small` creates a 14px by 14px icon
--   `large` creates a 48px by 48px icon
+- `medium` is the default size, which creates a 32px by 32px icon
+- `small` creates a 24px by 24px icon
+- `x-small` creates a 16px by 16px icon
+- `xx-small` creates a 14px by 14px icon
+- `large` creates a 48px by 48px icon
 
 ##### Variants
 
 Variants are supported only for the utility icons. To change the appearance of a [utility icon](https://lightningdesignsystem.com/icons/#utility), use the `variant` attribute with one of these values.
 
--   `inverse` adds a white fill to a utility icon, useful for dark backgrounds
--   `error` adds a red fill to a utility icon to call out a user- or system-related error
--   `success` adds a green fill to a utility icon to represent a successful operation
--   `warning` adds a yellow fill to a utility icon to advise caution
+- `inverse` adds a white fill to a utility icon, useful for dark backgrounds
+- `error` adds a red fill to a utility icon to call out a user- or system-related error
+- `success` adds a green fill to a utility icon to represent a successful operation
+- `warning` adds a yellow fill to a utility icon to advise caution
 
 This example uses the `error` variant to add a red fill to the error utility icon.
 
@@ -71,7 +71,7 @@ To apply additional styling, use the SLDS [utility classes](https://www.lightnin
 For example, you can set `class="slds-m-vertical_large"` or other [margin](https://lightningdesignsystem.com/utilities/margin/) classes to add
 spacing around the icon.
 
-Component styling hooks use the `--slds-c-*` prefix and change styling for specific elements or properties of a component. Component-specific styling isn’t recommended, because it’s unsupported for SLDS 2, but existing customizations still work with the original SLDS. If you use component styling hooks, limit the components to SLDS themes until SLDS 2 and the Salesforce Cosmos theme become generally available. See [Icons: Styling Hooks Overview](https://www.lightningdesignsystem.com/components/icons/#Styling-Hooks-Overview) for documentation on component-specific hooks for this component. 
+Component styling hooks use the `--slds-c-*` prefix and change styling for specific elements or properties of a component. Component-specific styling isn’t recommended, because it’s unsupported for SLDS 2, but existing customizations still work with the original SLDS. If you use component styling hooks, limit the components to SLDS themes until SLDS 2 and the Salesforce Cosmos theme become generally available. See [Icons: Styling Hooks Overview](https://www.lightningdesignsystem.com/components/icons/#Styling-Hooks-Overview) for documentation on component-specific hooks for this component.
 
 For more information, see [Style Components Using Lightning Design System Styling Hooks](https://developer.salesforce.com/docs/platform/lwc/guide/create-components-css-custom-properties) in the Lightning Web Components Developer Guide.
 

package/src/lightning/icon/__examples__/variants/variants.css

@@ -1,9 +1,9 @@
-.dark-background{
+.dark-background {
     background-color: #16325c;
     padding: 12px;
     color: #fff;
 }
 
-.row{
-    margin:10px 0;
+.row {
+    margin: 10px 0;
 }

package/src/lightning/icon/icon.slds.css

@@ -132,7 +132,8 @@
     var(--slds-c-icon-sizing, var(--slds-g-sizing-9))
   );
 }
-:host([data-render-mode="shadow"][icon-name*='action']),:host([data-render-mode="shadow"])  .slds-icon_container_circle {
+:host([data-render-mode="shadow"][icon-name*='action']),:host([data-render-mode="shadow"]) 
+.slds-icon_container_circle {
   --slds-c-icon-spacing-block: var(--slds-g-sizing-3);
   --slds-c-icon-spacing-inline: var(--slds-g-sizing-3);
   --slds-c-icon-radius-border: calc(var(--slds-g-radius-border-circle) / 2);
@@ -233,5 +234,8 @@
 }
 :host([data-render-mode="shadow"]) .slds-icon_container {
   border-radius: var(--slds-c-icon-radius-border, var(--slds-s-icon-radius-border));
-  background-color: var(--slds-c-icon-color-background, var(--slds-s-icon-color-background, var(--sds-c-icon-color-background)));
+  background-color: var(
+    --slds-c-icon-color-background,
+    var(--slds-s-icon-color-background, var(--sds-c-icon-color-background))
+  );
 }

package/src/lightning/input/__docs__/input.md

@@ -56,33 +56,33 @@ examples:
 A `lightning-input` component creates an HTML `<input>` element. This component
 supports the following input types:
 
--   `checkbox`
--   `checkbox-button`
--   `date`
--   `datetime`/`datetime-local`
--   `time`
--   `email`
--   `file`
--   `password`
--   `search`
--   `tel`
--   `url`
--   `number`
--   `text` (default)
--   `toggle`
+- `checkbox`
+- `checkbox-button`
+- `date`
+- `datetime`/`datetime-local`
+- `time`
+- `email`
+- `file`
+- `password`
+- `search`
+- `tel`
+- `url`
+- `number`
+- `text` (default)
+- `toggle`
 
 There is no behavioral difference between the `datetime` and `datetime-local` types.
 
 The following HTML input types aren't supported.
 
--   `button`
--   `hidden`
--   `image`
--   `radio`
--   `reset`
--   `submit`
--   `week`
--   `month`
+- `button`
+- `hidden`
+- `image`
+- `radio`
+- `reset`
+- `submit`
+- `week`
+- `month`
 
 Use [`lightning-button`](bundle/lightning-button/documentation)
 instead for input types `button`, `reset`, and
@@ -122,7 +122,7 @@ with a group of checkboxes, use [`lightning-checkbox-group`](bundle/lightning-ch
 
 The checkbox implements the [checkbox](https://www.lightningdesignsystem.com/components/checkbox/) blueprint in SLDS.
 
-Component styling hooks use the `--slds-c-*` prefix and change styling for specific elements or properties of a component. Component-specific styling isn’t recommended, because it’s unsupported for SLDS 2, but existing customizations still work with the original SLDS. If you use component styling hooks, limit the components to SLDS themes until SLDS 2 and the Salesforce Cosmos theme become generally available. See [Checkbox: Styling Hooks Overview](https://www.lightningdesignsystem.com/components/checkbox/#Styling-Hooks-Overview) for documentation on component-specific hooks for this component. 
+Component styling hooks use the `--slds-c-*` prefix and change styling for specific elements or properties of a component. Component-specific styling isn’t recommended, because it’s unsupported for SLDS 2, but existing customizations still work with the original SLDS. If you use component styling hooks, limit the components to SLDS themes until SLDS 2 and the Salesforce Cosmos theme become generally available. See [Checkbox: Styling Hooks Overview](https://www.lightningdesignsystem.com/components/checkbox/#Styling-Hooks-Overview) for documentation on component-specific hooks for this component.
 
 #### Checkbox-button
 
@@ -210,8 +210,6 @@ On mobile devices, this component uses the native datetime picker, which ignores
 When the field receives focus, a message appears under the field with the date format based on the user locale and `date-style` value.
 For example, if your user locale is en-US and the `date-style` is `medium`, the message displays "Format: MMM d, yyyy".
 
-
-
 ##### Desktop
 
 On desktop, `lightning-input` provides its own date/time picker that's styled with
@@ -259,7 +257,7 @@ You can guide users with a `field-level-help` tooltip, as explained in **Adding
 
 On desktop, the datepicker calendar clips behind other components on the page if the parent container of `lightning-input` has a smaller width or height than the calendar. To prevent clipping, give the parent container a minimum width of 285px and minimum height of 310px.
 
-In Lightning Experience, a datepicker calendar that's opened overlays the record edit page or modal, the global header, and record form footer when scrolling. 
+In Lightning Experience, a datepicker calendar that's opened overlays the record edit page or modal, the global header, and record form footer when scrolling.
 
 **Note**: Set the same time zone on your mobile device and in Salesforce to avoid confusion and potential validation
 issues. For example, suppose the current time is 4:00 PM ET. Your mobile device is set to the America/New_York time zone and
@@ -602,7 +600,7 @@ A toggle is similar to a checkbox; it presents a binary choice. However, a toggl
 
 The toggle implements the [checkbox toggle](https://www.lightningdesignsystem.com/components/checkbox-toggle/) blueprint in SLDS.
 
-Component styling hooks use the `--slds-c-*` prefix and change styling for specific elements or properties of a component. Component-specific styling isn’t recommended, because it’s unsupported for SLDS 2, but existing customizations still work with the original SLDS. If you use component styling hooks, limit the components to SLDS themes until SLDS 2 and the Salesforce Cosmos theme become generally available. See [Checkbox Toggle: Styling Hooks Overview](https://www.lightningdesignsystem.com/components/checkbox-toggle/#Styling-Hooks-Overview) for documentation on component-specific hooks for this component. 
+Component styling hooks use the `--slds-c-*` prefix and change styling for specific elements or properties of a component. Component-specific styling isn’t recommended, because it’s unsupported for SLDS 2, but existing customizations still work with the original SLDS. If you use component styling hooks, limit the components to SLDS themes until SLDS 2 and the Salesforce Cosmos theme become generally available. See [Checkbox Toggle: Styling Hooks Overview](https://www.lightningdesignsystem.com/components/checkbox-toggle/#Styling-Hooks-Overview) for documentation on component-specific hooks for this component.
 
 By default, the toggle component expands to 100% of the available width. To limit the size of the toggle component, wrap it with an element that specifies the appropriate width.
 
@@ -717,17 +715,17 @@ This `validity` attribute returns an object with the following read-only `boolea
 properties. One property is set to true and the rest are false, depending on attributes
 set on the input field and the user's entry.
 
--   `badInput`: Indicates that the value is invalid for any input type.
--   `customError`: Indicates that a custom error has been set. See **Custom Validity Error Messages**.
--   `patternMismatch`: Indicates that the value doesn't match the specified `pattern` attribute for `email`, `password`, `search`, `tel`, `text`, or `url` input types.
--   `rangeOverflow`: Indicates that the value is greater than the specified `max` attribute for `number`, `range`, `date`, `datetime`, or `time` input types.
--   `rangeUnderflow`: Indicates that the value is less than the specified `min` attribute for `number`, `range`, `date`, `datetime`, or `time` input types.
--   `stepMismatch`: Indicates that the value doesn't match the specified `step` attribute for `number` or `range` input types.
--   `tooLong`: Indicates that the value exceeds the specified `maxlength` attribute for `email`, `password`, `search`, `tel`, `text`, or `url` input types.
--   `tooShort`: Indicates that the value is less than the specified `minlength` attribute for `email`, `password`, `search`, `tel`, `text`, or `url` input types.
--   `typeMismatch`: Indicates that the value doesn't match the required syntax for `email` or `url` input types.
--   `valueMissing`: Indicates that an empty value is provided when `required` attribute is set for any input type.
--   `valid`: True if none of the preceding properties are true.
+- `badInput`: Indicates that the value is invalid for any input type.
+- `customError`: Indicates that a custom error has been set. See **Custom Validity Error Messages**.
+- `patternMismatch`: Indicates that the value doesn't match the specified `pattern` attribute for `email`, `password`, `search`, `tel`, `text`, or `url` input types.
+- `rangeOverflow`: Indicates that the value is greater than the specified `max` attribute for `number`, `range`, `date`, `datetime`, or `time` input types.
+- `rangeUnderflow`: Indicates that the value is less than the specified `min` attribute for `number`, `range`, `date`, `datetime`, or `time` input types.
+- `stepMismatch`: Indicates that the value doesn't match the specified `step` attribute for `number` or `range` input types.
+- `tooLong`: Indicates that the value exceeds the specified `maxlength` attribute for `email`, `password`, `search`, `tel`, `text`, or `url` input types.
+- `tooShort`: Indicates that the value is less than the specified `minlength` attribute for `email`, `password`, `search`, `tel`, `text`, or `url` input types.
+- `typeMismatch`: Indicates that the value doesn't match the required syntax for `email` or `url` input types.
+- `valueMissing`: Indicates that an empty value is provided when `required` attribute is set for any input type.
+- `valid`: True if none of the preceding properties are true.
 
 #### Error Messages
 
@@ -822,11 +820,11 @@ Some input types can be autofilled, based on your browser's support of the featu
 The `autocomplete` attribute passes through its value to the browser.
 These `lightning-input` types support the `autocomplete` attribute:
 
--   `email`
--   `search`
--   `tel`
--   `text`
--   `url`
+- `email`
+- `search`
+- `tel`
+- `text`
+- `url`
 
 The values `on` and `off` are supported, but the behavior depends on the browser. Some browsers might ignore the passed value.
 
@@ -1054,7 +1052,7 @@ This example creates two fields using `lightning-input` in a compound row simila
 </fieldset>
 ```
 
-Component styling hooks use the `--slds-c-*` prefix and change styling for specific elements or properties of a component. Component-specific styling isn’t recommended, because it’s unsupported for SLDS 2, but existing customizations still work with the original SLDS. If you use component styling hooks, limit the components to SLDS themes until SLDS 2 and the Salesforce Cosmos theme become generally available. See [Input: Styling Hooks Overview](https://www.lightningdesignsystem.com/components/input/#Styling-Hooks-Overview) for documentation on component-specific hooks for this component. 
+Component styling hooks use the `--slds-c-*` prefix and change styling for specific elements or properties of a component. Component-specific styling isn’t recommended, because it’s unsupported for SLDS 2, but existing customizations still work with the original SLDS. If you use component styling hooks, limit the components to SLDS themes until SLDS 2 and the Salesforce Cosmos theme become generally available. See [Input: Styling Hooks Overview](https://www.lightningdesignsystem.com/components/input/#Styling-Hooks-Overview) for documentation on component-specific hooks for this component.
 
 #### Usage Considerations
 
@@ -1081,8 +1079,8 @@ see [Access Labels](https://developer.salesforce.com/docs/platform/lwc/guide/cre
 
 The `lightning-input` component has these limitations when running in the Playground and the Mini-Playground in the Examples tab of this Component Reference.
 
--   The `timezone` attribute currently doesn't work, so the time is formatted using the runtime system's timezone.
--   The input types `date`, `time`, and `datetime` are limited to the en-US locale. Other locales are currently not supported in Playground.
+- The `timezone` attribute currently doesn't work, so the time is formatted using the runtime system's timezone.
+- The input types `date`, `time`, and `datetime` are limited to the en-US locale. Other locales are currently not supported in Playground.
 
 #### Accessibility
 
@@ -1139,7 +1137,7 @@ The event properties are as follows.
 
 **`commit`**
 
-The event fired when you press Enter after interacting with the input, or move away from the input so it loses focus. For the input type `search` the event is also fired when you click the "x" button to clear the search. For the input type `number` the event is also fired when you press Up/Down arrow keys to change the number.
+The event fired when you press Enter after interacting with the input, or move away from the input so it loses focus. For the input type search, the event is only fired when focus leaves the entire component or when the user clicks the "x" button to clear the search. For the input type `number` the event is also fired when you press Up/Down arrow keys to change the number.
 
 The `commit` event doesn’t return any parameters.
 
@@ -1157,9 +1155,9 @@ The [LWC Recipes GitHub repository](https://github.com/trailheadapps/lwc-recipes
 
 For a recipe that uses `lightning-input`, see the following components in the LWC Recipes repo.
 
--   `c-lds-create-record`
--   `c-misc-modal`
--   `c-wire-get-picklist-values`
+- `c-lds-create-record`
+- `c-misc-modal`
+- `c-wire-get-picklist-values`
 
 #### See Also
 

package/src/lightning/input/__examples__/checkboxbutton/checkboxbutton.css

@@ -1,6 +1,6 @@
-      .slds-box {
-        padding: 1rem;
-        margin: 0;
-        border-radius: .25rem;
-        border: 1px solid lightgrey;
-      }
+.slds-box {
+    padding: 1rem;
+    margin: 0;
+    border-radius: 0.25rem;
+    border: 1px solid lightgrey;
+}

package/src/lightning/input/__requirements__/requirements.md

@@ -1,98 +1,98 @@
 ### Events
 
--   When entering a value and that value is "committed", a 'commit' event is dispatch, the event is not bubbling,
-    nor cancelable and has no detail.
-    Committing a number is defined as:
-    the user presses Enter
-    OR blurs away from the input
-    OR presses the "x" clear button for type search)
+- When entering a value and that value is "committed", a 'commit' event is dispatch, the event is not bubbling,
+  nor cancelable and has no detail.
+  Committing a number is defined as:
+  the user presses Enter
+  OR blurs away from the input
+  OR presses the "x" clear button for type search)
 
 ### `number``
 
--   When not a valid ISO number is passed as a value to the input
-    either via an attribute `<lightning-input type="number" value="notANumber"` or
-    property `component.value = 'notANumber'`, the value should be set to empty string.
-    This also means on type changes the number needs to be re-parsed.
+- When not a valid ISO number is passed as a value to the input
+  either via an attribute `<lightning-input type="number" value="notANumber"` or
+  property `component.value = 'notANumber'`, the value should be set to empty string.
+  This also means on type changes the number needs to be re-parsed.
 
     > Covered by Jest tests.
 
--   When not a valid ISO number is passed to 'step', the value of the step should be the default one.
-    Currently that default is 'undefined'. It would be better if this value would be '1' instead.
+- When not a valid ISO number is passed to 'step', the value of the step should be the default one.
+  Currently that default is 'undefined'. It would be better if this value would be '1' instead.
 
     > Covered by Jest tests.
 
--   When entering a number, as the number is typed, it's converted to an ISO number and set as the value.
-    The conversion is done by using the user's current locale (not browser and not OS but rather the locale provided
-    by the localization service).
+- When entering a number, as the number is typed, it's converted to an ISO number and set as the value.
+  The conversion is done by using the user's current locale (not browser and not OS but rather the locale provided
+  by the localization service).
 
     > Covered by integration tests
 
--   In mobile environments a "numbers" keyboard should be presented when an input of type number is tapped.
-    This is done by setting `inputmode="decimal"`
+- In mobile environments a "numbers" keyboard should be presented when an input of type number is tapped.
+  This is done by setting `inputmode="decimal"`
 
     > Covered by snapshot test
 
--   When input has the focus and Up/Down key arrows are pressed, the number is increased/decreased as by the given step, if step is not given, the increases are by 1 and the number is rounded off to an integer.
-    When no initial number is given a value of 0 is used (as such a clck on '-' would net -1, and and '+" would result in 1).
+- When input has the focus and Up/Down key arrows are pressed, the number is increased/decreased as by the given step, if step is not given, the increases are by 1 and the number is rounded off to an integer.
+  When no initial number is given a value of 0 is used (as such a clck on '-' would net -1, and and '+" would result in 1).
 
     > Covered by integration tests
 
--   When numbers are increased either via Up/Down keys or by pressing the - and + buttons, both 'commit' and 'change'
-    events are dispatched.
+- When numbers are increased either via Up/Down keys or by pressing the - and + buttons, both 'commit' and 'change'
+  events are dispatched.
 
--   Bad input (like 1eee3) is flagged as invalid, when an input is flagged as invalid the input should not be formatted
-    when blurred, the original input is kept.
+- Bad input (like 1eee3) is flagged as invalid, when an input is flagged as invalid the input should not be formatted
+  when blurred, the original input is kept.
 
     > Covered by integration tests
 
--   Entering West-Arabic/Hindu numbers should be supported. Due to the way aura localisation implements this these numbers
-    can be mixed with regular numbers and can be entered even if the user locale is not of those types.
+- Entering West-Arabic/Hindu numbers should be supported. Due to the way aura localisation implements this these numbers
+  can be mixed with regular numbers and can be entered even if the user locale is not of those types.
 
--   Very long number input should be supported (the number is no longer rounded off). This is subject to precision
-    limitation of the Up/Down increase/decrease and various operations (like max/min/step checks which are still bound by the usual js limits)
+- Very long number input should be supported (the number is no longer rounded off). This is subject to precision
+  limitation of the Up/Down increase/decrease and various operations (like max/min/step checks which are still bound by the usual js limits)
 
     > Covered by integration Tests
 
--   The 'change' event is fired when the component transitions to a badInput state (ie. validity.badInput is true).
-    Specifically if a valid value is entered followed by a character that's invalid, it will trigger a 'change' event, and
-    the value will be ''.
+- The 'change' event is fired when the component transitions to a badInput state (ie. validity.badInput is true).
+  Specifically if a valid value is entered followed by a character that's invalid, it will trigger a 'change' event, and
+  the value will be ''.
 
     > Covered by integration tests
 
--   When a number starts with a decimal separator (like -.2 or .3), the resulting value should always have a zero
-    in front (ie. .value should be -0.2 and 0.3 respectively)
+- When a number starts with a decimal separator (like -.2 or .3), the resulting value should always have a zero
+  in front (ie. .value should be -0.2 and 0.3 respectively)
 
     > Covered by Jest tests
 
--   'step' attribute is used to determine the significant digits for formatting of a number; when 'step' has a superfluous .0 at the end, the number of significant digits should be 0; exponent format should also be correctly calculated, eg. 1.5e-5 should net 6 significant digits when formatting the number; positive exponents should also be correctly parsed (eg. 1e10 should net 0)
+- 'step' attribute is used to determine the significant digits for formatting of a number; when 'step' has a superfluous .0 at the end, the number of significant digits should be 0; exponent format should also be correctly calculated, eg. 1.5e-5 should net 6 significant digits when formatting the number; positive exponents should also be correctly parsed (eg. 1e10 should net 0)
 
     > Covered by Jest tests
 
--   only valid characters are allowed to be typed (anything can be pasted in however), valid characters are considered:
-    -   `0-9`
-    -   `k` `K` `m` `M` `b` `B` `t` `T` (shortcuts)
-    -   `e` `E` (exponent)
-    -   `+` `-` `.` `,`
-    -   West-Arabic/Hindu numbers
+- only valid characters are allowed to be typed (anything can be pasted in however), valid characters are considered:
+    - `0-9`
+    - `k` `K` `m` `M` `b` `B` `t` `T` (shortcuts)
+    - `e` `E` (exponent)
+    - `+` `-` `.` `,`
+    - West-Arabic/Hindu numbers
         > Covered by Jest and integration tests
 
 #### number 'k' / 'm' / 'b' shortcuts
 
--   When an entered valid number in the given locale ends in "k", "K", "m", "M", "b", "B", "t" or "T" (shortcut suffix):
-    -   as soon as the suffix is entered `value` is `1000 * the entered` number if "k" or "K" is the suffix, or `1000000 * the entered number` if "m" or "M" is the suffix, or `1000000000 * the entered number` if "b" or "B" is the suffix, or `1000000000000 * the entered number` if "t" or "T" is the suffix
+- When an entered valid number in the given locale ends in "k", "K", "m", "M", "b", "B", "t" or "T" (shortcut suffix):
+    - as soon as the suffix is entered `value` is `1000 * the entered` number if "k" or "K" is the suffix, or `1000000 * the entered number` if "m" or "M" is the suffix, or `1000000000 * the entered number` if "b" or "B" is the suffix, or `1000000000000 * the entered number` if "t" or "T" is the suffix
         > Covered by Jest and Integration tests
-    -   when blurring from the input, the value shown on the input should reflect the multiplied number (eg. for `1k` it could be `1,000` for a locale with `,` as a grouping separator)
+    - when blurring from the input, the value shown on the input should reflect the multiplied number (eg. for `1k` it could be `1,000` for a locale with `,` as a grouping separator)
         > Covered by Jest and Integration tests
-    -   when the input is focused, the value that's in the input will be the multiplied number
-        in the given locale with the correct decimal separator and no grouping separators (eg. if in a locale with "," as a decimal separator number `0,0001k` was entered, when focusing after a blur the number should show as `0,1`)
+    - when the input is focused, the value that's in the input will be the multiplied number
+      in the given locale with the correct decimal separator and no grouping separators (eg. if in a locale with "," as a decimal separator number `0,0001k` was entered, when focusing after a blur the number should show as `0,1`)
         > Covered by Jest and Integration tests (partially, it would be good to have a test that overrides the locale used to test with locales that have different decimal digits)
--   If the input is not a valid number but has a shortcut suffix at the end, when blurring from the input, and then focusing back on it, the original entered string should be preserved (eg. if `100eee10k` is entered, blurring out and focusing should preserve that value)
+- If the input is not a valid number but has a shortcut suffix at the end, when blurring from the input, and then focusing back on it, the original entered string should be preserved (eg. if `100eee10k` is entered, blurring out and focusing should preserve that value)
     > Covered by Jest tests
--   When setting the value programmatically, value that contains a shortcut suffix should not be considered valid
+- When setting the value programmatically, value that contains a shortcut suffix should not be considered valid
     > Covered by Jest tests
 
 ### Open questions
 
--   We need to define the behaviour for - and + when max or min are hit, and also whether it should round to the
-    closest step. In addition the behaviour for when the number is larger than what js arithmetics can handle (because
-    of the rounding errors the increase/decrease does nothing).
+- We need to define the behaviour for - and + when max or min are hit, and also whether it should round to the
+  closest step. In addition the behaviour for when the number is larger than what js arithmetics can handle (because
+  of the rounding errors the increase/decrease does nothing).

package/src/lightning/input/form-element.slds.css

@@ -1,5 +1,4 @@
 
-
 /**
  * sldsFormElementUtils.css and form-element.css have many similarities
  * however, they are used for very different use cases, and this is why
@@ -255,7 +254,9 @@
   display: block;
 }
 
-:host([data-render-mode="shadow"][variant='label-stacked']) .slds-form-element__label,:host([data-render-mode="shadow"][variant="label-stacked"]) ::part(rich-text-label),:host([data-render-mode="shadow"][variant='label-stacked']) .slds-form-element__control,:host([data-render-mode="shadow"][variant="label-stacked"]) ::part(rich-text-editor-container) {/* for rich text via lightning-quill */
+:host([data-render-mode="shadow"][variant='label-stacked']) .slds-form-element__label,:host([data-render-mode="shadow"][variant="label-stacked"]) ::part(rich-text-label),:host([data-render-mode="shadow"][variant='label-stacked']) .slds-form-element__control,:host([data-render-mode="shadow"][variant="label-stacked"]) ::part(rich-text-editor-container) {
+  /* for rich text via lightning-quill */
+
   /* @W-14518344 The following line still exists in SLDS-internal
       but it was removed here because it was causing the input
       component to not display it's bottom border
@@ -294,8 +295,7 @@
 /* Force inner child input to not have padding and margin.
 The parent (ex. lightning-input-field) will provide it instead */
 
-:host([data-render-mode="shadow"][variant='label-inline']) .slds-form-element,:host([data-render-mode="shadow"][variant='label-inline']) [variant='label-inline']
-{
+:host([data-render-mode="shadow"][variant='label-inline']) .slds-form-element,:host([data-render-mode="shadow"][variant='label-inline']) [variant='label-inline'] {
   padding: 0;
   margin-block-end: 0;
 }

package/src/lightning/input/input.lbc.synthetic.css

@@ -2,7 +2,7 @@
     display: block;
 }
 
-input[type="tel"]:dir(rtl) {
+input[type='tel']:dir(rtl) {
     direction: ltr;
     text-align: right;
     unicode-bidi: embed;