reset.css

input[type="text"],
input[type="email"],
input[type="tel"],
input[type="number"],
textarea {
  -webkit-appearance: none;
  -moz-appearance: none;
  -ms-appearance: none;
  appearance: none;
  outline: 0;
  box-shadow: none;
}

:focus

sets styles for the field currently being used:

input:focus,
textarea:focus,
select:focus {
background-color: #eef;
}

:checked

input:checked ~ label {
font-weight: bold;
}

alternatively:
:not(:checked)

~ Selector

find siblings:
input:checked ~ label {
font-weight: bold;
}

:indeterminate

:required

:required applies styles to any input that has a required attribute and must be entered prior to submit.

:optional

:optional applies styles to any input that does not have a required attribute. I’m not sure why it’s been added since :not(:required) would do the same?!

:valid

:valid applies styles to any input that currently holds valid data.

:invalid

Similarly, :invalid (or :not(:valid)) applies styles to any input that currently holds invalid data,

:in-range (number and range inputs)

Numbers and ranges holding a valid value between the min and max attributes that adhere to the step value can be selected using :in-range. Obviously, it’s a little difficult for a slider to be out of range, but…

:out-of-range (number and range inputs)

:out-of-range targets invalid number values for range inputs.

:disabled

Inputs with a disabled attribute can be targeted with the :disabled pseudo-class, e.g.

input:disabled {

    color: #ccc;

    background-color: #eee;

}

Remember that disabled fields will not be validated or have their data posted to the server. However, styles for pseudo-classes such as :required and :invalid will still be applied.

:enabled

Similarly, non-disabled fields can be selected with :enabled (or :not(:disabled)). In practice, you’re unlikely to require this selector since it’s the default input style.

:read-only

Inputs with a readonly attribute can be targeted with the :read-only pseudo-class. Remember that read-only inputs will still be validated and posted to the server but the user cannot change the values.

:read-write

Standard read-write fields can be selected with :read-write (or :not(:read-only)). Again, it’s not a selector you’ll need often.

:default (submit buttons or inputs only)

Finally, we have the :default selector, which applies styles to the default submit button.

Placeholder Text Style

The placeholder attribute text can be styled using the ::placeholder pseudo-element with vendor-prefixes (in separate rules), e.g.

input::-webkit-input-placeholder { color: #ccc; }

input::-moz-placeholder { color: #ccc; }

input:-ms-input-placeholder { color: #ccc; }

input::placeholder { color: #ccc; }

******************************************************************************
******************************************************************************
******************************************************************************
******************************************************************************
******************************************************************************
******************************************************************************
******************************************************************************
******************************************************************************
******************************************************************************

input[type=search] { -webkit-appearance: none; }

input[type=text] {
  -webkit-appearance: searchfield;
}

WebKit values

checkbox
radio
push-button
square-button
button
button-bevel
listbox
listitem
menulist
menulist-button
menulist-text
menulist-textfield
scrollbarbutton-up
scrollbarbutton-down
scrollbarbutton-left
scrollbarbutton-right
scrollbartrack-horizontal
scrollbartrack-vertical
scrollbarthumb-horizontal
scrollbarthumb-vertical
scrollbargripper-horizontal
scrollbargripper-vertical
slider-horizontal
slider-vertical
sliderthumb-horizontal
sliderthumb-vertical
caret
searchfield
searchfield-decoration
searchfield-results-decoration
searchfield-results-button
searchfield-cancel-button
textfield
textarea

Mozilla values

none
button
checkbox
checkbox-container
checkbox-small
dialog
listbox
menuitem
menulist
menulist-button
menulist-textfield
menupopup
progressbar
radio
radio-container
radio-small
resizer
scrollbar
scrollbarbutton-down
scrollbarbutton-left
scrollbarbutton-right
scrollbarbutton-up
scrollbartrack-horizontal
scrollbartrack-vertical
separator
statusbar
tab
tab-left-edge Obsolete
tabpanels
textfield
textfield-multiline
toolbar
toolbarbutton
toolbox
-moz-mac-unified-toolbar
-moz-win-borderless-glass
-moz-win-browsertabbar-toolbox
-moz-win-communications-toolbox
-moz-win-glass
-moz-win-media-toolbox
tooltip
treeheadercell
treeheadersortarrow
treeitem
treetwisty
treetwistyopen
treeview
window

This is the first in a three-part series about HTML5 web forms. We’ll cover the basic markup in this article before progressing to styling and the client-side JavaScript validation APIs. I recommend you read this even if you’re already familiar with forms — there are many new attributes and gotchas!

HTML forms may be mundane but they’re essential for the majority of web sites and apps. In HTML4, input fields were limited to:

input type="text"
input type="checkbox"
input type="radio"
input type="password"
input type="hidden" — for data the user cannot view
input type="file" — for uploads
textarea — for longer text entry
select — for drop-down lists
button — generally used for submitting a form, although input type="submit" and input type="image" could also be used.

Also:

CSS styling possibilities were limited,
custom controls such as date and color pickers had to be developed in code, and
client-side validation required JavaScript.

Additional HTML5 Input Types

A deluge of new input types have been introduced. These provide native input assistance and validation without any JavaScript code…

type	description
`email`	enter an email address
`tel`	enter a telephone number — no strict syntax is enforced but line breaks will be removed
`url`	enter a URL
`search`	a search field with line breaks automatically removed
`number`	a floating point number
`range`	a control for entering an approximate value, typically represented by a slider
`date`	enter the day, month and year
`datetime`	enter the day, month, year, hour, minute, second and microsecond based on the current UTC timezone
`datetime-local`	enter a date and time with no timezone
`month`	enter the month and year with no timezone
`week`	enter a week number with no timezone
`time`	enter the time with no timezone
`color`	specify a color

Input Attributes

Unless stated otherwise, input fields can have any of the following form-specific attributes. Several are Boolean attributes, that is, they do not require values, e.g

<input type="email" name="email" required />

although you can add them if you prefer a stricter XHTML-like syntax, e.g.

<input type="email" name="email" required="required" />

attribute	description
`name`	the input field name
`value`	an initial value
`checked`	checks a `checkbox` or `radio` input
`maxlength`	the maximum length of the entered string. This can also be applied to `textarea` fields in HTML5
`minlength`	the minimum length of the entered string. This is documented but, at the time of writing, browser support is poor and the attribute causes HTML validators to error. An alternative option is`pattern=".{3,}"` which would enforce at least three characters.
`placeholder`	a subtle text hint shown in the input box
`autofocus`	set focus to this (non-hidden) field when the page loads
`required`	indicates that a value must be entered
`pattern`	ensures a value adheres to a regular expression
`min`	the minimum value permitted (numeric and date types)
`max`	the maximum value permitted (numeric and date types)
`step`	the value granularity. For example, `input type="number" min="10" max="19" step="2"` would only permit the values 10, 12, 14, 16 or 18.
`autocomplete`	provides the browser with a hint for auto-completion, e.g. “billing email” or can be set to “on” or “off” to enable and disable accordingly
`inputmode`	specifies the input mechanism. The most useful options: `verbatim` — non-prose content such as usernames `latin` — latin script such as search fields `latin-name` — names, i.e. with initial letter capitalization `latin-prose` — prose content such as messages, tweets, etc. `numeric` — numeric input where `number` or `range` would not be appropriate, e.g. credit card numbers
`size`	the size in characters for `text` or `password` inputs or pixels for `email`, `tel`, `url` or`search` inputs. Probably best avoided since you should use CSS to style fields.
`rows`	number of text rows (`textarea` only)
`cols`	number of text columns (`textarea` only)
`list`	points to a set datalist options
`spellcheck`	set to true or false to enable or disable spell checking
`form`	the ID of the form which this input belongs to. In general, inputs should be nested inside a `form`, but this attribute permits an input to be defined anywhere on the page
`formaction`	specifies a URI to override the `form` action when submitting (submit buttons/images only)
`formmethod`	specifies GET or POST to override the `form` method when submitting (submit buttons/images only)
`formenctype`	specifies the type of content when submitting (`text/plain`, `multipart/form-data` or`application/x-www-form-urlencoded` on submit buttons/images only)
`formtarget`	specifies a target window/frame to override the `form` target when submitting (submit buttons/images only)
`readonly`	the input value cannot be changed although it will be validated and submitted
`disabled`	disables the input — no validation will occur and data will not be submitted

Note that date fields must always use YYYY-MM-DD for value, min and max attributes.

The following example requests a mandatory email which ends in @mysite.com and has focus when the page loads:

<input

  type="email"

  name="login"

  pattern="@mysite\.com$"

  autocomplete="email"

  autofocus

  required />

Datalists

A datalist contains a set of suitable options for any type of input, e.g.

<input type="text" name="browser" list="browsers" />

<datalist id="browsers">

  <option value="Chrome" />

  <option value="Firefox" />

  <option value="Internet Explorer" />

  <option value="Safari" />

  <option value="Opera" />

</datalist>

When datalist is supported, the browser presents auto-complete options when you start to type. The whole list is usually shown if you double-click the control or click the down arrow (if shown). Unlike a standard selectdrop-down, the user is free to override these choices and enter their own value.

It’s possible to set values and text like standard select options, e.g.

<option value="IE">Internet Explorer</option>

but be aware that implementations differ. For example, Firefox auto-completes on the text itself (Internet Explorer) while Chrome prefers the value (IE) and shows the text greyed out:

Datalists can be populated by JavaScript if you wanted to retrieve options via Ajax.

Disabling Validation

Validation for the whole form can be disabled by setting a novalidate attribute on the form element. Alternatively, you can set a formnovalidate attribute on the form’s submit button/image.

Remember also that setting an input’s disabled attribute will prevent validation on that field.

Output Fields

While we’re primarily discussing input types, HTML5 also provides read-only output options:

output — the result of a calculation or user action
progress — a progress bar (the value and max attributes define the status)
meter — a scale which can change between green, amber and red depending on the values set for the attributes value, min, max, low, high and optimum

Separating and Labeling Inputs

The whatwg.org form specification states:

Each part of a form is considered a paragraph, and is typically separated from other parts using <p> elements

Interesting. I normally use a div although I doubt it matters from a semantic perspective. A p tag is shorter although it’s possible you’ll need to apply a class to modify margins.

More importantly, you should use label elements either around or next to the input itself with a for attribute stating the input’s ID, e.g.

<p>

  <p>

  <label for="firstname">First name</label>

  <input type="text" id="firstname" name="firstname" placeholder="first name" required maxlength="20" />

</p>

<p>

  <label for="lastname">Last name</label>

  <input type="text" id="lastname" name="lastname" placeholder="last name" required maxlength="20" />

</p>

<p>

  <label for="email">Email address</label>

  <input type="email" id="email" name="email" placeholder="your@email.address" required maxlength="50" />

</p>

<p>

  <label>

    <input type="checkbox" name="newsletter" />

    Sign up for our newsletter

  </label>

</p>

No Standard Controls

There are no specific interface guidelines for browser vendors to follow. This is intentional: a typical desktop mouse-controlled date picker can be too small on a mobile device so the vendor can implement a touch-based alternative.

Browser Support

Not every input type and attribute is supported in all browsers. In general, most modern browsers from IE10+ include basics such as email and number. However, the date types are only supported in Webkit and Blink browsers at the time of writing.

The browser will revert to a standard text input when a specific type and ignore attributes when those values are not supported.

Always Use the Correct Type!

It’s important to use the correct input type for the data you’re requesting. That may seem obvious but you will encounter situations when you’ll be tempted to use a standard text input.

Consider dates. Support is patchy and this leads to implementation issues:

The standard date input always returns dates in YYYY-MM-DD format regardless of how the date picker is presented in your locale.
IE and Firefox will fall back to a standard text input, but your users may expect to enter values in US MM-DD-YYYY or European DD-MM-YYYY format.
A JavaScript date picker such as the one in jQuery UI allows you to define a custom format — or even YYYY-MM-DD for consistency — but you cannot guarantee JavaScript will be enabled.

The easy solution is to abandon the HTML5 date input, revert to text and implement your own date control. Don’t. You will never create a custom date picker which works in all devices at all screen resolutions, supports keyboard, mouse and touch input and continues to operate when JavaScript is disabled. In particular, mobile browsers are often ahead of their desktop cousins and implement good touch-screen controls.

The HTML5 input types are the future. Use them and, if necessary, add JavaScript polyfills in situations where you require good cross-browser support. But remember to…

Validate Server-Side

Browser validation is not guaranteed. Even if you forced everyone to access using the latest version of Chrome you could never prevent:

browser bugs or JavaScript failures permitting invalid data
the user changing your HTML or scripts using browser tools
submission from systems outside your control, or
data interception between the browser and the server (certainly over HTTP).

Client-side validation never has and never will be a substitute for server-side validation. Validating user data on the server is essential. On the client, it’s a nice-to-have.

Finally, remember dates may be received in YYYY-MM-DD or whichever format you specified to the user (MM-DD-YYYY, DD-MM-YYYY, etc.) Check for digits in the first four characters or use native language/framework date parsing methods as necessary.

We’ve covered a lot in this article. In the next part we’ll look at form-related CSS properties.

The 30 CSS Selectors you Must Memorize

by Jeffrey Way9 Jun 2011549 Comments

Twice a month, we revisit some of our readers’ favorite posts from throughout the history of Nettuts+. This tutorial was first published in November, 2010.
So you learned the base id, class, and descendant selectors - and then called it a day? If so, you're missing out on an enormous level of flexibility. While many of the selectors mentioned in this article are part of the CSS3 spec, and are, consequently, only available in modern browsers, you owe it to yourself to commit these to memory.

1. *

* {

 margin: 0;

 padding: 0;

}

Let's knock the obvious ones out, for the beginners, before we move onto the more advanced selectors.
The star symbol will target every single element on the page. Many developers will use this trick to zero out the margins and padding. While this is certainly fine for quick tests, I'd advise you to never use this in production code. It adds too much weight on the browser, and is unnecessary.
The * can also be used with child selectors.

#container * {

 border: 1px solid black;

}

This will target every single element that is a child of the #container div. Again, try not to use this technique very much, if ever.

Sunday, 6 July 2014

Tuesday, 1 July 2014

Saturday, 28 June 2014

reset.css

:focus

sets styles for the field currently being used:

input:focus,textarea:focus,select:focus { background-color: #eef;}

:checked

~ Selector

:indeterminate

:required

:optional

:valid

:invalid

:in-range (number and range inputs)

:out-of-range (number and range inputs)

:disabled

:enabled

:read-only

:read-write

:default (submit buttons or inputs only)

Placeholder Text Style

WebKit values

Mozilla values

Additional HTML5 Input Types

Input Attributes

Datalists

Disabling Validation

Output Fields

Separating and Labeling Inputs

No Standard Controls

Browser Support

Always Use the Correct Type!

Validate Server-Side

The 30 CSS Selectors you Must Memorize

1. *

Compatibility

2. #X

Compatibility

3. .X

Compatibility

4. X Y

Compatibility

5. X

Compatibility

6. X:visited and X:link

Compatibility

7. X + Y

Compatibility

8. X > Y

Compatibility

9. X ~ Y

Compatibility

10. X[title]

Compatibility

11. X[href="foo"]

Compatibility

12. X[href*="nettuts"]

Compatibility

13. X[href^="http"]

Compatibility

14. X[href$=".jpg"]

Compatibility

15. X[data-*="foo"]

Compatibility

16. X[foo~="bar"]

Compatibility

17. X:checked

Compatibility

18. X:after

Compatibility

19. X:hover

Compatibility

20. X:not(selector)

Compatibility

21. X::pseudoElement

Target the First Letter of a Paragraph

Target the First Line of a Paragraph

Compatibility

22. X:nth-child(n)

input:focus,
textarea:focus,
select:focus {
background-color: #eef;
}