admin-color-scheme.css already loaded on wp-login.php. why?

[F J Kaiser]

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;
}

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).

should do his work, but not tested

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

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.

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).

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.

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.

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

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.

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).

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

now with the file from core (3.0).

I didn't mean to close this.

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

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

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).

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

+100, makes easy to inlcude this on frontend

I think this needs some refresh.

:)