Page MenuHomePhabricator

[Bug] WVUI Search component does not scale well with font size
Open, LowPublicBUG REPORT


Steps to reproduce

  1. In Chrome, go to Settings and in the "Appearance" section change your "Font size" to "Small" (or "Very small"
  2. Visit
  3. Focus the search input and wait for WVUI to load

Note this will happen in any browser with a configurable font size (not only Chrome).

Expected results

  • The input's container wraps the input in a way that doesn't look broken

Actual results

  • The input's container wraps the input in a way that looks broken

Screen Shot 2021-07-30 at 10.20.58 AM.png (152×2 px, 67 KB)

Environments observed

  • Browser version: Version 92.0.4515.107 (Official Build) (x86_64)
  • OS version: MacOS Big Sur 11.2.3
  • Device model: MacBook Pro
  • Device language: en

Developer notes

This is happening because the search button has a min-height of 32px so while the input height scales with the font-size, the search button stays at a fixed 32px height. One way to fix this would be to set the the same min-height on the input. Alternatively (although probably undesirably based on the comment in the code) is to switch the px to em units or remove the min-height.

.wvui-button {
	box-sizing: border-box;
	// Interactive elements have a minimum touch area.
	min-width: @min-size-base; // 32px
	min-height: @min-size-base; // 32px

Event Timeline

Volker_E added a subscriber: Volker_E.

I have not been in any conversation or seen any request ever for “accessibility” that includes designing for smaller or smallest client settings. This might be a feature in browsers, but in my experience and understanding it's not connected to more accessible interfaces.

WCAG 2.2 draft features the following note:

When using text without specifying the font size, the smallest font size used on major browsers for unspecified text would be a reasonable size to assume for the font. If a level 1 heading is rendered in 14pt bold or higher on major browsers, then it would be reasonable to assume it is large text. Relative scaling can be calculated from the default sizes in a similar fashion.

In my reading it is starting from default styles on browsers, not user overrides to the smaller side.
But as has shown, there's a miniscule group of users (0.17% in the tested set) that go for “small” settings, while not a single “smallest“/“tiny”.

Because of the whole mess of T130691 and using min-width/min-height in px as way around this (not sure if IE 11 would be continuing to be a blocker here, but also probably not worth the further research), I'd suggest as way out to put min-height on search input as well and not further optimize for “small” user setting visually.

Jdlrobson moved this task from Incoming to unsed on the Readers-Web-Backlog board.
Jdlrobson added a subscriber: Jdlrobson.

Design systems team: Was this bug carried over to the Codex version? Since WVUI may be frozen might be worth either resolving this or updating it to be about Codex.

Hi @StevenSun I can reproduce this with the Codex patch and there still seems to be some kind of problem here (although it changes with Codex):

Before focus:

Screen Shot 2022-04-04 at 4.07.02 PM.png (100×818 px, 9 KB)

After focus:

Screen Shot 2022-04-04 at 4.07.11 PM.png (170×872 px, 19 KB)

I see .cdx-text-input__input has height 32px set.

So either Vector needs to also set height 32px for that input, or Codex needs to use em's to define.

We'll need to sync the rule .vector-search-box-vue .vector-search-box-input with the Codex one.