@lion/ui 0.20.0 → 0.21.1

package/custom-elements.json

@@ -1206,6 +1206,14 @@
             "name": "runInputTelDropdownSuite",
             "module": "../components/input-tel-dropdown/test-suites/LionInputTelDropdown.suite.js"
           }
+        },
+        {
+          "kind": "js",
+          "name": "runInputTelDropdownParenthesesSuite",
+          "declaration": {
+            "name": "runInputTelDropdownParenthesesSuite",
+            "module": "../components/input-tel-dropdown/test-suites/LionInputTelDropdown--parentheses.suite.js"
+          }
         }
       ]
     },
@@ -8322,7 +8330,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "FormatMixin",
                 "module": "components/form-core/src/FormatMixin.js"
@@ -9002,7 +9010,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -9793,6 +9801,16 @@
                 "module": "components/form-core/src/FormControlMixin.js"
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "FormatMixin",
+                "module": "components/form-core/src/FormatMixin.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -11777,7 +11795,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "FormatMixin",
                 "module": "components/form-core/src/FormatMixin.js"
@@ -12434,7 +12452,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -13210,6 +13228,16 @@
                 "module": "components/form-core/src/FormControlMixin.js"
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "FormatMixin",
+                "module": "components/form-core/src/FormatMixin.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -24298,7 +24326,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "FormatMixin",
                 "module": "components/form-core/src/FormatMixin.js"
@@ -24955,7 +24983,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -25731,6 +25759,16 @@
                 "module": "components/form-core/src/FormControlMixin.js"
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "FormatMixin",
+                "module": "components/form-core/src/FormatMixin.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -26982,7 +27020,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "FormatMixin",
                 "module": "components/form-core/src/FormatMixin.js"
@@ -27639,7 +27677,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -28415,6 +28453,16 @@
                 "module": "components/form-core/src/FormControlMixin.js"
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "FormatMixin",
+                "module": "components/form-core/src/FormatMixin.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -30272,7 +30320,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "FormatMixin",
                 "module": "components/form-core/src/FormatMixin.js"
@@ -30929,7 +30977,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -31705,6 +31753,16 @@
                 "module": "components/form-core/src/FormControlMixin.js"
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "FormatMixin",
+                "module": "components/form-core/src/FormatMixin.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -35718,7 +35776,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "FormatMixin",
                 "module": "components/form-core/src/FormatMixin.js"
@@ -36375,7 +36433,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -37151,6 +37209,16 @@
                 "module": "components/form-core/src/FormControlMixin.js"
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "FormatMixin",
+                "module": "components/form-core/src/FormatMixin.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -39258,7 +39326,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators."
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators."
             },
             {
               "kind": "field",
@@ -39273,6 +39341,11 @@
                 }
               ]
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true
+            },
             {
               "kind": "method",
               "name": "preprocessor",
@@ -39292,7 +39365,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -44123,7 +44196,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "FormatMixin",
                 "module": "components/form-core/src/FormatMixin.js"
@@ -44717,7 +44790,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -45429,6 +45502,16 @@
                 "module": "components/form-core/src/FormControlMixin.js"
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "FormatMixin",
+                "module": "components/form-core/src/FormatMixin.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -47376,7 +47459,16 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
+              "inheritedFrom": {
+                "name": "FormatMixin",
+                "module": "components/form-core/src/FormatMixin.js"
+              }
+            },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
               "inheritedFrom": {
                 "name": "FormatMixin",
                 "module": "components/form-core/src/FormatMixin.js"
@@ -47401,7 +47493,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -61432,7 +61524,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "FormatMixin",
                 "module": "components/form-core/src/FormatMixin.js"
@@ -61455,6 +61547,15 @@
                 "module": "components/form-core/src/FormatMixin.js"
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "FormatMixin",
+                "module": "components/form-core/src/FormatMixin.js"
+              }
+            },
             {
               "kind": "method",
               "name": "preprocessor",
@@ -61474,7 +61575,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -69860,7 +69961,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "LionField",
                 "module": "components/form-core/src/LionField.js"
@@ -70487,7 +70588,8 @@
               "attribute": "modelValue",
               "type": {
                 "text": "object"
-              }
+              },
+              "description": "For a FormControl to function properly, its modelValue, serializedValue and  viewValue/formattedValue\nshould always translate in two directions. This is expected by `_callParser` method. It guards for empty\nviewValues. As the viewValue (`.value`) only concerns the amount part and not the currency part in\nInputAmountDropdown, this contract is broken.\nBelow, we compensate for this."
             },
             {
               "kind": "field",
@@ -70617,7 +70719,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -71501,6 +71603,16 @@
                 "text": "HTMLInputElement | HTMLTextAreaElement"
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "LionField",
+                "module": "components/form-core/src/LionField.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -72397,6 +72509,16 @@
                 "module": "components/form-core/src/LionField.js"
               }
             },
+            {
+              "kind": "field",
+              "name": "__modelValue",
+              "description": "The internal modelValue is a combination of the amount and the currency code. The amount is a number, the currency code is a string.",
+              "privacy": "private",
+              "type": {
+                "text": "AmountDropdownModelValue"
+              },
+              "default": "{ currency: this.currency, amount: '' }"
+            },
             {
               "kind": "method",
               "name": "__onBlur",
@@ -72819,17 +72941,6 @@
             }
           ],
           "attributes": [
-            {
-              "name": "modelValue",
-              "fieldName": "modelValue",
-              "type": {
-                "text": "object"
-              },
-              "inheritedFrom": {
-                "name": "LionInputAmount",
-                "module": "components/input-amount/src/LionInputAmount.js"
-              }
-            },
             {
               "name": "preferredCurrencies",
               "type": {
@@ -72869,6 +72980,14 @@
                 "module": "components/input-amount/src/LionInputAmount.js"
               }
             },
+            {
+              "name": "modelValue",
+              "fieldName": "modelValue",
+              "inheritedFrom": {
+                "name": "LionInputAmount",
+                "module": "components/input-amount/src/LionInputAmount.js"
+              }
+            },
             {
               "name": "autocomplete",
               "type": {
@@ -73351,7 +73470,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "LionField",
                 "module": "components/form-core/src/LionField.js"
@@ -74073,7 +74192,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -74892,6 +75011,16 @@
                 "text": "HTMLInputElement | HTMLTextAreaElement"
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "LionField",
+                "module": "components/form-core/src/LionField.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -76734,7 +76863,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "LionField",
                 "module": "components/form-core/src/LionField.js"
@@ -77428,7 +77557,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -78235,6 +78364,16 @@
                 "text": "HTMLInputElement | HTMLTextAreaElement"
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "LionField",
+                "module": "components/form-core/src/LionField.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -80021,7 +80160,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "LionField",
                 "module": "components/form-core/src/LionField.js"
@@ -80740,7 +80879,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -81673,6 +81812,16 @@
               "description": "Subclassers can replace this with their custom extension invoker,\nlike `<my-button><calendar-icon></calendar-icon></my-button>`",
               "privacy": "protected"
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "LionField",
+                "module": "components/form-core/src/LionField.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -83530,7 +83679,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "LionField",
                 "module": "components/form-core/src/LionField.js"
@@ -84230,7 +84379,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -85038,6 +85187,16 @@
                 "text": "HTMLInputElement | HTMLTextAreaElement"
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "LionField",
+                "module": "components/form-core/src/LionField.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -86695,7 +86854,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "LionField",
                 "module": "components/form-core/src/LionField.js"
@@ -87432,7 +87591,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -88306,6 +88465,16 @@
               "privacy": "protected",
               "readonly": true
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "LionField",
+                "module": "components/form-core/src/LionField.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -91413,7 +91582,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "LionField",
                 "module": "components/form-core/src/LionField.js"
@@ -92115,7 +92284,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -92923,6 +93092,16 @@
                 "text": "HTMLInputElement | HTMLTextAreaElement"
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "LionField",
+                "module": "components/form-core/src/LionField.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -95590,7 +95769,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "LionField",
                 "module": "components/form-core/src/LionField.js"
@@ -96176,6 +96355,16 @@
               "attribute": "max",
               "reflects": true
             },
+            {
+              "kind": "field",
+              "name": "maxLabel",
+              "privacy": "public",
+              "type": {
+                "text": "string"
+              },
+              "default": "''",
+              "attribute": "max-label"
+            },
             {
               "kind": "field",
               "name": "min",
@@ -96187,6 +96376,16 @@
               "attribute": "min",
               "reflects": true
             },
+            {
+              "kind": "field",
+              "name": "minLabel",
+              "privacy": "public",
+              "type": {
+                "text": "string"
+              },
+              "default": "''",
+              "attribute": "min-label"
+            },
             {
               "kind": "field",
               "name": "modelValue",
@@ -96315,7 +96514,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -97168,6 +97367,16 @@
                 "text": "HTMLInputElement | HTMLTextAreaElement"
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "LionField",
+                "module": "components/form-core/src/LionField.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -97649,6 +97858,18 @@
                 "module": "components/form-core/src/LionField.js"
               }
             },
+            {
+              "kind": "field",
+              "name": "_valueDisplay",
+              "description": "Get the display info for the current value",
+              "privacy": "protected",
+              "return": {
+                "type": {
+                  "text": "{ text: string, showUnit: boolean }"
+                }
+              },
+              "readonly": true
+            },
             {
               "kind": "field",
               "name": "_visibleMessagesAmount",
@@ -98367,6 +98588,22 @@
               "default": "false",
               "fieldName": "noMinMaxLabels"
             },
+            {
+              "name": "min-label",
+              "type": {
+                "text": "string"
+              },
+              "default": "''",
+              "fieldName": "minLabel"
+            },
+            {
+              "name": "max-label",
+              "type": {
+                "text": "string"
+              },
+              "default": "''",
+              "fieldName": "maxLabel"
+            },
             {
               "name": "autocomplete",
               "type": {
@@ -98907,7 +99144,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "LionField",
                 "module": "components/form-core/src/LionField.js"
@@ -99635,7 +99872,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -100555,6 +100792,16 @@
                 "text": "HTMLInputElement | HTMLTextAreaElement"
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "LionField",
+                "module": "components/form-core/src/LionField.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -102307,6 +102554,38 @@
         }
       ]
     },
+    {
+      "kind": "javascript-module",
+      "path": "components/input-tel-dropdown/test-suites/LionInputTelDropdown--parentheses.suite.js",
+      "declarations": [
+        {
+          "kind": "function",
+          "name": "runInputTelDropdownParenthesesSuite",
+          "parameters": [
+            {
+              "name": "{ klass, config }",
+              "default": "{ klass: LionInputTelDropdown, config: telDropdownConfig }"
+            },
+            {
+              "name": "config",
+              "type": {
+                "text": "{ klass:LionInputTelDropdown, config: TelDropdownConfig }"
+              }
+            }
+          ]
+        }
+      ],
+      "exports": [
+        {
+          "kind": "js",
+          "name": "runInputTelDropdownParenthesesSuite",
+          "declaration": {
+            "name": "runInputTelDropdownParenthesesSuite",
+            "module": "components/input-tel-dropdown/test-suites/LionInputTelDropdown--parentheses.suite.js"
+          }
+        }
+      ]
+    },
     {
       "kind": "javascript-module",
       "path": "components/input-tel-dropdown/src/getFlagSymbol.js",
@@ -102403,7 +102682,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "LionField",
                 "module": "components/form-core/src/LionField.js"
@@ -103178,7 +103457,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue: string; caretIndex: number; } | undefined"
@@ -104034,6 +104313,16 @@
                 "text": "HTMLInputElement | HTMLTextAreaElement"
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "LionField",
+                "module": "components/form-core/src/LionField.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -106028,7 +106317,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "LionField",
                 "module": "components/form-core/src/LionField.js"
@@ -106779,7 +107068,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue: string; caretIndex: number; } | undefined"
@@ -107597,6 +107886,16 @@
                 "text": "HTMLInputElement | HTMLTextAreaElement"
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "LionField",
+                "module": "components/form-core/src/LionField.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -109780,7 +110079,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "LionField",
                 "module": "components/form-core/src/LionField.js"
@@ -110476,7 +110775,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -111280,6 +111579,16 @@
                 "text": "HTMLInputElement | HTMLTextAreaElement"
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "LionField",
+                "module": "components/form-core/src/LionField.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -119385,7 +119694,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "FormatMixin",
                 "module": "components/form-core/src/FormatMixin.js"
@@ -119663,7 +119972,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -119862,6 +120171,16 @@
                 "module": "components/form-core/src/FormatMixin.js"
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "FormatMixin",
+                "module": "components/form-core/src/FormatMixin.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -127837,7 +128156,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "LionField",
                 "module": "components/form-core/src/LionField.js"
@@ -128565,7 +128884,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -129390,6 +129709,16 @@
                 "text": "HTMLInputElement | HTMLTextAreaElement"
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "LionField",
+                "module": "components/form-core/src/LionField.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -135111,7 +135440,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "LionField",
                 "module": "components/form-core/src/LionField.js"
@@ -135789,7 +136118,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -136559,6 +136888,16 @@
                 }
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "LionField",
+                "module": "components/form-core/src/LionField.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -138526,7 +138865,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "LionField",
                 "module": "components/form-core/src/LionField.js"
@@ -139224,7 +139563,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -140010,6 +140349,16 @@
                 "text": "LionSwitchButton"
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "LionField",
+                "module": "components/form-core/src/LionField.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",
@@ -142354,7 +142703,7 @@
                 "text": "object"
               },
               "default": "{ didFormatterOutputSyncToView: false, didFormatterRun: false, }",
-              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the curent interpretation of separators.",
+              "description": "During format/parse, we sometimes need to know how the current viewValue the user\ninteracts with \"came to be\". Was it already formatted before for instance?\nIf so, in case of an amount input, we might want to stick to the current interpretation of separators.",
               "inheritedFrom": {
                 "name": "LionField",
                 "module": "components/form-core/src/LionField.js"
@@ -143060,7 +143409,7 @@
                   }
                 }
               ],
-              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessro that smartly\nupdates the viewValue and caret position for best UX.",
+              "description": "Preprocessors could be considered 'live formatters'. Their result is shown to the user\non keyup instead of after blurring the field. The biggest difference between preprocessors\nand formatters is their moment of execution: preprocessors are run before modelValue is\ncomputed (and work based on view value), whereas formatters are run after the parser (and\nare based on modelValue)\nAutomatically formats code while typing. It depends on a preprocessor that smartly\nupdates the viewValue and caret position for best UX.",
               "return": {
                 "type": {
                   "text": "{ viewValue:string; caretIndex:number; }|string|undefined"
@@ -143891,6 +144240,16 @@
                 "text": "HTMLInputElement | HTMLTextAreaElement"
               }
             },
+            {
+              "kind": "field",
+              "name": "_isEditingTextField",
+              "readonly": true,
+              "inheritedFrom": {
+                "name": "LionField",
+                "module": "components/form-core/src/LionField.js"
+              },
+              "privacy": "protected"
+            },
             {
               "kind": "method",
               "name": "_isEmpty",