Issue 4633 - Default form styles

scss/_forms.scss

+/*!
+ * This file is part of website-defaults
+ * Copyright (C) 2016 Eyeo GmbH
+ *
+ * website-defaults is free software: you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * website-defaults is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with website-defaults.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+/*******************************************************************************
+ * Forms

[juliandoucette, 2017/01/10 13:40:26]

TODO:

- move button styles to button.scss
- remove browsers and numeration from comments
- generally keep normalize only when useful and not overridden 

+ *******************************************************************************
+ * 1. Reset
+ * 2. Structure
+ * 3. Consistency
+ * 4. Fields
+ * 5. States
+ ******************************************************************************/
+
+/* 1. Reset
+ ******************************************************************************/
+
+/**
+ * 1. Change the font styles in all browsers (opinionated).
+ * 2. Remove the margin in Firefox and Safari.

[saroyanm, 2016/12/06 18:26:54]

Detail: Why exactly in Firefox and Safari ? I think we don't know exact list of
the browsers that we are removing margins from.
Having general comment I think will makes more sense.

[juliandoucette, 2016/12/07 17:31:08]

Acknowledged.

This was taken from normalize.

[juliandoucette, 2017/01/10 13:40:27]

will-do.

+ */
+
+button,
+input,
+optgroup,

[saroyanm, 2016/12/06 18:26:54]

Why do we apply this styles to the optgroup ? Ex. margins doesn't have any sense
for this element I guess.

[juliandoucette, 2016/12/07 17:31:09]

Acknowledged.

Don't know. This was taken from normalize. I guess 1 & 2 apply to optgroup in
some way. I can investigate.

+select,
+textarea
+{
+  margin: 0; /* 2 */

[saroyanm, 2016/12/06 18:26:54]

Detail: please specify units where possible.

[saroyanm, 2016/12/06 18:26:54]

I don't think that we need to be that specific regarding the comments.

[juliandoucette, 2016/12/07 17:31:08]

Acknowledged.

Will-do.

Again, taken from normalize.

+  font-family: sans-serif; /* 1 */
+  font-size: 100%; /* 1 */

[saroyanm, 2016/12/06 18:26:54]

Deatail: I think you want to specify 1em here ?

[juliandoucette, 2016/12/07 17:31:09]

Acknowledged.

Maybe. I'll investigate. I think normalize did this because some browsers set
font-size to under 100%.

[juliandoucette, 2017/01/10 13:40:27]

Note: Will change this to em instead of %

+  line-height: inherit;

[saroyanm, 2016/12/06 18:26:53]

I assume you want to setup this according to the current element font-size, not
according to the parent ?

[juliandoucette, 2016/12/07 17:31:09]

Inherit is the default value. This is a reset style.

[juliandoucette, 2017/01/10 13:40:26]

Acknowledged, will investigate, and determine if we override this.

- Consider when parent font-size may be changed

+}
+
+/**
+ * Make advanced text fields consistent and stylable on chrome, safari, and iOS
+ */
+
+input[type="date"],

[saroyanm, 2016/12/06 18:26:54]

This input types are not supported across most of the browsers.

[juliandoucette, 2016/12/07 17:31:09]

Acknowledged.

- They are supported by HTML5
- They fallback to text on browsers that do not support them
- These styles prevent odd browser specific styling (specifically in webkit
browsers)

It makes sense for us to use the correct HTML5 inputs in this case because they
affect the keyboard layout on mobile devices.

[juliandoucette, 2017/01/10 13:40:27]

See comment below.

+input[type="time"],
+input[type="datetime-local"],
+input[type="month"]
+{
+  /* stylelint-disable-next-line */
+  -webkit-appearance: listbox;

[juliandoucette, 2017/01/10 13:40:26]

- will investigate if -webkit-appearance is necessary
- will investigate if/when we should support all these input types (probably not
necessary)

+  box-sizing: border-box;
+}
+
+/**
+ * 1. Prevent a WebKit bug where (2) destroys native `audio` and `video`

[saroyanm, 2016/12/06 18:26:53]

Not really sure if I understand how this comment is relevant to the rule ?

[juliandoucette, 2016/12/07 17:31:09]

Apparently applying "-webkit-appearance: button" to "[type="button"]" causes a
bug on fullscreen video for webkit based browsers on Android 4. And applying the
same style to "html [type="button"]" is a workaround.

Again, this was taken from normalize.css.

+ *    controls in Android 4.
+ * 2. Correct the inability to style clickable types in iOS and Safari.
+ */
+
+button,
+html [type="button"], /* 1 */

[saroyanm, 2016/12/06 18:26:53]

[type="button"] selector will be more consistent with others.

[juliandoucette, 2016/12/07 17:31:09]

Acknowledged.

See comment above.

+[type="reset"],
+[type="submit"]
+{
+  /* stylelint-disable-next-line */
+  -webkit-appearance: button; /* 2 */

[saroyanm, 2016/12/06 18:26:53]

I don't think why we need to use this non standard feature.
Even if we do, why do we only specify the appearance for webkit browsers ?

[juliandoucette, 2016/12/07 17:31:09]

Because webkit based mobile browsers apply default styles to buttons that cannot
be overwritten without changing this property. EG: Border radius and gradient on
submit buttons in Safari for iOS.

+}
+
+/**
+ * Remove the inner border and padding in Firefox.

[saroyanm, 2016/12/06 18:26:54]

I can't see if this have any effect on my side.

[juliandoucette, 2016/12/07 17:31:08]

Acknowledged.

Looks like this is not relevant to the latest versions of firefox.

+ */
+
+button::-moz-focus-inner,
+[type="button"]::-moz-focus-inner,
+[type="reset"]::-moz-focus-inner,
+[type="submit"]::-moz-focus-inner
+{
+  padding: 0;
+  border-style: none;
+}
+
+/**
+ * Restore the focus styles unset by the previous rule.

[saroyanm, 2016/12/06 18:26:54]

Again: why do we need this non standard reset ?
Also I can't test this, maybe it has some particular effect to some special FF
version ? Or maybe I'm missing smth.

[juliandoucette, 2016/12/07 17:31:08]

Acknowledged.

See comment above.

+ */
+
+button:-moz-focusring,
+[type="button"]:-moz-focusring,
+[type="reset"]:-moz-focusring,
+[type="submit"]:-moz-focusring
+{
+  outline: 1px dotted ButtonText;
+}
+
+/**
+ * 2. Remove the padding in IE 10-.

[saroyanm, 2016/12/06 18:26:53]

I don't think that this style is specific for only IE 10- I assume this might be
relevant to other browsers as well.

[juliandoucette, 2016/12/07 17:31:09]

Acknowledged.

Again, this comes from normalize. Apparently it is specific to IE10-.

+ */
+
+[type="checkbox"],
+[type="radio"]
+{
+  padding: 0; /* 2 */
+}
+
+/**
+ * 1. Correct the odd appearance in Chrome and Safari.

[saroyanm, 2016/12/06 18:26:55]

What odd appearance is this fixing, I can't see any result on my side.

[juliandoucette, 2016/12/07 17:31:09]

Search input has border radius by default on chrome and safari.

+ * 2. Correct the outline style in Safari.
+ */
+
+[type="search"]
+{
+  /* stylelint-disable-next-line */
+  -webkit-appearance: textfield; /* 1 */
+  outline-offset: -2px; /* 2 */
+}
+
+/**
+ * Work around a Firefox/IE bug where the transparent `button` background
+ * results in a loss of the default `button` focus styles.
+ */
+
+button:focus
+{
+  outline: 1px dotted;
+  /* stylelint-disable-next-line */
+  outline: 5px auto -webkit-focus-ring-color;

[saroyanm, 2016/12/06 18:26:54]

I don't think that we want to use a webkit specific color, do we ? 

[juliandoucette, 2016/12/07 17:31:08]

Acknowledged.

This is restoring the default behaviour on webkit browsers and is ignored by
other browsers.

We may or may not want to define our own focus styles. We are not currently.

[juliandoucette, 2017/01/10 13:40:27]

Agreed. Let's use a non-webkit color.

+}
+
+/**
+ * Add the correct display in IE 10-.
+ */
+
+[hidden]

[saroyanm, 2016/12/06 18:26:53]

Are we planing to use hidden attribute ?
I can't see any place where we are using it currently.

[juliandoucette, 2016/12/07 17:31:08]

It's common to use this attribute to hide custom form elements EG: replacing a
selectbox with a customized dropdown.

This also provides a standard way to hide elements. Perhaps we should consider
moving it to base.scss?

+{
+  display: none;
+}
+
+/* 2. Structure
+ ******************************************************************************/
+
+fieldset {

[saroyanm, 2016/12/06 18:26:54]

Detail: the opening braces should go to the next line.

[juliandoucette, 2016/12/07 17:31:08]

Acknowledged.

(Sorry)

+  display: block;
+  /* undo browser default */
+  margin: 0em;
+  padding: 0em;
+  border: 0em;
+}
+
+legend {
+  display: block;
+  margin: 2em 0em 0em 0em;
+  /* undo browser default */
+  padding: 0em;
+  font-size: 1.25em;
+  font-weight: $bold-weight;
+  /* undo browser default */
+  line-height: inherit;

[saroyanm, 2016/12/06 18:26:53]

deatail: As far as I remember we decided to specify line-height without units,
according to the fint-size.

[juliandoucette, 2016/12/07 17:31:08]

Acknowledged.

The intention here was to unset browser default line-height. We can investigate
when/if this applies to our requirements.

+}
+
+label {
+  display: block;
+  margin: 1em 0em 0.25em 0em;
+}
+
+/* 3. Consistency
+ ****************************************************************************************/
+
+[type="text"],
+[type="search"],
+[type="tel"],
+[type="url"],
+[type="email"],
+[type="password"],
+[type="date"],

[saroyanm, 2016/12/06 18:26:54]

Some of this input type, like date and time are not supported in most of the
browsers, we need to find out which of them are we going to use.

[juliandoucette, 2016/12/07 17:31:08]

Acknowledged.

I got this list from the HTML5 spec.

Also see comment above.

[juliandoucette, 2017/01/10 13:40:26]

See comment above.

+[type="time"],
+[type="number"],
+select,
+textarea
+{
+  width: 100%;
+  border: 1px solid $secondary;
+  background-color: $primary-light;
+}
+
+[type="text"],
+[type="search"],
+[type="tel"],
+[type="url"],
+[type="email"],
+[type="password"],
+[type="date"],
+[type="time"],
+[type="number"],
+select
+{
+  height: 1.75em;
+  padding: 0 0.25em;
+}
+
+/* 4. Fields
+ ****************************************************************************************/
+
+textarea
+{
+  /* Progressively disable horizontal resizing */
+  /* stylelint-disable-next-line no-unsupported-browser-features */
+  resize: vertical;
+  overflow: auto;

[saroyanm, 2016/12/06 18:26:53]

Why we need to setup overflow to auto ? 

[juliandoucette, 2016/12/07 17:31:08]

Acknowledged.

I don't know :/ . Will investigate.

+}
+
+select
+{
+  /* stylelint-disable */
+  /* Undo chrome default border radius */
+  -webkit-appearance: none;

[saroyanm, 2016/12/06 18:26:54]

The way we are designing select boxes are not reliable and probably will have
issues in most of the browsers that are not supporting SVGs or Appearance
attribute.
We probably can check if specific attribute exists or not before applying some
of this styles.

[juliandoucette, 2016/12/07 17:31:09]

I styled select this way to specifically address this problem. 

- webkit-appearance of none normalizes select on webkit browsers
- moz-appearance of none normalizes select on mozilla browsers
- svg background normalizes the caret icon on modern browsers and highDPI
screens

The intention is to make the select box as consistent as possible across
browsers.

+  -moz-appearance: none;
+  border-radius: 0;
+  /* Make the caret consistent across modern browsers */
+  background-image: url("data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' version='1.1' width='32' height='24' viewBox='0 0 32 24'><polygon points='0,0 32,0 16,24' style='fill: rgb%28138, 138, 138%29'></polygon></svg>");

[saroyanm, 2016/12/06 18:26:54]

I think we can use PNG and made a wider support.

[juliandoucette, 2016/12/07 17:31:09]

SVG is smaller and supports highDPI. We cannot replace the default caret icon on
browsers that don't support SVG anyway.

[juliandoucette, 2017/01/10 13:40:27]

- will double check double backgrounds
- will double check svg fallback
- will consider png fallback

+  background-size: 9px 6px;

[saroyanm, 2016/12/06 18:26:54]

I think we can use background shorthand property.

[juliandoucette, 2016/12/07 17:31:09]

Maybe. This may affect browser support.

+  background-position: right 8px center;
+  background-repeat: no-repeat;
+  padding-right: 25px;

[saroyanm, 2016/12/06 18:26:54]

I thought we awere planing to use EMs instead.

[juliandoucette, 2016/12/07 17:31:09]

The padding-right is in px because the caret icon width is in px. 

+  /* stylelint-enable */
+}
+
+[dir="rtl"] select
+{
+  padding-right: 25px;

[saroyanm, 2016/12/06 18:26:54]

You already setup padding right above.

[juliandoucette, 2016/12/07 17:31:08]

Acknowledged.

Maybe I got this backwards :/

[juliandoucette, 2017/01/10 13:40:26]

Verified. I got this backwards.

+  padding-left: 0.25em;
+  background-position: left 8px center;
+}
+
+/* stylelint-disable-next-line */
+[type="checkbox"],
+[type="radio"]
+{
+  margin-right: 0.15em;

[saroyanm, 2016/12/06 18:26:53]

What if the label will be before the checkbox ? 
Even if we planing to have label on after the checkbox we need to consider RTL.

[juliandoucette, 2016/12/07 17:31:08]

Acknowledged.

Good point.

+}
+
+[type="button"],
+[type="reset"]
+{
+  @extend .button;

[saroyanm, 2016/12/06 18:26:54]

I'll suggest not to use @extend if there is no real need for it.
Currently we can have a general style I guess for some set of input types and
buttons, same applies to the style below.

[juliandoucette, 2016/12/07 17:31:09]

Acknowledged.

[juliandoucette, 2017/01/10 13:40:26]

We will move button styles to button.scss

+}
+
+[type="submit"]
+{
+  @extend .button;
+  @extend .submit;
+}
+
+/* 5. States
+ ****************************************************************************************/
+
+.invalid
+{
+  color: $error;
+}
+
+.invalid input,
+.invalid textarea,
+.invalid select
+{
+  border-color: $error;
+}
+
+.disabled
+{
+  color: $secondary;
+}
+
+.disabled input,

[saroyanm, 2016/12/06 18:26:54]

Why not to use disabled attribute ?

[juliandoucette, 2016/12/07 17:31:08]

Because this class is intended to apply to the paragraph or container containing
the label and the input field.

(And container element disabled attribute does not apply to child elements
consistently in all browsers.)

[juliandoucette, 2017/01/10 13:40:26]

- Will use attribute here instead

+.disabled textarea,
+.disabled select
+{
+  background-color: $secondary-light;
+  /* Progressively set disabled cursor */
+  /* stylelint-disable-next-line */
+  cursor: not-allowed;
+}