forked from w3c/web-roadmaps
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathforms.html
36 lines (31 loc) · 3.66 KB
/
forms.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Forms</title>
</head>
<body>
<header>
<h1>Forms</h1>
<p>The ability to build rich forms with HTML is the basis for user input in most Web-based applications. Due to the absence of physical keyboards and the limited size available for on-screen keyboards, text input on mobile devices remains a difficult task for most users though. HTML defines new types of form controls that optimize the way users may enter data.</p>
</header>
<main>
<section class="featureset well-deployed">
<h2>Well-deployed technologies</h2>
<p data-feature="Customized text entries">The <code><a data-featureid="inputtext"><input type="<strong>email</strong>"></a></code>, <code><a href="https://www.w3.org/TR/html52/sec-forms.html#telephone-state-typetel"><input type="<strong>tel</strong>"></a></code> and <code><a href="https://www.w3.org/TR/html52/sec-forms.html#url-state-typeurl"><input type="<strong>url</strong>"></a></code> can be used to optimize the ways user enter these often-difficult to type data, e.g. through dedicated virtual keyboards, or by accessing on-device records for these data (from the address book, bookmarks, etc.).</p>
<p data-feature="Customized text entries"><a data-featureid="inputdate">Date and time entries</a> can take advantage of a number of dedicated form controls (e.g. <code><input type="date"></code>) to trigger the use of a native calendar control, avoiding the need to create custom JS-based controls that cannot be easily tailored to cope for the variety of mobile devices available on the market. Beware though: specific browsers may only support a subset of these controls, falling back to regular text entries when the input type value is not supported.</p>
<p data-feature="Input validation">The <code><a data-featureid="inputpattern">pattern</a></code> attribute allows both to guide user input as well as to avoid server-side validation (which requires a network round-trip) or JavaScript-based validation (which takes up more resources), both useful optimization on constrained mobile devices.</p>
<p data-feature="Input hint">The <code><a data-featureid="inputhint">placeholder</a></code> attribute allows to guide user input by inserting hints that describe the type of content expected in a text-entry control.</p>
<p data-feature="Form autocomplete">The <code><a data-featureid="datalist"><datalist></a></code> element allows creating free-text input controls coming with <strong>pre-defined values</strong> the user can select from; the <a data-featureid="autocomplete"><code>autocomplete</code> attribute</a> is a mechanism to automatically fill input fields based on <strong>well-known data</strong> for the user, solving the problem of working with long and multi-page forms that are common on mobile devices, e.g. in mobile purchase scenarios.</p>
</section>
<section>
<h2>Discontinued features</h2>
<dl>
<dt>Input modality</dt>
<dd>The <code><a data-featureid="inputmode">inputmode</a></code> attribute defined the type of textual input expected in a text entry. Mobile browsers could use that hint to render the right type of on-screen keyboard, for instance to display a keypad when the user was expected to enter a credit card number. This attribute is no longer supported in recent browsers and has been removed from HTML. Developers are encouraged to use more specific input types (such as <code>tel</code>, <code>email</code> and <code>url</code>).</dd>
</dl>
</section>
</main>
<script src="../js/generate.js"></script>
</body>
</html>