Page MenuHomePhabricator

TextInput should have relative height
Open, MediumPublic

Description

Background

Currently, all input elements in Codex inherit an absolute height of 32px from their parent cdx-text-input.

Screenshot 2022-06-22 at 10.32.06.png (316×792 px, 54 KB)

Using absolute units in this context becomes problematic, since they prevent the components from adjusting when the font size of the browser is increased (e.g. to "Very large" in Chrome, to "24" in Safari – which are default options provided by said browsers). The inputs become too narrow and, in the case of Safari, hardly usable.

TahS in Chrome's "Very large" font configurationTahS in Safari's 24px font configuration
Screenshot 2022-06-22 at 10.37.47.png (560×1 px, 113 KB)
Screenshot 2022-06-22 at 10.45.17.png (1×2 px, 260 KB)

Goal

Inputs should scale to display correct proportions and proper spacing around their values. A good example of this would be the current vector 2022/WVUI TypeaheadSearch component:

Screenshot 2022-06-22 at 10.40.26.png (1×2 px, 698 KB)

Considerations

We might want to still specify 32px as a min-height instead. This way, inputs will be correctly resized thanks to the increase of their relative line height.
Specifying a min-height will also ensure that Codex components maintain this base system size in contexts where font size is reduced (e.g. Monobook skin).

ACs

  • The height of Codex input components increases proportionally with font size

Event Timeline

Change 808074 had a related patch set uploaded (by VolkerE; author: VolkerE):

[design/codex@main] styles, TextInput: Use `min-height-base` instead of `height-base`

https://gerrit.wikimedia.org/r/808074

In this powerful DS team one has to be quick to report issues. Have seen this a while ago, but was planning to amend it accordingly to size and spacing tokens.
As it's an accessibility issue (which is easy to fix) it makes sense to prioritize this though. Thanks Sarai!

Volker_E renamed this task from Codex inputs should have relative heights to TextInputs should have relative heights.Thu, Jun 23, 9:40 PM

Change 808074 merged by jenkins-bot:

[design/codex@main] styles, TextInput: Use `min-height-base` instead of `height-base`

https://gerrit.wikimedia.org/r/808074

Thanks, @Volker_E! While creating the ticket, I also thought this would be solved with the introduction of Codex's spacing tokens, but it seemed necessary to document this in any case just to be safe 🙏🏻

I noticed that the line height of text-input and derivates has a greater value in Safari, which results in a bigger input size 🤔 It might be related to the compounding effect: the browser indicates that the component has a font-size of 'inherited' and replacing this value by 24px or 1.5em makes it look as expected. Not sure of how this could be fixed 😕

Screenshot 2022-06-27 at 12.24.22.png (556×2 px, 114 KB)

Sarai-WMDE renamed this task from TextInputs should have relative heights to TextInput should have relative heights.Mon, Jun 27, 3:43 PM

Thanks, @Volker_E! While creating the ticket, I also thought this would be solved with the introduction of Codex's spacing tokens, but it seemed necessary to document this in any case just to be safe 🙏🏻

I noticed that the line height of text-input and derivates has a greater value in Safari, which results in a bigger input size 🤔 It might be related to the compounding effect: the browser indicates that the component has a font-size of 'inherited' and replacing this value by 24px or 1.5em makes it look as expected. Not sure of how this could be fixed 😕

Screenshot 2022-06-27 at 12.24.22.png (556×2 px, 114 KB)

Where are you testing this? macOS/iOS? It looks like you've increased the text size in your screenshot.
We're not beautifying anything <> 100%, we just make sure that it's usable.

Our demos currently use -webkit-text-size-adjust: 100%. We could, for iOS, consider -webkit-text-size-adjust: none;

Sarai-WMDE renamed this task from TextInput should have relative heights to TextInput should have relative height.Tue, Jun 28, 3:06 PM

Sorry for not specifying: this was detected checking in Safari 15.5 on MacOS Monterey. And yes, the browser font was increased to test – as specified in the task description and AC – whether the input component increased proportionately in height to accommodate the bigger size. Fair enough if we don't want to "beautify" things and just make them work: the comment was more related to consistency (making sure that TextInput maintained the same proportions across browsers) and to the need to meet the existing component's behavior/styling under the same conditions.

Regarding the latter, the difference in size between the adjusted Codex component and the production TahS isn't big (around 9px):

Screenshot 2022-06-28 at 17.16.55.png (1×2 px, 650 KB)

It'd be great to reach the mentioned double consistency, but I'd understand if this wasn't considered a priority now.

The sizing issue detected in Safari 15.5 has been captured in a separate ticket: T311636. With that, and after checking that TextInput is now relatively sized and can accommodate larger browser font-sizes, this task can be signed-off.
Tested in Firefox v10, Chrome v103 on MacOS Monterey, for font sizes of 18px, 20px and 24px.

ldelench_wmf raised the priority of this task from Low to Medium.Wed, Jun 29, 5:29 PM