Change Details

### Background According to the design specs, most interactive components should be 32px tall at the base font size. 32px is defined as `min-size-interactive-pointer` and is the min-height of these components. However, there is a discrepancy between the height of these components as implemented in the Codex component library: - Select, TextInput, and components that use TextInput (Combobox, Lookup, TypeaheadSearch) are 32.85px tall - Button, ToggleSwitch, and FilterChipInput are 32px tall ### Solution We could fix the too-tall components by reducing the line-height from `line-height-x-small`, a deprecated token, to `line-height-xx-small`, which is what they should be anyway. #### Implications This will cause a slight change in TypeaheadSearch since the height of the input will be reduced. We should ensure that this does not cause a regression, especially between the server-rendered input and the Vue version. This should not be an issue since both versions use the same styles now, but we should note it anyway. --- ### Acceptance criteria - [] Decide how to fix the height discrepancy - [] Implement and test

### Background According to the design specs, most interactive components should be 32px tall at the base font size. 32px is defined as `min-size-interactive-pointer` and is the min-height of these components. However, there is a discrepancy between the height of these components as implemented in the Codex component library: - Select, TextInput, and components that use TextInput (Combobox, Lookup, SeachInput, and TypeaheadSearch) are 32.84px tall (in [[ https://doc.wikimedia.org/codex/latest/components/overview.html | Codex Demo ]]) - Button, ToggleSwitch, and FilterChipInput are 32px tall - TextInputs with `type="date"` are even taller at 34.84px tall. All TextInputs share the same `line-height`, but something inside the box's content adds an extra 2px to the height of the TextInput with `type="date"`. - Note: There's a discrepancy between changes run on localhost versus [[ https://993763--wikimedia-codex.netlify.app/components/demos/text-input.html#demos | Netlify preview ]]. ### Solution We could fix the too-tall components by reducing the line-height from `line-height-x-small`, a deprecated token, to `line-height-xx-small`, which is what they should be anyway. #### Implications This will cause a slight change in TypeaheadSearch since the height of the input will be reduced. We should ensure that this does not cause a regression, especially between the server-rendered input and the Vue version. This should not be an issue since both versions use the same styles now, but we should note it anyway. --- ### Acceptance criteria - [] Decide how to fix the height discrepancy - [] Implement and test

### Background According to the design specs, most interactive components should be 32px tall at the base font size. 32px is defined as `min-size-interactive-pointer` and is the min-height of these components. However, there is a discrepancy between the height of these components as implemented in the Codex component library: - Select, TextInput, and components that use TextInput (Combobox, Lookup, TypeaheadSearch) are 32.85px tallSeachInput, and TypeaheadSearch) are 32.84px tall (in [[ https://doc.wikimedia.org/codex/latest/components/overview.html | Codex Demo ]]) - Button, ToggleSwitch, and FilterChipInput are 32px tall - TextInputs with `type="date"` are even taller at 34.84px tall. All TextInputs share the same `line-height`, but something inside the box's content adds an extra 2px to the height of the TextInput with `type="date"`. - Note: There's a discrepancy between changes run on localhost versus [[ https://993763--wikimedia-codex.netlify.app/components/demos/text-input.html#demos | Netlify preview ]]. ### Solution We could fix the too-tall components by reducing the line-height from `line-height-x-small`, a deprecated token, to `line-height-xx-small`, which is what they should be anyway. #### Implications This will cause a slight change in TypeaheadSearch since the height of the input will be reduced. We should ensure that this does not cause a regression, especially between the server-rendered input and the Vue version. This should not be an issue since both versions use the same styles now, but we should note it anyway. --- ### Acceptance criteria - [] Decide how to fix the height discrepancy - [] Implement and test