Make WordPress Core

Opened 15 years ago

Closed 11 years ago

Last modified 11 years ago

#12506 closed task (blessed) (fixed)

Standalone login styles

Reported by: f-j-kaiser's profile F J Kaiser Owned by: helen's profile helen
Milestone: 3.9 Priority: low
Severity: minor Version: 2.9.2
Component: Login and Registration Keywords: has-patch
Focuses: ui Cc:

Description

On wp-login.php we are already on admin, because wp is loading the whole color-scheme for a user... which is wrong. It is senseless, because the color-scheme the user selected for admin cannot be loaded without his user-data. And that is not possible as long as he/she didn't enter any login-data.

REQUEST: get the ~30kB color scheme out of the wp-login.php and add the following to wp-admin/css/login.css:

body.login {
    border-top-color:#464646;
}
body, #wpbody, .form-table .pre {
    color:#333333;
}
a, /* All obsolete on wp-login.php - could here simply be h1 a */
#adminmenu a,
#poststuff #edButtonPreview,
#poststuff #edButtonHTML,
#the-comment-list p.comment-author strong a,
#media-upload a.del-link,
#media-items a.delete,
.plugins a.delete,
.ui-tabs-nav a {
    color:#21759B;
}
.submit {
    border-color:#DFDFDF;
}
textarea, /* All obsolete - could be #login #wp-submit */
input[type="text"],
input[type="password"],
input[type="file"],
input[type="button"],
input[type="submit"],
input[type="reset"],
select {
    background-color:#FFFFFF;
    border-color:#DFDFDF; /* Obsolete due to .submit-class above */
}
input.button-primary, button.button-primary, a.button-primary {
    -moz-background-clip:border;
    -moz-background-inline-policy:continuous;
    -moz-background-origin:padding;
    background:#21759B url(../images/button-grad.png) repeat-x scroll left top;
    border-color:#298CBA;
    color:#FFFFFF;
    font-weight:bold;
    text-shadow:0 -1px 0 rgba(0, 0, 0, 0.3);
}
.submit {
    border-color:#DFDFDF;
}
.login #nav a {
    color:#21759B !important;
}
.login #backtoblog a {
    color:#CCCCCC;
}

Attachments (7)

login.css (2.3 KB) - added by F J Kaiser 15 years ago.
should do his work, but not tested
login.2.css (2.8 KB) - added by F J Kaiser 14 years ago.
Tested for cases: login, lost password, error-messages on both screens. should work for most plugins that keep the present scheme.
login.3.css (3.6 KB) - added by F J Kaiser 14 years ago.
Uploaded the wrong (old) file and forgot to mention some things: * Added some lines at top of the file to remove the dotted lines around links and buttons, when they get klicked. * Added a basic color-definition (#333) for cases where a plugin writes something directly into the page. * Added a class for the nav-links at the bottom of the form, so plugins can scale easier (.login_link). * Added a class for the input-fields, so we can have IDs for specific targetting and a class for plugin- and basic-fields (input.user_data).
login.4.css (3.6 KB) - added by F J Kaiser 14 years ago.
one text-shadow too much, and one :hover-state forgotten.
login-dev-css.patch (6.1 KB) - added by F J Kaiser 14 years ago.
now with the file from core (3.0).
login-css+wp-login.patch (9.7 KB) - added by F J Kaiser 14 years ago.
includes: css reworked & the minor changes to wp-login.php that are needed
12506.diff (3.0 KB) - added by helen 11 years ago.

Download all attachments as: .zip

Change History (46)

#1 @F J Kaiser
15 years ago

  • Keywords css admin login.css wp-login.php added
  • Version set to 2.9.2

Due to the fact, that login.css get's only loaded on the wp-login.php page, a lot of the selectors could be downstripped to simple html-selectors like "h1 a" for the logo.

A big + would be, that the large amount of selectors and definitions in the color-scheme could not anymore interfer with plugins loading custom login-styles. That would make styling the login a lot easier and make smaller files (= faster loading time).

@F J Kaiser
15 years ago

should do his work, but not tested

#2 @F J Kaiser
15 years ago

  • Type changed from feature request to defect (bug)

Du to wrong loading of something that shouldn't be here, i call this a bug.

#3 @F J Kaiser
15 years ago

  • Milestone changed from Unassigned to 3.0

#4 @dd32
15 years ago

I do not see the problem with including the fresh colour scheme for the login page. Users can choose to have a different colour scheme for the admin interface, that doesnt apply to the login form, as like you say, it doesnt know the user yet.

Moving the colour styles to login.css will mean duplicating the styles in 2 locations, whereas, at present, the colour scheme can be defined once.

#5 @F J Kaiser
15 years ago

I get your point (partly), but i can't agree. Let one thing do it's specific stuff and not only part of it.

At +/- 30kB i don't argue with loading time. But i do say, that it's unneccassary and doesn't help anyone. There are 2 scenarios i can imagine: a) Someone extends the data/input fields with a plugin or custom code. There she/he needs only the styles i wrote in my initial text. b) Someone makes a custom login page. In this scenario it's likely, that admin-css and login.css will be completly dropped and replaced by something that fits a theme.

If you start wp, you no near nothing about php, mysql and often pretty less than nothing from html to css. This doesn't mean you can't use wp (themes, plugins, 5 min. installation). But when you start diggin into code, it's getting hard. And the starting point is nearly everytime css. So let's keep things clear, easy and separated in case, someone want's to change something (even plugin authors would have an easier life with such a slim css file).

I gave you 3 reasons why i see this neccassary: Size, Structure (separated code - it's not part of /wp-admin) and useability/3rd party friendly. The only point i could really see in your argument "the color scheme can be defined once", if the wp-login.php would make use of more than just the button-style. (Here goes a last one: we save bandwidth).

#6 @F J Kaiser
15 years ago

and another argument (which is in parts already in the other ones written above): separating things makes tearing them apart and exchanging things easier. Currently there are a lot of things changing in wp and the wp-login.php could surely be a stand alone to.

#7 @rmccue
15 years ago

  • Cc me@… added
  • Keywords login has-patch needs-testing added; login.css wp-login.php removed

#8 @nacin
14 years ago

  • Keywords needs-patch added; css admin login has-patch needs-testing removed
  • Milestone changed from 3.0 to Future Release
  • Priority changed from normal to low
  • Resolution set to fixed
  • Severity changed from normal to minor
  • Status changed from new to closed
  • Type changed from defect (bug) to enhancement

Still not convinced here, but it needs a proper patch, which should be uncompressed and also remove unneeded styles out of the color css file as appropriate.

@F J Kaiser
14 years ago

Tested for cases: login, lost password, error-messages on both screens. should work for most plugins that keep the present scheme.

#9 @F J Kaiser
14 years ago

The new patch works in my test-scenario as expected.

Description of what i did, so other contributers can understand my patch easier:

  • I added 3 classes for messages: .plugin-message, .plugin-message-yellow, .plugin-message-error. Those are there, so plugin code can be marked easier and the wp-login.php should be a bit easier readable in the sourcecode.
  • Changed the vertical-alignment of the #backtoblog link.
  • Reordered all code, so the file is (hopefully) even in the compressed version easier search and readable. For ex.: padding-top: 3px; padding-bottom: 5px; padding-left: 9px; > padding: 3px 0 5px 9px; and so on. Same to font, border, margin. Further the file now has with all IDs/classes the same order at the definitions.

Sidenotes about furter enchancements for wp-login.php:

  • I was looking at all the <p>-tags for messages and links. But when i tried the error-handling i found the error-messages sitting in a <div>-tag. I would prefer divs or spans for all messages. In my test-scenarion there was no change, because i targeted most stuff at their class and not the html-tag. Divs and spans offer more possibilities than Paragraph tags. I think the Paragraphes should all get Divs or spans.
  • The error-message is the only message i found, that has an ID instead of a class. Other error-messages for plugins are that way impossible. I tried to get around that too with the plugin-* classes. Other ideas are welcome.

@F J Kaiser
14 years ago

Uploaded the wrong (old) file and forgot to mention some things: * Added some lines at top of the file to remove the dotted lines around links and buttons, when they get klicked. * Added a basic color-definition (#333) for cases where a plugin writes something directly into the page. * Added a class for the nav-links at the bottom of the form, so plugins can scale easier (.login_link). * Added a class for the input-fields, so we can have IDs for specific targetting and a class for plugin- and basic-fields (input.user_data).

@F J Kaiser
14 years ago

one text-shadow too much, and one :hover-state forgotten.

#10 @F J Kaiser
14 years ago

  • Cc 24-7@… added

@F J Kaiser
14 years ago

now with the file from core (3.0).

#11 @nacin
14 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

I didn't mean to close this.

@F J Kaiser
14 years ago

includes: css reworked & the minor changes to wp-login.php that are needed

#12 @F J Kaiser
14 years ago

  • Keywords css admin login has-patch needs-testing added; needs-patch removed

@nacin: n/p. Added the patch for both files now. Maybe you (or anyone else) wants to add some keywords.

#13 @F J Kaiser
14 years ago

  • Owner set to F J Kaiser
  • Status changed from reopened to assigned

#14 @F J Kaiser
14 years ago

  • Owner F J Kaiser deleted

I hope i didn't get this part of the workflow too wrong: I now un-assigned this, because i got no 3.0-installation. The next owner will be the one, who makes the test? Thanks for any info about the workflow (still learning).

#15 @F J Kaiser
14 years ago

  • Owner set to F J Kaiser

Reassigned to me, because no one seems to care about this since a half year...

#16 @bueltge
14 years ago

  • Cc frank@… added

+100, makes easy to inlcude this on frontend

#17 @ocean90
13 years ago

  • Keywords css admin login removed

I think this needs some refresh.

#18 @F J Kaiser
13 years ago

  • Owner changed from F J Kaiser to ocean90

:)

#19 @ocean90
12 years ago

  • Owner ocean90 deleted
  • Status changed from assigned to reviewing

#20 @jeremyfelt
11 years ago

  • Component changed from Administration to Login and Registration
  • Focuses ui added

#21 follow-up: @nacin
11 years ago

  • Keywords close added

The new plan is to merge colors.css into wp-admin.css. Then color schemes will load over that, only in the admin (not on login). I believe that would render this suggestion moot. Suggesting we close this as a duplicate of #18380.

#22 in reply to: ↑ 21 @F J Kaiser
11 years ago

Replying to nacin:

The new plan is to merge colors.css into wp-admin.css. Then color schemes will load over that, only in the admin (not on login). I believe that would render this suggestion moot.

Yep, it's out of scope then.

Suggesting we close this as a duplicate of #18380.

As this was about breaking out/separating login styles away from admin, I would just close it without marking it as duplicate. The motivation behind it was to see login as the 3rd part of WP (public/theme - login - admin) and therefore allowing more customization.

Last edited 11 years ago by F J Kaiser (previous) (diff)

#23 follow-up: @nacin
11 years ago

  • Keywords close removed
  • Milestone changed from Future Release to 3.9

Hmm, actually, if we're going to merge it in, then we'll actually need to do this. Otherwise we'd have to load wp-admin.css.

#24 in reply to: ↑ 23 ; follow-up: @F J Kaiser
11 years ago

Replying to nacin:

Hmm, actually, if we're going to merge it in, then we'll actually need to do this. Otherwise we'd have to load wp-admin.css.

It's a little bit like reading JavaScript: What does this refer to? :)

#25 in reply to: ↑ 24 @helen
11 years ago

Replying to F J Kaiser:

What does this refer to? :)

The ticket. Sounds like some colors will need merging into login styles, not just wp-admin.css, so we should be mindful of that and be sure to test it. Can keep this open for tracking.

#26 @helen
11 years ago

  • Owner set to helen
  • Status changed from reviewing to accepted
Version 0, edited 11 years ago by helen (next)

#27 @helen
11 years ago

  • Summary changed from admin-color-scheme.css already loaded on wp-login.php. why? to Merge colors into login styles as applicable

#28 follow-up: @helen
11 years ago

  • Summary changed from Merge colors into login styles as applicable to Standalone login styles

Sorry @F J Kaiser, I think nacin and I confused ourselves and then you. We both thought that there were still separated login styles in the head and just colors were loaded, not the whole wp-admin.css. We'll make this better along with the CSS split in #26669 - I'll leave a note over there as well as in my own notes so we don't forget.

#29 in reply to: ↑ 28 ; follow-up: @F J Kaiser
11 years ago

Replying to helen:

Sorry @F J Kaiser, I think nacin and I confused ourselves and then you.

No one was injured during this.

Any plan how proceed on this one?

#30 in reply to: ↑ 29 ; follow-up: @nacin
11 years ago

Replying to F J Kaiser:

Any plan how proceed on this one?

Helen is painstakingly, line-by-line, merging colors.css into wp-admin.css. That should be completed in the new few days. After that, we'll re-group in #26669 to begin splitting wp-admin.css into separate files. All of those files will be concatenated on build — except one, which would be a new login.css file. It's possible that we'll want a base CSS file to be concatenated into both wp-admin.css and login.css, like form styling or something.

At this point, I'd call it on-hold until colors.css is merged. That's taking place in #18380. If after that lands you want to identify which rules we need for wp-login.php (essentially updating your work from years ago), that would help move this along. Otherwise it'll just be lumped into the tasks in #26669, which are also going to be pretty painstaking.

#31 in reply to: ↑ 30 @F J Kaiser
11 years ago

Replying to nacin:

(...) splitting wp-admin.css into separate files. All of those files will be concatenated on build — except one, which would be a new login.css file.

Sounds good.

At this point, I'd call it on-hold

Ok for me. Sadly that we ain't got a "blocked" tag. Would be nice to have blocked #12345 or similar.

If after that lands you want to identify which rules we need for wp-login.php (essentially updating your work from years ago), that would help move this along.

Just ping that ticket - I'm subscribed. We can then discuss further steps, depending on the outgoing of the related tickets.

@helen
11 years ago

#32 @helen
11 years ago

In 27199:

Make login styles standalone. see #12506.

#33 @helen
11 years ago

In 27200:

Login styles do not depend on common.css. see #12506.

#34 follow-up: @helen
11 years ago

  • Keywords needs-testing removed

I did not change the current selectors for login styling - I'm not sure we really need to or should, but open to more discussion. I'm also leaving the ticket open as I did not do any detailed testing of non-core login form additions, so we may need to tweak a bit.

#35 @mrtortai
11 years ago

This looks good.

12506.diff caused a small issue with #26879 which relied on wp-admin.css. This has been fixed in 26879-7.patch which now uses login.css instead.

#36 in reply to: ↑ 34 @F J Kaiser
11 years ago

Nice to see progress.

Replying to helen:

I did not change the current selectors for login styling - I'm not sure we really need to or should, but open to more discussion.

There are quite some inconsistencies in the generated MarkUp by wp-login.php, which we should prepare to remove. Example:

echo '<div id="login_error">' . apply_filters( 'login_errors', $errors ) . "</div>\n";
echo '<p class="message">' . apply_filters( 'login_messages', $messages ) . "</p>\n";

IDs vs. classes or assuming one vs. many.

The naming scheme in place is equally inconsistent, see those examples for "password":

<form id="lostpasswordform"
<form id="resetpassform"
<p class="message reset-pass">
<input type="password" name="pass1" id="pass1"
<input type="password" name="pass2" id="pass2"
<div id="pass-strength-result"
<p id="reg_passmail">
<input type="password" name="pwd" id="user_pass"

We should really try to introduce parallel classes to allow us to mark all the inconsistent stuff to be marked as deprecated.

Another thing is generic vs. specific messages. In between we got notes like the following, which aren't as unique that they would need an ID. We could just differentiate between .error, .message (both on top of the form) and .note (inline form).

<p id="reg_passmail"><?php _e('A password will be e-mailed to you.') ?></p>

And we should think about a prefix that allows us to consistently determine which action we're currently targeting.

  • password--lost__*
  • password--reset__*
  • login__*
  • register__*

At least this ticket would offer us a good chance.

Last edited 11 years ago by F J Kaiser (previous) (diff)

#37 @nacin
11 years ago

  • Type changed from enhancement to task (blessed)

#38 @helen
11 years ago

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

I think we should open a new ticket for markup changes, which will have to be tackled after 3.9. Seem like it's out of the original scope, anyway. Closing fixed; new tickets for issues, like #27245.

#39 @nacin
11 years ago

Yeah, I agree with helen. I think the research done by F J Kaiser is a good starting point for markup changes, for sure.

Note: See TracTickets for help on using tickets.