WordPress.org

Make WordPress Core

Opened 9 years ago

Closed 7 years ago

Last modified 7 years ago

#7763 closed enhancement (fixed)

CSS for login/register page could be more robust

Reported by: richardkmiller Owned by: Nicholas91
Milestone: 3.1 Priority: normal
Severity: minor Version: 2.8
Component: UI Keywords: has-patch needs-testing dev-feedback
Focuses: Cc:

Description

I'm using the register_form hook to add custom fields to the registration page. However, my new fields don't inherit the styles from the default style sheet (wp-includes/css/login.css).

The attached patch would make the CSS for the login and register forms more robust, by applying the styles to ALL fields in the form.

Before:

#user_pass, #user_login, #user_email {

After:

#registerform input, #registerform textarea, #loginform input, #loginform textarea {

Attachments (3)

login.css.diff (445 bytes) - added by richardkmiller 9 years ago.
7763.diff (486 bytes) - added by wojtek.szkutnik 7 years ago.
login.dev.css.diff (336 bytes) - added by joelhardi 7 years ago.
patch to wp-admin/css/login.dev.css (see my comment)

Download all attachments as: .zip

Change History (15)

#1 @Nicholas91
8 years ago

  • Cc dragos.nicholas@… added
  • Keywords has-patch needs-testing added
  • Owner changed from anonymous to Nicholas91

#2 @Nicholas91
8 years ago

  • Milestone changed from 2.8 to 2.9

Moving to 2.9.

#3 @Denis-de-Bernardy
8 years ago

  • Component changed from General to UI

#4 @Denis-de-Bernardy
8 years ago

  • Keywords needs-patch reporter-feedback added; has-patch needs-testing removed
  • Milestone changed from 2.9 to Future Release

patch is broken. also, can you confirm the issue is still relevant in 2.8?

#5 @scribu
8 years ago

  • Keywords reporter-feedback removed
  • Severity changed from normal to minor

Still relevant for 2.9.

#6 @wojtek.szkutnik
7 years ago

  • Cc wojtek.szkutnik@… added
  • Keywords has-patch gsoc needs-testing added; needs-patch removed

@wojtek.szkutnik
7 years ago

#7 @wojtek.szkutnik
7 years ago

Issue confirmed for trunk, the patch fixes it and doesn't break submit buttons compared to the previous one

#8 @joelhardi
7 years ago

  • Cc joelhardi added
  • Version changed from 2.6.1 to 3.1

Hi, I would like to jump in on this bug and say:

  • This issue is still valid in trunk/3.1. IMHO it's a bug, not enhancement. Granted, it's not a crash, but I find this bug very annoying as a plugin developer because I can't just add a field to the login/registration/etc. forms and set class="input" to inherit the default styles.
  • I've attached what I think is a simpler/better patch to fix.

Ideally, would just have a rule for .input to style HTML input elements that are given class="input".

This works, except for the background color, because the style for form sets background to #fff. So, my rule prepends body and form to .input to take precedence in the cascade. Since all <input> elements should be inside the <body> and <form> on these pages, it works without having to be placed inside particular IDs like previous patches.

-#user_pass,
-#user_login,
-#user_email {
+body form .input {

@joelhardi
7 years ago

patch to wp-admin/css/login.dev.css (see my comment)

#9 @joelhardi
7 years ago

  • Keywords dev-feedback added; gsoc removed

Just a retag in hopes of reviving this old bug up (please chastise me if I'm abusing the bug tracker) and getting a commit.

This seems like a pretty minor change. The username, email and password fields already have class="input" so it's simply a matter of applying the style to this class rather than to the individual id of every single text input on the form. No HTML edits necessary.

To me, this is a CSS/markup best practice, and as a plugin dev it means I can add additional fields to these forms (i.e. if I want to allow the user to register a URL, or want to require a captcha) and just do class="input" to get them to match the style of the other input fields. It also means I can change the HTML ID attributes of these fields if I need to (for instance, I have an anti-reg spam reason for doing this) without them losing their styling.

I've tested my patch across all browsers and don't see where there could be any breakage or bad side effects. The new CSS declaration is just a straight-up CSS1 descendant selector that's been supported since at least IE 5.5. And it saves 20 bytes.

#10 @scribu
7 years ago

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

(In [15643]) Make login css more flexible. Props joelhardi. Fixes #7763

#11 @scribu
7 years ago

  • Milestone changed from Future Release to 3.1
  • Version changed from 3.1 to 2.8

#12 @joelhardi
7 years ago

awesome, many thanks!

Note: See TracTickets for help on using tickets.