Password protected content: password form styling and UX improvements

[Nyiriland]

This is specifically referring to the form seen when trying to view a password-protected page or post.

The current password protection form currently uses default browser html form styles, though it would be expected to inherit form styling from theme.

Suggestions for improvements:

• Refactor form to inherit input, label and submit button styles from theme.
• Improve form accessibility by allowing users to toggle password visibility.

[joedolson]

Core does not provide any CSS styling for the password form. As it is, it will inherit any styles that the theme provides. If the theme does not provide any general styling for form inputs, it could end up with browser styling, but that would be due to gaps in the theme's styling - there's nothing core can do to ensure that theme styles apply to this form.

I'm a bit curious about the suggestion that this form only inherits browser styling and *doesn't* inherit theme styling; that would be very unusual. Do you have an example of this?

When it comes to including a password visibility toggle on this form, I don't think that's really feasible. Trying to create styles that will universally work in any theme isn't really doable; it's up to the theme to implement this.

In my opinion, this ticket should be closed. The first part is invalid, and the second part is just not really feasible.

[Nyiriland]

Apologies for not attaching visual documentation previously (was a hurried submission).

I'm a bit curious about the suggestion that this form only inherits browser styling and *doesn't* inherit theme styling; that would be very unusual. Do you have an example of this?

In regards to the form styling, I'm specifically saying the password form doesn't inherit the theme's global styles. Mainly, the submit button:

You can also see that in the markup above, the password input element is nested within the label element, which while technically valid, doesn't match the input/label markup pattern of the default comment form:

At the least, I think changing the markup to inherit the theme's global block button styles could be a welcome improvement:

[joedolson]

OK; I think I see what you're requesting now. This is specific to block themes, which don't handle styles the same way as classic themes.

It may be an option to add classes to this form so that block styles can apply, although there are some complicating factors - it's not a block, so variant classes that might get applied elsewhere won't be applied.

The nested label/input pattern is for historic compatibility. This is an old form, and making changes like that can have significant backwards compatibility issues.

But it's worth thinking about for block themes.

[sabernhardt]

Related issues on the Gutenberg repository:

1. ​Add 'wp-element-button' class to the submit input
2. ​Create a template for password protected pages
3. ​Create a block for the post password form

Adding the .wp-element-button class if wp_is_block_theme() seems to be a simple way to bring theme styles to one element of the form. If the theme.json also includes styles for textInput elements (support added in 6.9), those should apply to the password field.

[poena]

Adding the .wp-element-button class if wp_is_block_theme() seems to be a simple way to bring theme styles to one element of the form

I created the Gutenberg PR, but in the 7.1 compat folder.
In core, I suppose the change should be made in ​https://developer.wordpress.org/reference/functions/get_the_password_form/

[joedolson]

These changes seem very feasible for 7.1, so I'm going to go ahead and milestone.

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

[sabernhardt]

Related: #65567

[wildworks]

Should we close this ticket as a duplicate of #65567? The linked PRs both contain similar changes.

​https://github.com/WordPress/wordpress-develop/pull/11642/
​https://github.com/WordPress/wordpress-develop/pull/12374/

[wildworks]

#65567 was marked as a duplicate.

I plan to commit this PR today, and I will adopt part of the approach taken in #12374. Specifically, I will add logic to explicitly enqueue styles for buttons, as they might not be enqueued otherwise when a page does not have a button block.

[wildworks]

In 62754:

Posts, Post Types: Style password form button in block themes.

When a block theme is active, wrap the post password form's submit button in a wp-block-button span and add the wp-block-button__link class along with the theme's button element class name, so it is styled consistently with other buttons output by the theme. The wp-block-button stylesheet is explicitly enqueued when registered, as it may not otherwise be present on pages without a Button block.

Props apermo, mukesh27, sukhendu2002, poena, wildworks.
Fixes #64569.