Update textfield & textarea style

Styles taken from ry5n's sandbox + some additional styles as said above:
- red * changed to grey and made bolder
- search input has a little bit different style. Buttons are covered in another issue, so i didn't touch this.
- Auto submit search input has border radius on all sides

Additional:
In the way it's done right now - .error class is added only on the input and not form-item, making it impossible to style label and description. Though .form-disabled class is handled

Other fields:
We still need styling for items like file upload or image fields (as in style guide) - we haven't done them yet in sandbox. They are also not covered by this issue (as seen by screenshot).

Updated issue summary.

+++ b/core/themes/seven/style.cssundefined
@@ -581,8 +585,32 @@ details summary {
+.form-item input.error, ¶

Redundant space

+++ b/core/themes/seven/style.cssundefined
@@ -581,8 +585,32 @@ details summary {
+.form-item textarea.error, ¶

Same here

+++ b/core/themes/seven/style.cssundefined
@@ -581,8 +585,32 @@ details summary {
+.form-item input.error:focus, ¶

Same here

+++ b/core/themes/seven/style.cssundefined
@@ -581,8 +585,32 @@ details summary {
+.form-item textarea.error:focus, ¶

Same here

@Bojhan don't think this patch can cause installation errors, as it's only css.

Simplytest.me fails on this... o_O

Notice: Trying to get property of non-object in Drupal\locale\LocaleLookup->__construct() (line 49 of core/modules/locale/lib/Drupal/locale/LocaleLookup.php).
Warning: array_keys() expects parameter 1 to be array, null given in Drupal\locale\LocaleLookup->__construct() (line 49 of core/modules/locale/lib/Drupal/locale/LocaleLookup.php).
Warning: implode() [function.implode]: Invalid arguments passed in Drupal\locale\LocaleLookup->__construct() (line 49 of core/modules/locale/lib/Drupal/locale/LocaleLookup.php).

Works perfectly fine on local install, it's CSS people ...

Removed the trailing spaces, split the ".form-text, .form-textarea" selectors across separate lines and indented their properties. I also made similar changes outside of the scope of the original patch for consistency's sake.

@swentel Yeah but it's strange simplytest.me crashed only on this one O_o. I know it couldn't be caused by the patch. :)

The styling and the CSS looks fine for me. We can add the additional error styling in a follow up patch.

input.form-autocomplete,
input.form-text,
input.form-tel,
input.form-email,
input.form-url,
input.form-search,
input.form-number,
input.form-color,
input.form-file,
textarea.form-textarea,
select.form-select{

Since these all appear as text inputs, we should use a class to assign the appearance, rather than targeting individual elements: .textinput {

---

.form-item label.option {

Selectors like the above are not cool: descendent selector for no obvious reason, overqualified selector for 'label.option'. This selector would be much better as a stand-alone class. That said, cleaning up the css architecture in Seven is going to require a coordinated effort with HTML cleanup in core. If maintainers feel that that should be follow-up, that would be OK.


Likewise, we should at least try to use the new standards for states, i.e. 'is-disabled'. State classes are the one place we should see double-qualified selectors: .something.is-disabled. Analogous to .something:disabled. Speaking of which, if the item supports the ':disabled' pseudo-class (form elements), that should be present in the css too. So this is also not up to standard:

.form-disabled input.form-autocomplete,
.form-disabled input.form-text,
.form-disabled input.form-tel {

Assuming
1. our previous '.textinput' class,
2. '.field' is the new name for a component consisting of an input with label, description, etc.
3. form elements get the 'disabled' attribute when disabled,
The above should be refactored to something like this:

.field.is-disabled label {
…
}
.textinput:disabled {
…
}

---

.form-text, .form-textarea {
border-radius: 3px;
font-size: 1em;

The standard rounded corners in the style guide, including for text fields, is 2px, not 3px. Also, per coding standards each of those selectors should be on its own line.

I’d keep the focus transition.

Assigning to myself...

Not sure about refactoring the markup so that we can use different selectors, such as .textinput; I'll defer to others on that change.

Attaching updated patch that changes the border radius to 2 pixels, and adds vendor prefixes for border-radius. Also adding interdiff.

It seems like we no longer need prefixes for border-radius.
http://caniuse.com/border-radius
http://css-tricks.com/do-we-need-box-shadow-prefixes/

Yeah remove the prefixes

meta issue added

+++ b/core/themes/seven/style.cssundefined
@@ -1782,12 +1832,12 @@ details.fieldset-no-legend {
-  color: #ffffff;
-  text-shadow: 1px 1px 1px rgba(31, 83, 131, 0.8);
+  color: #fff;

These changes are unrelated and incorrect. In core we always use 6 digeits for colors and 0.x when working with decimal numbers

@18, the Format section of the CSS formatting guidelines states "When hex values are used for colors, use lowercase and, if possible, the shorthand syntax..."

oh ok :s

I think it's a good idea to deal with the property standardisation in another patch. It makes this patch very hard to apply, it keeps getting out of sync with core.

Re-roll.

cleaned up the patch to only contain the relevant css and no refactoring css and also updated it to the current head

Patch applies well and seems to work well.

Nice work guys, just a few improvements.

+++ b/core/themes/seven/style.cssundefined
@@ -656,10 +685,9 @@ details summary {
+  font-size: 90%;

I think ems would be more appropriate

+++ b/core/themes/seven/style.cssundefined
@@ -738,6 +766,14 @@ body div.form-type-checkbox div.description {
+  -webkit-border-radius: 2px;
+  -moz-border-radius: 2px;

@@ -749,18 +785,21 @@ input.form-color,
+  -webkit-border-radius: 2px;
+  -moz-border-radius: 2px;

We no longer need prefixes on border-radius

+++ b/core/themes/seven/style.cssundefined
@@ -749,18 +785,21 @@ input.form-color,
-  -webkit-transition: border linear 0.2s, box-shadow linear 0.2s;
-  -moz-transition: border linear 0.2s, box-shadow linear 0.2s;
-  transition: border linear 0.2s, box-shadow linear 0.2s;

Are we keeping the transition? It would be nice

I have add the improvements.

Here's a patch that should hopefully pass this time.

#31: form-items-styling-1986418-30.patch queued for re-testing.

#31: form-items-styling-1986418-30.patch queued for re-testing.

I have found some vendor prefixes and I am not sure if we should remove them. Pasted some examples. What do you think?

+++ b/core/themes/seven/css/components/buttons.cssundefined
@@ -0,0 +1,70 @@
+  -webkit-box-sizing: border-box;
+  -moz-box-sizing: border-box;

+++ b/core/themes/seven/css/components/buttons.cssundefined
@@ -0,0 +1,70 @@
+  -webkit-appearance: none;  /* 3 */

+++ b/core/themes/seven/css/components/buttons.cssundefined
@@ -0,0 +1,70 @@
+  -webkit-appearance: none;

+++ b/core/themes/seven/css/components/buttons.theme.cssundefined
@@ -0,0 +1,244 @@
+  background-image: -webkit-linear-gradient(top, #f6f6f3, #e7e7df);
+  background-image:    -moz-linear-gradient(top, #f6f6f3, #e7e7df);
+  background-image:      -o-linear-gradient(top, #f6f6f3, #e7e7df);
+  background-image:   linear-gradient(to bottom, #f6f6f3, #e7e7df);

+++ b/core/themes/seven/css/components/buttons.theme.cssundefined
@@ -0,0 +1,244 @@
+  -webkit-transition: all 0.1s;
+  -moz-transition:    all 0.1s;
+  -o-transition:      all 0.1s;
+  transition:         all 0.1s;
+  -webkit-font-smoothing: antialiased;  /* 2 */

+++ b/core/themes/seven/css/components/buttons.theme.cssundefined
@@ -0,0 +1,244 @@
+  background-image: -webkit-linear-gradient(top, #fcfcfa, #e9e9dd);
+  background-image:    -moz-linear-gradient(top, #fcfcfa, #e9e9dd);
+  background-image:      -o-linear-gradient(top, #fcfcfa, #e9e9dd);
+  background-image:   linear-gradient(to bottom, #fcfcfa, #e9e9dd);

+++ b/core/themes/seven/css/components/buttons.theme.cssundefined
@@ -0,0 +1,244 @@
+  background-image: -webkit-linear-gradient(top, #f6f6f3, #e7e7df);
+  background-image:    -moz-linear-gradient(top, #f6f6f3, #e7e7df);
+  background-image:      -o-linear-gradient(top, #f6f6f3, #e7e7df);
+  background-image:   linear-gradient(to bottom, #f6f6f3, #e7e7df);
+  box-shadow: inset 0 1px 3px hsla(0, 0%, 0%, 0.2);
+  -webkit-transition: none;
+  -moz-transition:    none;
+  -o-transition:      none;

If in doubt go to http://caniuse.com with our supported browsers in mind. It would be nice to find a way to achieve this consistently across core. Maybe it should be a separate page of our CSS standards?

#31: form-items-styling-1986418-30.patch queued for re-testing.

I couldn't find an example of a disabled text field in d8 Core as displayed in the png above(Screen Shot 2013-05-03 at 10.29.50 PM.png).
My screenshots of current text fields were taken from the site-wide contact form: /contact

Screenshot of text box and text area not required from an article with restricted text:

The latest patch includes button styling files, they are never loaded though. Should be easy to remove.

I haven't tried the latest patch, but from scanning through it and looking at the screenshots in #42, I think the biggest accessibility problem is conveying too much via color. I like the addition of the red outline for disabled text fields, but wonder how a color blind person would be able to determine the meaning?

Think this will be a good addition to Core.

I believe #42 and #43 show the current state of Seven, not the effects of the patch.

That said, for either: the majority of people with colour blindness will still perceive a red hue. Folk with complete red-blindness will still recognise bolder outlines. The most important aspect of the colour choices is that normal fields, error-state fields and focused fields appear distinct.

#31: form-items-styling-1986418-30.patch queued for re-testing.

The previous patch included the buttons styling somehow. Let's get some up to date screenshots.

Re-uploading with another filename the image to make it visible in the issue summary.

updated related issues

Tried to make image visible.

Once more the image. New source: https://...

Patch applies well and styling seems ok. (See screenshots)

Is it a RTBC?

#48: form-items-styling-1986418-48.patch queued for re-testing.

I did the auto re-test and the patch failed. I will get on GIT and manually test it as well.

Re-roll! I haven't looked into the title styling yet. Go testbot!

Last patch applies well to me.

I've tested in Google Chrome, Mozilla Firefox and Safari. The styling seems work on test pages.

Testing /admin/config/system/site-information, and "error" class is not injected in the label for text input field.

So "needs work", right?

Yes.

I'll add this.

Ok, I've implemented two theme functions to add error classes to the label and description.

#61: form-items-styling-1986418-60.patch queued for re-testing.

Re-roll.

#65: form-items-styling-1986418-65.patch queued for re-testing.

@LewisNyman

Looks awesome. The only thing I noticed is that when overlay is uninstalled the focus effect appears to shift right a few pixels.

@Bojhan, which form elements? We have designs for other form elements such as the select inputs. Do we need more designs to achieve consistency? I don't think we have it now.

Added test pages

1. +++ b/core/themes/seven/style.css
   @@ -845,18 +884,22 @@ input.form-color,
    input.form-tel:focus,
   
   @@ -868,16 +911,30 @@ input.form-color:focus,
   +  box-shadow: inset 0 1px 3px rgba(0, 0, 0, .05), 0 0 8px #40b6ff;
   

   The focus shadow is hidden on the left because of overflow: hidden on .layout-node-form (see visual illustration in attachment). This cannot be unseen :(

2. +++ b/core/themes/seven/style.css
   @@ -868,16 +911,30 @@ input.form-color:focus,
    .js input.form-autocomplete {
   -  background-position: 100% 4px;
   +  background: none;
   

   This breaks the autocomplete throbber. It is now completely missing from autocomplete fields such as entity reference, which used to be the only visual cue the field was more than a plain textfield

3. +++ b/core/themes/seven/style.css
   @@ -741,10 +747,35 @@ label {
   +.form-required {
   +  font-weight: bold;
   +  color: #666;
   +  font-size: 1.1em;
   +  padding-left: 2px;
   +  }
   

   Indenting error in closing tag :P

Thanks for the review. I don't know why node-layout-form had overflow hidden on it. I've fixed that along with the other bugs.

Works.

EDIT: Sorry I did somthing wrong. Doesn't apply..

Sorry, no longer applies.

+++ b/core/themes/seven/style.css
@@ -1748,7 +1805,6 @@ details.fieldset-no-legend {
   .layout-node-form {
-    overflow: hidden;
     position: relative;
   }

This breaks the node layout form for secondary input as it applies the 'Position Is Everything technique for equal-height columns: http://www.positioniseverything.net/articles/onetruelayout/equalheight

This is re-rolled patch #71. I've removed the seven.theme changes in it so this is pure css patch.
I'm not sure what was the code in seven.theme for but all it seemed it did was breaking required labels of form elements to something like this: "Title!required".

Comment in #75 still needs work

Yes, but I'm wondering if this could be fixed from the other end.
I'm not sure if there's an issue about 'Position Is Everything technique' and why this was chosen?
This looks like an old hack. Maybe it could be changed to display: table in a follow up issue.

@philipz It would be good to add the theme functions back in. The theme functions in core must have changed and knocked it off a bit. I think we only added a few additional lines to add error classes on to the description and label.

I think the simplest way to solve the content creation screen problem in this issue is to add padding-left: 4px; to .layout-region-node-main.

OK I'll update and include the theme functions and the padding-left fix today.

@LewisNyman what do you think about changing the equal heights columns approach to media query + display: table? Is this something I could try and open issue on or is this topic closed and it's not going to change?

Theme functions re-added. The "Title!required" problem is gone and this must have been caching issue on my side.
Overflow fixed and workaround padding added.

The old theme function in this patch was using now deprecated form_get_error which now takes $form_state array as second parameter and it is not available in the theme function (or at least is not to my knowledge).
I'm not sure this can be done like it was before.

Looks like you can check if the '#errors' attribute is empty? Works for me. Looks like we're almost there.

Yes, it is very close now :) I don't have much time right now but the only minor problem is

form-items-styling-1986418-82.patch:135: new blank line at EOF.
+
warning: 1 line adds whitespace errors.

Yep nice catch

It looks like this might be RTBC :) One thing I found but not sure if this is related issue is the required marker printed as "Array" on a field I added.
This is not happening for Title field. I cleared caches of course.

No this happens without the patch. Good find though. Is there an issue for this already?

Edit: it seems that date field had theme_ functions converted to Twig in #1963476: datetime.module - Convert theme_ functions to Twig which might be the reason for this to happen.
I'm not sure if this really needs fixing or rather it's just waiting for some other patch to make it work like it should.

Created issue for this #2160365: Date field required marker rendered as "Array".

Anyway the form styling patch should be ready to be commited but I guess someone else should look on it right?

86: form-items-styling-1986418-86.patch queued for re-testing.

I didn't see any accessibility problems with this patch. Looks good too.

Looks good!

1. +++ b/core/themes/seven/seven.theme
   @@ -270,3 +271,121 @@ function seven_form_node_form_alter(&$form, &$form_state) {
   +      $output .= ' ' . theme('form_element_label', $variables);
   ...
   +      $output .= ' ' . theme('form_element_label', $variables) . "\n";
   

   We are replacing calls to theme with calls to drupal_render() - see #2006152: [meta] Don't call theme() directly anywhere outside drupal_render()

2. +++ b/core/themes/seven/seven.theme
   @@ -270,3 +271,121 @@ function seven_form_node_form_alter(&$form, &$form_state) {
   +  $title = filter_xss_admin($element['#title']);
   

   Could be replaced with Xss::filter()

Updated the patch in #86 to fix problems described in #94.

For the renderable array I took the patch in #2177653: Replace theme() with drupal_render() in form.inc as a reference. I also used the Xss::filterAdmin instead of Xss::filter since it was previously a filter_xss_admin.

95: form-items-styling-1986418-95.patch queued for re-testing.

+++ b/core/themes/seven/seven.theme
@@ -319,16 +320,24 @@ function seven_form_element($variables) {
+  $form_element_label = array(
+    '#theme' => 'form_element_label',
+    '#required' => isset($element['#required']) ? $element['#required'] : '',
+    '#title' => isset($element['#title']) ? $element['#title'] : '',
+    '#title_display' => isset($element['#title_display']) ? $element['#title_display'] : '',
+    '#id' => isset($element['#id']) ? $element['#id'] : '',
+  );

this would be simpler if done like this.
$form_element_label = $variables + array('#theme' => 'form_element_label');

Thanks for the review @alexpott. I tried your suggestion but it triggered many warning on the create article page:

User error: "theme_hook_original" is an invalid render array key in Drupal\Core\Render\Element::children() (line 89 of core/lib/Drupal/Core/Render/Element.php).

But I looked again at #1986418: Update textfield & textarea style and the patch was updated with a cleaner version.

101: form-items-styling-1986418-101.patch queued for re-testing.

Patch wasn't applying anymore so here is a reroll.

There are two things I didn't reapply since the elements were not anymore in the css:

 .js input.form-autocomplete {
-  background-position: 100% 4px;
+  background-position: 100% 5px;
 }
-.js input.throbbing {
-  background-position: 100% -16px;
+.js input.form-autocomplete.ui-autocomplete-loading {
+  background-position: 100% -15px;
 }

I was not able to find which issue/commit removed these style but without that the autocomplete still looks good. Here is how it looks after applying the patch:

edit: didn't mean to "delete" all these files, I don't know what happened.

105: form-items-styling-1986418-105.patch queued for re-testing.

Reroll of #105, it had a conflict with 'use Drupal...' added to seven.theme.

1. +++ b/core/themes/seven/seven.theme
   @@ -363,3 +365,124 @@ function seven_form_node_form_alter(&$form, &$form_state) {
   +
   

   Only one space before comments.

2. +++ b/core/themes/seven/seven.theme
   @@ -363,3 +365,124 @@ function seven_form_node_form_alter(&$form, &$form_state) {
   +  if (isset($element['#parents']) && !empty($element['#errors']) && !empty($element['#validated'])) {
   +    $attributes['class'][] = 'error';
   +  }
   

   I don't know why but it looks like the label theming changes is no longer adding the error class?

Here is a new patch which should fix the problems described in #112.

113: form-items-styling-1986418-113.patch queued for re-testing.

@idflood The install fails on SimplyTest.me as well.

My bad, the error was caused by #2173655: Refactor theme() to _theme(); make it a private API to discourage module developers from circumventing the renderable build system.

118: form-items-styling-1986418-118.patch queued for re-testing.

Reroll. This is looking RTBC worthy to me. Any objections?

+++ b/core/themes/seven/style.css
@@ -828,10 +871,23 @@ input.form-color:focus,
+input.form-search {

Whoops answered my own question. Found this overqualified selector

Working...

+++ b/core/themes/seven/style.css
@@ -774,10 +805,12 @@ label {
+.form-item div.description.error {

What about this one?

Added #123, #125 and some other fixes (just see interdiff.txt)

126: form-items-styling-1986418-126.patch queued for re-testing.

Re-roll with one simple change.

Those selectors:

body div.form-type-radio div.description,
body div.form-type-checkbox div.description {

seemed too specific so I changed them to:

.form-type-radio .description,
.form-type-checkbox .description {

129: form-items-styling-1986418-129.patch queued for re-testing.

Hey

Tested the last patch:

/core/install.php

Looks good

/node/add/article

Added a small change for theming the "Authored on" fields

/admin/structure/views/view/content - Try changing a few settings

Looks good

/admin/structure/views/add

Looks good

/admin/structure/block - Try adding a block

Looks good

/admin/structure/types/manage/article/fields/node.article.body

Not using the admin theme.

Testing the patch in #131.

Notice: in the description the input background is defined as #fafafa but in the code it is actually #fcfcfa. I think it is OK, but wanted to mention it.

/core/install.php
Generally OK, but box-shadow cant be seen on the password fields. I think fixing that could be a separate issue.

/node/add/article
Looks good. ("Athored on" field checked too.)
Notice: CKEditor appereance should follow these other input elements. Should be a separate issue.

/admin/structure/views/view/content - Try changing a few settings
Looks good.

/admin/structure/views/add
Input fields are OK.
Fieldsets need work but that will be a separate issue.

/admin/structure/block - Try adding a block
Looks good.

/admin/structure/types/manage/article/fields/node.article.body
Looks good.

I tested all the url-s.
One more differencies:
The field with error not exactly the same, what is proposed, but maybe good enough to commit.
Screenshot:( edited 3 screenshot on one image)

fixing core/install.php box shadow. It is, because using overflow: hidden;

Here is the patch i missed to upload to #135.

I recommend we add 4px of left padding to the install form like we did for the content creation page, I assume we are using overflow hidden for a reason there?

@Lewis: What element overflow are you talking about?

Here is the patch for background-color problem on form-error, and the deleted box-shadow patch.

I'm not sure but it is possible that this is no longer needed:

 /**
+ * Make room for focused form items box-shadow
+ */
+.layout-region-node-main {
+  padding-left: 4px;
+}

because of #2195675: Breadcrumbs push the sidebar down on node edit pages where .layout-node-form and its overflow: hidden was removed.
I will double check that.

The overflow was for the faux column of the node meta data in the right column.

@philipz Yeah worth double checking.

Looking good! I did find one error introduced on the install form.

Before:

After:

Ignore the fact that everything is outside of the box because that's being fixed in #2193271: Remove default #size attribute from core

fixed the small ( < 1010px ) screens layout.
also removed the lines from the #143 comment, without errors.

This patch got suddenly huge ;)

I've checked that the left-padding of .layout-region-node-main can be removed.

Added back the left-padding of .layout-region-node-main.

Sorry if I wasn't clear enough. The padding CAN be removed. I set it to Needs work because patch #145 was over 90 kb and clearly mixed with some other patch applied.

OK, some code changes on the http://git.drupal.org/project/drupal.git repo, and i made create diff from there.
Now i create a fresh clone, and make a new patch.

I've clicked through all the problem pages and everything looks great!

152: form-items-styling-1986418-152.patch queued for re-testing.

So RTBC then?

needs some reroll, becaouse there is no more theme_form_element_label, or theme_form_element

Is it good, to add the error class to the wrapper div?
Is there always a wrapper class on the seven theme?

The patch is doing this.

Looks like we just need a preprocess function to add a class to the label on error. If you look in the patch in #152 you can see we were overriding a theme function to add a class there but I bet we could do it in a preprocess.

I need to upgrade the core/includes/form.inc -> theme_form_element_label, because it can't handle additional classes. No we can add classes through $variables.

update theme_form_element_label function documentaiton.

OK, i rerolled it again :)

Thumbs up!. It looks soo good!
Tested in Mac (FF, Chrome, Safari) and IE 11,10,9

Screenshot attached.

Chrome/Safari in Mac doesn't apply padding on "select" elements. Firefox Mac and IE9-IE11 yes. So they have more consistent look in the latter case.
But this is something we can't control easily, unless we set a 'height' value to the select element. Maybe in a follow-up issue if people agree that is worth it.

For me it's RTBC

1. +++ b/core/includes/form.inc
   @@ -2969,11 +2969,15 @@ function theme_form_element_label($variables) {
   +  // If the element already has a class, append this.
   +  if (!empty($element['#class'])) {
   +    $attributes['class'][] = $element['#class'];
      }
   

   This feature addition needs to go into a separate issue:

   #1244338: Add generic #class property for form elements

2. +++ b/core/modules/user/css/user.module.css
   @@ -79,7 +79,7 @@ div.password-suggestions ul {
   -  overflow: hidden;
   +  width: auto;
   

   Was this tested in other themes than Seven?

3. +++ b/core/themes/seven/seven.theme
   @@ -8,6 +8,8 @@
   +use Drupal\Core\Template\Attribute;
   +
   

   Can we remove this additional/duplicate blank line?

4. +++ b/core/themes/seven/seven.theme
   @@ -346,3 +348,18 @@ function seven_form_node_form_alter(&$form, &$form_state) {
   + * Add error class to the form item wrapper div, if it has got an error.
   + */
   +function seven_preprocess_form_element(&$variables) {
   

   Isn't this what #1493324: Inline form errors for accessibility and UX tries to resolve, beyond Seven theme?

5. +++ b/core/themes/seven/seven.theme
   @@ -346,3 +348,18 @@ function seven_form_node_form_alter(&$form, &$form_state) {
   \ No newline at end of file
   

   minor

+++ b/core/modules/user/css/user.module.css
@@ -79,7 +79,7 @@ div.password-suggestions ul {
-  overflow: hidden;
+  width: auto;

Not quite sure what this change does, and the two CSS-inclined people at the sprint were unsure as well.

Since this is changing something outside of /core/themes/seven, let's get some before/after screenshots in both Stark and Bartik, ok?

That overflow: hidden; (in 2 places, one for narrow viewport) was added in #2100509: Password strength indicator for site maintenance account is aligned incorrectly on the installation screen so that might help to not miss testing those screens.

I need some clarification.

First:
I delete "overflow :hidden", because in the SEVEN styleguide, the input text has a box-shadow, and the "overflow: hidden" cut this shadow. First, try to use 4px padding, but this padding also break the layout. Then i create another CSS for clearing floats.
I think we can move this CSS modification to the SEVEN stylesheet.

Second:
This issue is about the textfield & textarea style, only in the seven theme.
We don't need to modify the whole CSS, and the labels, and descriptions.

Third:
Can we make another issue for the styling the error field labels and descriptions? If we can, than we can commit this issue in a short way..

First:
I delete "overflow :hidden", because in the SEVEN styleguide, the input text has a box-shadow, and the "overflow: hidden" cut this shadow. First, try to use 4px padding, but this padding also break the layout. Then i create another CSS for clearing floats.
I think we can move this CSS modification to the SEVEN stylesheet.

Agreed, let's change the patch so we're only modifying Seven CSS and .theme files.

Second:
This issue is about the textfield & textarea style, only in the seven theme.
We don't need to modify the whole CSS, and the labels, and descriptions.

Third:
Can we make another issue for the styling the error field labels and descriptions? If we can, than we can commit this issue in a short way..

If you think we are close to achieving it the error label and description styling here then we can expand the title of the issue. If you think it's too much trouble and is better off split into a separate issue (it looks like it is) then let's do that.

Moved user.module.css modifications to seven/style.css.
Remove the preprocess function from seven.theme, because to add an error class to the form label and description is a more complex problem. Now just format the inputs and textfields.
This issue: #1244338: Add generic #class property for form elements is about to add #class to the form label.
This issue: #1493324: Inline form errors for accessibility and UX is about,to add inline form errors. My idea is, after this was coomited, then apply the styleguide for the errors.

i forgot remove the .htaccess mods. It's for my local development enviroment.

Nice work reducing the patch down to just CSS. I noticed some weirdness in the installer which must be related to the CSS changes we made:

It must have something to do with all the floats that come in. When I add a clear:both; to the details element, the layout seems fixed. See here: http://cl.ly/image/0c1Z1H0D1E0v. Another thing to do could be to float the details element as well?

Sounds like we're floating too many things... but is that the problem introduced in this patch? I'm not sure.

I also just noticed that the form-required markup has changed which mens we need to change the CSS here:

+++ b/core/themes/seven/style.css
@@ -783,9 +790,35 @@ label {
+.form-required {
+  font-weight: bold;
+  color: #e62600;
+  font-size: 1.1em;
+  padding-left: 2px;
+}

Without the patch, the installation layout seems to be looking fine. It does seem like the patch is breaking the layout.

Before the patch:
http://cl.ly/image/3T320C150a2S

After the patch:
http://cl.ly/image/3T1I2M1f3e2v

We need to tag a more specific class than .form-type-password, because this is used in more than one place during the installation process.

Added more specific selector for .form-type-password.

@tompagabor: did you have a specific for this

 .form-item label.option {
text-transform: none;
+ display: inline-block;
}

The install screen displays fine for me- all lined up. Required field labels on install page are currently red, but on the contact form it's just the red asterisk. Looks like .form-required isn't loading here. Looking at "create basic page" we're back to red label again- the class loads.

Here's an updated patch to solve the above issue. As @LewisNyman suggested, I added an :after to .form-required to fix the label coloring.

Let's get this done in Austin.