feat: add --vaadin-input-field-height custom CSS property by web-padawan · Pull Request #12574 · vaadin/web-components

web-padawan · 2026-09-01T13:03:01Z

Description

Fixes #12546

Used min-height as agreed in #12546 (comment) to not break text-area and MSCB with autoExpandVertically.

Applied --vaadin-input-field-height as min-height on the vaadin-input-container host in base styles, so the property now works with base styles and Aura, in addition to Lumo
Added the property to the styling tables (.js and .d.ts) of components where it is applicable
Documented in the maxRows JSDoc of text-area that the property is applied as a minimum height and takes priority over the max-height given by maxRows
Added unit tests for the input container, text-area (single row, minRows / maxRows interplay) and visual tests for input-container, text-field, password-field, number-field and single-row text-area
Added a toggle for the property to dev/baseline.html

Type of change

Feature

How to test

Open dev/baseline.html
Check "Set --vaadin-input-field-height & --vaadin-button-height"
All input fields should become 56px tall, with the content vertically centered; the text area grows with its content when it is taller

Note

When the property makes a field taller than its content, the input text is centered in the field but the field's baseline alignment guide still assumes the content height, so baseline-aligned rows (e.g. vaadin-horizontal-layout with align-items: baseline) drift by half the difference. This is a known follow-up. Until then, set --vaadin-field-baseline-input-height to calc((<field height> + <content height>) / 2) on the affected vaadin-text-field / vaadin-select etc. elements themselves, not on :root: text-area, multi-select-combo-box and slider keep their content at the top and would be misaligned by a global value.

🤖 Generated with Claude Code

sonarqubecloud · 2026-09-01T13:14:32Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

vaadin-review-bot

Reviewed the changes — left 1 comment and collected 1 finding below that could not be attached to the diff.

	Finding
⚠️	Multi-select combo box is listed as supporting the property, but its chips and input stay top-aligned in the taller field
📐	The new `maxRows` JSDoc note was not synced to the mixin's `.d.ts`

📐 The new maxRows JSDoc note was not synced to the mixin's .d.ts
CONVENTIONS.md: "Any change in JSDoc descriptions in .js modules needs to be synced to the sibling hand-maintained .d.ts module." The note about --vaadin-input-field-height was added only to vaadin-text-area-mixin.js; the maxRows doc block in the .d.ts still has the old text.
_{vaadin-text-area-mixin.d.ts:76 · conventions}

vaadin-review-bot · 2026-09-01T13:24:21Z

 * | `--vaadin-input-field-error-font-weight`              |
 * | `--vaadin-input-field-error-line-height`              |
 * | `--vaadin-input-field-gap`                            |
+ * | `--vaadin-input-field-height`                         |


⚠️ Multi-select combo box is listed as supporting the property, but its chips and input stay top-aligned in the taller field

The container's #wrapper (holding the prefix, chips and input) has align-self: start, so it keeps its content height while the host grows to the new min-height. The suffix (toggle button) is still centered by align-items: center, so the field renders with the value glued to the top and the button in the middle.

This does not show up in Lumo, where the property is applied to the slotted content instead, and the dev page used for verification has no multi-select combo box on it. Combo box, date picker, time picker and select all center correctly; only this component needs the wrapper to stretch (or center) when the host is taller than its content.

_{vaadin-multi-select-combo-box.js:103 · correctness}

IMO this needs its own follow-up decision. Changing align-self: start breaks "auto expand height" screenshot, and I would prefer to not ship behavior altering changes as part of a feature PR.

web-padawan · 2026-09-01T13:37:32Z

The new maxRows JSDoc note was not synced to the mixin's .d.ts

Fixed.

jouni · 2026-09-02T13:36:56Z

I feel we might want to wait for #12576, so that we can get the baseline alignment working accordingly. I don't think we need to rush this change, and fix the alignment here, as I believe it might get fixed by that PR.

web-padawan · 2026-09-02T14:07:36Z

I feel we might want to wait for #12576, so that we can get the baseline alignment working accordingly.

Sounds good to me. Converted this to draft for now. Let's get back to this after the baseline fix lands.
IMO it's ok to add new custom property during beta for 25.3 as it's a relatively minor feature.

Apply the property as a minimum height on the input container in base styles so that it also works with Aura, in addition to Lumo. There is no default value: the height is defined by the content and the padding unless the property is set. See #12546 for the decision on min-height semantics. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

sonarqubecloud · 2026-09-08T12:27:08Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

web-padawan · 2026-09-08T12:28:37Z

@jouni rebased this PR now when the baseline fix is merged. PTAL so we could include it in the next 25.3 beta.

vaadin-review-bot

Reviewed the changes — left 1 comment.

	Finding
📝	The baseline-alignment caveat of the new property is only written down in the PR description

vaadin-review-bot · 2026-09-08T12:37:27Z

  :host {
    display: flex;
    align-items: center;
+    min-height: var(--vaadin-input-field-height, auto);


📝 The baseline-alignment caveat of the new property is only written down in the PR description

With base styles / Aura, the field's baseline guide (:host::before in field-base-styles.js) keeps using 1lh + padding + border, so a field made taller by the property misaligns with adjacent text in a baseline-aligned row by half the extra height. Lumo does not have this problem because its :host::before height already resolves --vaadin-input-field-height.

The PR description covers this and names the workaround, but nothing a consumer can read does: the styling tables only list the property name, and --vaadin-field-baseline-input-height — the property the workaround relies on — appears in no styling table at all. A Note, paragraph in the field JSDoc (next to the existing input-prevented note) would carry it, together with documenting the escape hatch.

_{vaadin-input-container-base-styles.js:13 · documentation}

IMO let's not document --vaadin-field-baseline-input-height property, as it's internal.

Possible follow-up for baseline: feat/input-field-height-property...proto/baseline-guide

No one should need to fiddle with --vaadin-field-baseline-input-height, but it is there as an escape hatch if the calculations don't work and alignment is off by some pixels.

web-padawan force-pushed the feat/input-field-height-property branch 4 times, most recently from d3462da to cc5c4d0 Compare September 1, 2026 13:13

web-padawan marked this pull request as ready for review September 1, 2026 13:16

web-padawan requested a review from jouni September 1, 2026 13:16

vaadin-review-bot reviewed Sep 1, 2026

View reviewed changes

web-padawan force-pushed the feat/input-field-height-property branch from cc5c4d0 to 88d6c5f Compare September 1, 2026 13:34

web-padawan marked this pull request as draft September 2, 2026 14:06

web-padawan force-pushed the feat/input-field-height-property branch from 88d6c5f to aace960 Compare September 8, 2026 12:25

web-padawan marked this pull request as ready for review September 8, 2026 12:28

web-padawan added the target/25.3 label Sep 8, 2026

vaadin-review-bot reviewed Sep 8, 2026

View reviewed changes

Uh oh!

Conversation

web-padawan commented Sep 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Type of change

How to test

Uh oh!

sonarqubecloud Bot commented Sep 1, 2026

Quality Gate passed

Uh oh!

vaadin-review-bot left a comment

Choose a reason for hiding this comment

Uh oh!

vaadin-review-bot Sep 1, 2026

Choose a reason for hiding this comment

Uh oh!

web-padawan Sep 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

web-padawan commented Sep 1, 2026

Uh oh!

jouni commented Sep 2, 2026

Uh oh!

web-padawan commented Sep 2, 2026

Uh oh!

sonarqubecloud Bot commented Sep 8, 2026

Quality Gate passed

Uh oh!

web-padawan commented Sep 8, 2026

Uh oh!

vaadin-review-bot left a comment

Choose a reason for hiding this comment

Uh oh!

vaadin-review-bot Sep 8, 2026

Choose a reason for hiding this comment

Uh oh!

web-padawan Sep 8, 2026

Choose a reason for hiding this comment

Uh oh!

web-padawan Sep 8, 2026

Choose a reason for hiding this comment

Uh oh!

jouni Sep 10, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

web-padawan commented Sep 1, 2026 •

edited

Loading

web-padawan Sep 1, 2026 •

edited

Loading