Standalone login styles

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

[F J Kaiser]

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]

should do his work, but not tested

[F J Kaiser]

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

[dd32]

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.

[F J Kaiser]

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

[F J Kaiser]

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.

[nacin]

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]

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

[F J Kaiser]

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]

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]

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

[F J Kaiser]

now with the file from core (3.0).

[nacin]

I didn't mean to close this.

[F J Kaiser]

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

[F J Kaiser]

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

[F J Kaiser]

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

[F J Kaiser]

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

[bueltge]

+100, makes easy to inlcude this on frontend

[ocean90]

I think this needs some refresh.

[F J Kaiser]

:)

[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. Suggesting we close this as a duplicate of #18380.

[F J Kaiser]

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.

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

[F J Kaiser]

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? :)

[helen]

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.

[helen]

Edit: Meant to say that anybody can work on this, really, just want to be clear that it isn't going to be ignored :)

[helen]

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.

[F J Kaiser]

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?

[nacin]

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.

[F J Kaiser]

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]

In 27199:

Make login styles standalone. see #12506.

[helen]

In 27200:

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

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

[mrtortai]

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.

[F J Kaiser]

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

[helen]

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.

[nacin]

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