#7763 closed enhancement (fixed)
CSS for login/register page could be more robust
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| 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)
Change History (15)
#1
@
16 years ago
- Cc dragos.nicholas@… added
- Keywords has-patch needs-testing added
- Owner changed from anonymous to Nicholas91
#4
@
16 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
@
15 years ago
- Keywords reporter-feedback removed
- Severity changed from normal to minor
Still relevant for 2.9.
#6
@
14 years ago
- Cc wojtek.szkutnik@… added
- Keywords has-patch gsoc needs-testing added; needs-patch removed
#7
@
14 years ago
Issue confirmed for trunk, the patch fixes it and doesn't break submit buttons compared to the previous one
#8
@
14 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 {
#9
@
14 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.
Moving to 2.9.