WordPress.org

Make WordPress Core

Opened 4 months ago

Closed 4 months ago

Last modified 4 months ago

#52083 closed defect (bug) (fixed)

Twenty Twenty-One: Input fields do not have a max-width by default

Reported by: kjellr Owned by: ryelle
Milestone: 5.6.1 Priority: normal
Severity: normal Version: 5.6
Component: Bundled Theme Keywords: has-patch, twenty-twenty-one-1.1
Focuses: css Cc:

Description

In Twenty Twenty-One, input text fields do not have a default width by default. This means they can easily extend beyond the width of the viewport.

They do inherit this global rule:

header *,
main *,
footer * {
	max-width: var(--global--spacing-measure);
}

... but that --global--spacing-measure variable is undefined so it has no effect.

By contrast, the theme does provide a width value of 100% for textareas, so the problem does not exist for those:

https://cldup.com/15ffziP1eo.png


Tested with Twenty Twenty-One 1.0
WordPress 5.6

Originally reported in the support forums:
https://wordpress.org/support/topic/form-input-fields-fixed-width/

Change History (21)

#1 @poena
4 months ago

  • Keywords needs-patch added

This ticket was mentioned in Slack in #core-themes by poena. View the logs.


4 months ago

#3 @desrosj
4 months ago

  • Milestone changed from Awaiting Review to 5.7

#4 @desrosj
4 months ago

  • Version set to 5.6

This ticket was mentioned in Slack in #core-themes by poena. View the logs.


4 months ago

#6 @poena
4 months ago

I can see that there is no max-width set for the input elements themselves, but I am not able to reproduce the issue.

Tested on Windows 10, Chrome Version 87.0.4280.88.

From the link in the support forum topic, I was able to see that the form in the image is created with
Contact form 7.
But I am not able to reproduce it when viewing the website from the support forum topic,
nor when I test with and without the plugin locally (Plugin version 5.3.2).

When I manually add input elements to the HTML block, the max-width is adjusted by:

.post-thumbnail, .entry-content .wp-audio-shortcode, .entry-content > *:not(.alignwide):not(.alignfull):not(.alignleft):not(.alignright):not(.wp-block-separator):not(.woocommerce), *[class*=inner-container] > *:not(.entry-content):not(.alignwide):not(.alignfull):not(.alignleft):not(.alignright):not(.wp-block-separator):not(.woocommerce), .default-max-width {
    max-width: var(--responsive--aligndefault-width);
    margin-left: auto;
    margin-right: auto;
}

#7 @ryelle
4 months ago

I can reproduce this both with Contact Form 7, and with the following HTML. I needed to use the responsive view in Chrome's dev tools, just resizing the browser doesn't get it small enough (<400px).

<form>
<input type="text" size="40" />
</form>

The issue is that there's a size set, so it's a fixed size, and like @kjellr mentioned, the max-width is unset - I think that's meant to make sure the max-width inherits from the parent container, but instead it's just none.

This ticket was mentioned in PR #827 on WordPress/wordpress-develop by ryelle.


4 months ago

  • Keywords has-patch added; needs-patch removed

Inputs with a set size attribute are not correctly resized on very small screens. For example, if an input is 40 characters wide, when the screen goes smaller than 400px, it scrolls offscreen. This adds a max-width to cap the width to the container size.

Before:
https://i0.wp.com/user-images.githubusercontent.com/541093/102641913-e0bf5700-412a-11eb-83a5-88ac04453748.png

After:
https://i0.wp.com/user-images.githubusercontent.com/541093/102641911-e0bf5700-412a-11eb-98ec-0fa51d812e38.png

Trac ticket: https://core.trac.wordpress.org/ticket/52083

#9 @sabernhardt
4 months ago

The patch could be good enough for now, if we want a quick fix.

If the --global--spacing-measure variable is ever defined, though, the header *, main *, footer * style will override the max-width this patch assigns to the inputs.

#10 @ryelle
4 months ago

--global--spacing-measure is defined, the value is `unset` - which is meant to reset the max-width to the parent, which is none in this case.

Also, main * has less specificity than input[type], so even if the value for --global--spacing-measure is changed, it won't affect the max-width here.

#11 @kjellr
4 months ago

--global--spacing-measure is defined, the value is unset - which is meant to reset the max-width to the parent, which is none in this case.

Good catch — I missed that declaration somehow.

And thanks for the patch! It looks good. 👍

#12 @sabernhardt
4 months ago

I don't see any problems now. It must have been because I tried editing in the browser or made some other mistake.

This ticket was mentioned in Slack in #core-themes by desrosj. View the logs.


4 months ago

#14 @desrosj
4 months ago

  • Milestone changed from 5.7 to 5.6.1

Moving this to 5.6.1. If it can be properly tested before the 1.1 version of the theme is bundled later today, it's worth including.

This ticket was mentioned in Slack in #core-themes by poena. View the logs.


4 months ago

#16 @poena
4 months ago

I have tested the PR with Chrome, Firefox and Edge (with the dev tools device emulators) on Windows 10 without issues.

This ticket was mentioned in Slack in #themereview by poena. View the logs.


4 months ago

#18 @ryelle
4 months ago

  • Owner set to ryelle
  • Resolution set to fixed
  • Status changed from new to closed

In 49870:

Twenty Twenty-One: Set a maximum width on inputs.

Text inputs with a size attribute can end up longer than the screen width on small screens. A max-width of 100% keeps the inputs from breaking out of the container.

Props basscan, kjellr, poena, sabernhardt
Fixes #52083.

#19 @ryelle
4 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening to backport.

#20 @ryelle
4 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 49871:

Twenty Twenty-One: Set a maximum width on inputs.

Text inputs with a size attribute can end up longer than the screen width on small screens. A max-width of 100% keeps the inputs from breaking out of the container.

Props basscan, kjellr, poena, sabernhardt.
Merges [49870] to the 5.6 branch.
Fixes #52083.

#21 @desrosj
4 months ago

  • Keywords twenty-twenty-one-1.1 added

Adding a custom keyword for querying tickets included in the Twenty Twenty-One version 1.1 release in the future.

Note: See TracTickets for help on using tickets.