HTML — フォーム序論

4.10.1.1. ~form~UIの書法

この概略的な序論の目的においては、 ピザを注文する~formを作成することにする。 ◎ For the purposes of this brief introduction, we will create a pizza ordering form.

どの~formも `form$e 要素で開始され、 その内側にいくつかの~controlが置かれる。 ほとんどの~controlは、 `input$e 要素により表現される — それは、 既定では~text~controlを供する。 ~controlには、 `label$e 要素を利用して~labelを与えれる — ~label~textと当の~controlは、 `label$e 要素の内側に置く。 ~formを成す各~部位は，`段落$と見なされ、 概して `p$e 要素を利用して他から分離される。 これらを併せると、 顧客の名前を尋ねる~formは，次の様になる： ◎ Any form starts with a form element, inside which are placed the controls. Most controls are represented by the input element, which by default provides a text control. To label a control, the label element is used; the label text and the control itself go inside the label element. Each part of a form is considered a paragraph, and is typically separated from other parts using p elements. Putting this together, here is how one might ask for the customer's name:

次に、 利用者がピザのサイズを選定できるようにする — そのためには、 一群の~radio~buttonを利用できる。 ~radio~buttonも `input$e 要素を利用するが、 今度は `type$a 属性を値 `radio$v にする。 ~radio~buttonたちを~groupとして働かせるためには、 各自の `name$a 属性に共通な名前を与える。 また、 一連の~control — この事例では，~radio~buttonたち — を，まとまった~groupとして呈示するためには、 `fieldset$e 要素を利用する。 そのような~groupに~titleを与えるため、 `fieldset$e 内の最初の要素として `legend$e 要素を与える必要がある： ◎ To let the user select the size of the pizza, we can use a set of radio buttons. Radio buttons also use the input element, this time with a type attribute with the value radio. To make the radio buttons work as a group, they are given a common name using the name attribute. To group a batch of controls together, such as, in this case, the radio buttons, one can use the fieldset element. The title of such a group of controls is given by the first element in the fieldset, which has to be a legend element.

注記： 前~段からの変更点は、 強調して示される。 ◎ Changes from the previous step are highlighted.

ピザの各種トッピングを選び取れるようにするには、 ~checkboxを利用できる。 それは、 `type$a 属性が `checkbox$v に設定された `input$e 要素を利用する： ◎ To pick toppings, we can use checkboxes. These use the input element with a type attribute with the value checkbox:

この~formが書されたピザ屋は，よく間違いをおかすので、 顧客に連絡する仕方も必要になる。 その目的に特に用意された~form~controlとして、 電話番号 （ `type$a 属性が `tel$v に設定された `input$e 要素）, ~email~address （ `type$a 属性が `email$v に設定された `input$e 要素） がある： ◎ The pizzeria for which this form is being written is always making mistakes, so it needs a way to contact the customer. For this purpose, we can use form controls specifically for telephone numbers (input elements with their type attribute set to tel) and email addresses (input elements with their type attribute set to email):

配達~時刻を尋ねるには、 `type$a 属性が `time$v に設定された `input$e 要素を利用できる。 これらの~form~controlの多くには、 指定できる値の正確な範囲を制御するための属性がある。 この事例で特に関心があるのは、［ `min$a, `max$a, `step$a ］属性であり，順に［ 最小な時刻, 最大な時刻, 時刻に許容される（秒t数による）間隔 ］を設定する。 このピザ屋の配達~営業時間は午前 11 時から午後 9 時までで， 15 分t刻みより細かい配達~時刻は約束しないとする。 次のように~mark-upすれば、 そのようにできる： ◎ We can use an input element with its type attribute set to time to ask for a delivery time. Many of these form controls have attributes to control exactly what values can be specified; in this case, three attributes of particular interest are min, max, and step. These set the minimum time, the maximum time, and the interval between allowed values (in seconds). This pizzeria only delivers between 11am and 9pm, and doesn't promise anything better than 15 minute increments, which we can mark up as follows:

`textarea$e 要素を利用すれば、 複数行な~text~controlを供せる。 この例では、 それを利用して，顧客が他の配達指示を与えるための場を供することにする： ◎ The textarea element can be used to provide a multiline text control. In this instance, we are going to use it to provide a space for the customer to give delivery instructions:

最後に、 `button$e 要素を利用して，~formを提出-可能にする： ◎ Finally, to make the form submittable we use the button element:

4.10.1.2. ~form用の~server側~処理を実装するとき

~server側の処理器を書するための正確な詳細は、 この仕様の視野から外れる。 この序論の目的においては、 `https://pizza.example.com/order.cgi^c にある~scriptが［ `application/x-www-form-urlencoded$v 形式を利用している提出 ］を受容するよう環境設定されていて，［ ~HTTP `POST$M 要請の本体~内に次に挙げる~parameterが送信される ］ことを期待しているものと見做す： ◎ The exact details for writing a server-side processor are out of scope for this specification. For the purposes of this introduction, we will assume that the script at https://pizza.example.com/order.cgi is configured to accept submissions using the application/x-www-form-urlencoded format, expecting the following parameters sent in an HTTP POST body:

`custname^c

顧客の名前 ◎ Customer's name

`custtel^c

顧客の電話番号 ◎ Customer's telephone number

`custemail^c

顧客の~email~address ◎ Customer's email address

`size^c

ピザのサイズ — 次に挙げるいずれか ⇒ `small^v, `medium^v, `large^v ◎ The pizza size, either small, medium, or large

`topping^c

選定された各トッピングごとに，次に挙げるいずれかが値に指定される ⇒ `bacon^v, `cheese^v, `onion^v, `mushroom^v ◎ A topping, specified once for each selected topping, with the allowed values being bacon, cheese, onion, and mushroom

`delivery^c

要請された配達~時刻 ◎ The requested delivery time

`comments^c

配達指示 ◎ The delivery instructions

4.10.1.3. ~formを~serverと通信するように環境設定するとき

~form提出は、 種々の仕方で — 最も共通的~には、 ~HTTP［ `GET$M ／ `POST$M ］要請として — ~serverに公開される。 利用する正確な~HTTP~methodを指定するためには、 `form$e 要素に `method$a 属性を指定する。 これは、 ~form~dataの符号化-法を指定するものではない — それには、 `enctype$a 属性を利用する。 また、 `action$a 属性を利用して，［ 提出される~dataを取扱うことになる~service ］の`~URL$も指定する必要がある。 ◎ Form submissions are exposed to servers in a variety of ways, most commonly as HTTP GET or POST requests. To specify the exact method used, the method attribute is specified on the form element. This doesn't specify how the form data is encoded, though; to specify that, you use the enctype attribute. You also have to specify the URL of the service that will handle the submitted data, using the action attribute.

~serverに提出される~dataは、 一連の［ 名前, 値（省略可） ］が成す組からなるので、 提出~内に含ませたい各~form~controlには，名前を与える必要がある。 `name$a 属性が，それを指定する。 ~radio~buttonたちが成す~group用には、 すでに名前を指定した。 各~radio~buttonには， `value$a 属性を利用して互いに異なる値を与えたので、 提出~内でも どれが選定されたか判別できる。 ◎ For each form control you want submitted, you then have to give a name that will be used to refer to the data in the submission. We already specified the name for the group of radio buttons; the same attribute (name) also specifies the submission name. Radio buttons can be distinguished from each other in the submission by giving them different values, using the value attribute.

複数の~controlに同じ名前を与えれる。 例えばここでは，すべての~checkboxに同じ名前を与えるが、 ~radio~buttonと同様，それらにも `value$a 属性に一意な値を与えることにより、 ~serverは，どの~checkboxが~checkされたかを［ 当の名前を伴って提出された値 ］を見て判別できるようになる。 ◎ Multiple controls can have the same name; for example, here we give all the checkboxes the same name, and the server distinguishes which checkbox was checked by seeing which values are submitted with that name — like the radio buttons, they are also given unique values with the value attribute.

これらすべてを，前~節の設定群に加えると、 次のようになる： ◎ Given the settings in the previous section, this all becomes:

注記： 属性の値には，引用符で括られたもの, 括られてないものがあるが、 有意な違いはない。 `§ 構文＠~HTMLwriting#syntax-attributes$ にて論じられるとおり、 ~HTML構文においては，［ 等しく妥当な，属性を指定する種々の仕方 ］が許容される。 ◎ There is no particular significance to the way some of the attributes have their values quoted and others don't. The HTML syntax allows a variety of equally valid ways to specify attributes, as discussed in the syntax section.

~formData1

4.10.1.4. ~client側の~form検証

~formには、［ 提出する前に，利用者の入力を~UAに検査してもらう ］よう注釈できる。 検査したとしても、 ~serverは，入力が妥当かどうか検証yする必要がある （敵対的な利用者は、 ~form検証を容易に迂回できるので） — それでも、 検査を~serverのみに任せた場合に利用者が被る待機-は，避けれるようになる。 ◎ Forms can be annotated in such a way that the user agent will check the user's input before the form is submitted. The server still has to verify the input is valid (since hostile users can easily bypass the form validation), but it allows the user to avoid the wait incurred by having the server be the sole checker of the user's input.

最も単純な注釈は `required$a 属性であり、 `input$e 要素に指定できる。 これにより、［ 当の要素に値が与えられない限り，~formは提出されない ］よう指示できる。 この属性を［ 顧客の名前, ピザのサイズ, 配達~時刻 ］各~欄に追加すれば、 利用者が［ それらのうち いずれかの欄を埋めずに~formを提出しようとした ］とき，~UAは［ その旨を利用者に通知できる ］ようになる： ◎ The simplest annotation is the required attribute, which can be specified on input elements to indicate that the form is not to be submitted until a value is given. By adding this attribute to the customer name, pizza size, and delivery time fields, we allow the user agent to notify the user when the user submits the form without filling in those fields:

入力の長さを制限することも、 `maxlength$a 属性を利用すればアリになる。 これを `textarea$e 要素に追加して，例えば 1000 文字までに制限すれば、 多忙な配達人が利用者からの長文に余計な気を使わされることを防止できる。 ◎ It is also possible to limit the length of the input, using the maxlength attribute. By adding this to the textarea element, we can limit users to 1000 characters, preventing them from writing huge essays to the busy delivery drivers instead of staying focused and to the point:

注記： ~formが提出される際に，妥当でない~form~controlがある場合、 `invalid$et ~eventが それらに向けて発火される。 これは、 ~formにおける問題の要約を表示するときに有用になり得る — ~browserは、 概して，一時に 1 個の問題しか報告しないので。 ◎ When a form is submitted, invalid events are fired at each form control that is invalid. This can be useful for displaying a summary of the problems with the form, since typically the browser itself will only report one problem at a time.

4.10.1.5. ~client側で~form~controlを自動的に埋めることを可能化する

~browserには、 利用者が自身の情報を毎回 手入力する手間を省けるよう， ~form~controlを自動的に埋めて利用者を援助しようと試みるものもある。 例えば、 利用者の電話番号を尋ねる欄を，利用者のそれで自動的に埋めるなど。 ◎ Some browsers attempt to aid the user by automatically filling form controls rather than having the user reenter their information each time. For example, a field asking for the user's telephone number can be automatically filled with the user's phone number.

`autocomplete$a 属性を利用すれば、 ~UAに これを促すような欄の目的を述べれる。 この~formの事例では、 ピザの配達-先についての情報を与える 3 個の欄を，この仕方で有用に注釈でき、 その結果は次の様になる： ◎ To help the user agent with this, the autocomplete attribute can be used to describe the field's purpose. In the case of this form, we have three fields that can be usefully annotated in this way: the information about who the pizza is to be delivered to. Adding this information looks like this:

4.10.1.6. 携帯~機器における利用者~体験を改善する

利用者に複数の入力~modal性を供する機器もある — 特に，~virtual-keyboardを備えるものなど。 例えば，利用者は、［ ~credit-card番号を打込むときは，数字~UIkey（ 0〜9 ）のみを見たい／ 名前を打込む~form欄は，各~単語を既定で大字~化したい ］と望むであろう。 ◎ Some devices, in particular those with virtual keyboards can provide the user with multiple input modalities. For example, when typing in a credit card number the user may wish to only see keys for digits 0-9, while when typing in their name they may wish to see a form field that by default capitalizes each word.

`inputmode$a 属性を利用すれば、 適切な入力~modal性を選定できる： ◎ Using the inputmode attribute we can select appropriate input modalities:

4.10.1.7. 欄の型（ `type^a ）, ~autofill欄~名（ `autocomplete^a ）, 入力~modal性（ `inputmode^a ）の相違

`type$a, `autocomplete$a, `inputmode$a 属性は、 混同され易いかもしれない。 一例として、 これらのどれに対しても，文字列 `email^l は妥当な値になる。 この節では、 これらの属性~間の相違を~~説明するよう試みて， これらの用-法を示唆する助言を供する。 ◎ The type, autocomplete, and inputmode attributes can seem confusingly similar. For instance, in all three cases, the string "email" is a valid value. This section attempts to illustrate the difference between the three attributes and provides advice suggesting how to use them.

`input$e 要素の `type$a 属性は、 ~UAがどの種類の~controlを利用して欄を公開するかを裁定する。 この属性に与える値を選ぶことは、 `input$e, `textarea$e, `select$e, 等々から どの要素を利用するか選ぶことに相似する。 ◎ The type attribute on input elements decides what kind of control the user agent will use to expose the field. Choosing between different values of this attribute is the same choice as choosing whether to use an input element, a textarea element, a select element, etc.

対照的に `autocomplete$a 属性は、 利用者が手入力する値が，実際には何を表現するかについて述べる。 この属性に与える値を選ぶことは、 要素にどの~labelをあてがうか選ぶことに相似する。 ◎ The autocomplete attribute, in contrast, describes what the value that the user will enter actually represents. Choosing between different values of this attribute is the same choice as choosing what the label for the element will be.

まず、 ある~pageが利用者に電話番号を尋ねている場合を考える。 これに適任な~form~controlは `tel$stT になるが、 どの `autocomplete$a 値を利用するかは，~pageが どの電話番号を尋ねているか — 電話番号に［ 国際-形式, 地域-形式 ］どちらを期待するか, 等々 — に依存する。 ◎ First, consider telephone numbers. If a page is asking for a telephone number from the user, the right form control to use is <input type=tel>. However, which autocomplete value to use depends on which phone number the page is asking for, whether they expect a telephone number in the international format or just the local format, and so forth.

例えば、 ~e-commerce-siteで知人~宛にギフトを買う顧客~向けに，~checkoutを処理する~pageは、 （支払い票のための）顧客の電話番号, （配達~票のための）知人の電話番号 の両方を必要とするであろう。 ~siteが（国別codeを伴う）国際-電話番号を期待する場合、 これは次の様になる： ◎ For example, a page that forms part of a checkout process on an e-commerce site for a customer buying a gift to be shipped to a friend might need both the buyer's telephone number (in case of payment issues) and the friend's telephone number (in case of delivery issues). If the site expects international phone numbers (with the country code prefix), this could thus look like this:

<p><label>客様の電話番号： <input type=tel name=custtel autocomplete="billing tel"></label>
<p><label>送先の電話番号： <input type=tel name=shiptel autocomplete="shipping tel"></label>
<p>国別codeも含めた国際-電話番号を入れます。（例： +1 999 123 4567 ）

一方で、 ~siteが，~supportする顧客と送先を日本~国内に限るならば、 次の様になろう （ `~tel0$v に代えて `tel-national$v を利用することに注目）： ◎ But if the site only supports British customers and recipients, it might instead look like this (notice the use of tel-national rather than tel):

<p><label>客様の電話番号： <input type=tel name=custtel autocomplete="billing tel-national"></label>
<p><label>送先の電話番号： <input type=tel name=shiptel autocomplete="shipping tel-national"></label>
<p>国別codeは不要です。日本~国内の電話番号を入れます。（例： (0999) 123 4567 ）

今度は、 個人が選好する言語を考える。 適任な `autocomplete$a 値は `language$v になるが、 この目的に利用される~form~controlは， ~text~control（ `text$stT ）, ~drop-down~list（ <`select$e> ）, ~radio~button（ `radio$stT ）, 等々、いろいろあり得る。 それは、 どの種類の~UIが欲されるかのみに依存する。 ◎ Now, consider a person's preferred languages. The right autocomplete value is language. However, there could be a number of different form controls used for the purpose: a text control (<input type=text>), a drop-down list (<select>), radio buttons (<input type=radio>), etc. It only depends on what kind of interface is desired.

~~最後に、 ~pageが利用者の名前を求める場合を考える。 関連な~controlは `text$stT になる。 ~pageが利用者の全部的な名前を尋ねる場合、 関連な `autocomplete$a 値は `name$v になる。 ◎ Finally, consider names. If a page just wants one name from the user, then the relevant control is <input type=text>. If the page is asking for the user's full name, then the relevant autocomplete value is name.

<p><label>名前（日本語）： <input name="j" type="text" autocomplete="section-jp name"></label>
<label>名前（~romanized）： <input name="e" type="text" autocomplete="section-en name"></label>

この例では、 `autocomplete$a 属性の値~内の "`section-*$v" ~keywordが， 期待する名前として`異なる^em 2 個の欄があることを~UAに伝える。 それらが無ければ、 ~UAは，［ 利用者が 1 個目の欄に値を与えたとき， 2 個目の欄を 1 個目の欄に与えられた値で自動的に埋める ］こともできる。 ◎ In this example, the "section-*" keywords in the autocomplete attributes' values tell the user agent that the two fields expect different names. Without them, the user agent could automatically fill the second field with the value given in the first field when the user gave a value to the first field.

注記： ~keywordの `-jp^l, `-en^l が成す部位は、 ~UAにとっては不透明になる 【単なる識別子でしかない】 — ~UAは、 それらから，当の 2 個の名前~欄に日本語, 英語が期待されていることを推測できない。 ◎ The "-jp" and "-en" parts of the keywords are opaque to the user agent; the user agent cannot guess, from those, that the two names are expected to be in Japanese and English respectively.

`type$a, `autocomplete$a に関する~~選択とは別に、 `inputmode$a 属性は，［ ~controlが~text~controlであるとき，どの種類の入力~modal性を利用するか ］を裁定する （例：~virtual-keyboard）。 ◎ Separate from the choices regarding type and autocomplete, the inputmode attribute decides what kind of input modality (e.g., virtual keyboard) to use, when the control is a text control.

~credit-card番号を考える。 `後で説明する＠~HEinput#when-number-is-not-appropriate$ように、 入力に適切な型は， `number$stT `ではなく^em `text$stT である。 ~UAが常に数的な入力~modal性を利用するよう促すためには （例：数字のみを表示している~virtual-keyboard）、 ~pageは次を利用することになる： ◎ Consider credit card numbers. The appropriate input type is not <input type=number>, as explained below; it is instead <input type=text>. To encourage the user agent to use a numeric input modality anyway (e.g., a virtual keyboard displaying only digits), the page would use

<p><label>~credit-card番号：<input
  name="cc"
  type="text"
  inputmode="numeric"
  pattern="[0-9]{8,19}"
  autocomplete="cc-number"
></label></p>

4.10.1.8. 日付, 時刻, 実数 の形式

このピザ配達~例では、 時刻は "HH:MM" の形式 — 24 ~~時間~形式で時tを与える 2 個の数字と, 分tを与える 2 個の数字 — で指定される （秒tも指定できるが、この例には必要yでない）。 ◎ In this pizza delivery example, the times are specified in the format "HH:MM": two digits for the hour, in 24-hour format, and two digits for the time. (Seconds could also be specified, though they are not necessary in this example.)

しかしながら，利用者に呈示される時刻の表し方は、 ~localeに応じて異なることが多い。 例えば，米国では、 "2pm" など， "am"／"pm" 指示子と 12 ~~時間~~範囲で表出するのが いまだに共通的である。 ~Franceでは、 "14h00" など，文字 "h" で時tと分tを分離するのが共通的である。 ◎ In some locales, however, times are often expressed differently when presented to users. For example, in the United States, it is still common to use the 12-hour clock with an am/pm indicator, as in "2pm". In France, it is common to separate the hours from the minutes using an "h" character, as in "14h00".

日付についても同様で、 各 成分の順序ですら常に一貫するとは限らない。 例えば， 英語の日付 `first of February 2003^en は、 ~Cyprusでは概して "1/2/03" と記され， 日本では概して "2003年 2月 1日" と記される。 実数においても、 例えば，小数点や 3 桁ごとの分離子に利用される約物は、 ~localeに応じて相違する。 ◎ Similar issues exist with dates, with the added complication that even the order of the components is not always consistent — for example, in Cyprus the first of February 2003 would typically be written "1/2/03", while that same date in Japan would typically be written as "2003年02月01日" — and even with numbers, where locales differ, for example, in what punctuation is used as the decimal separator and the thousands separator.

したがって，［ 日付／時刻／実数 ］に対しては、 “伝送路” 上で — すなわち、~HTML~markupや~form提出にて — 利用される形式と， ~browserが［ 利用者に呈示する形式／利用者~入力として受容する形式 ］とを判別することが重要になる。 伝送路~形式は、 常に，この仕様で定義される形式になる （それは、 機械読取可能な日付＆時刻の形式~用に きちんと確立された ISO 8601 標準に基づく）。 ◎ It is therefore important to distinguish the time, date, and number formats used in HTML and in form submissions, which are always the formats defined in this specification (and based on the well-established ISO 8601 standard for computer-readable date and time formats), from the time, date, and number formats presented to the user by the browser and accepted as input from the user by the browser.

“伝送路” 形式は、 機械読取可能になるものと意図されており， 利用者の~localeが何であれ一貫する。 一例として、 日付は， "2003-02-01" のように常に "YYYY-MM-DD" （ year-month-date ／~~年-~~月-~~日）の形式で記される。 一部の利用者は，この形式を見るかもしれない一方で、 他の利用者は "01.02.2003" や "February 1, 2003" として見る【~UAが，そのように呈示する】かもしれない。 ◎ The format used "on the wire", i.e., in HTML markup and in form submissions, is intended to be computer-readable and consistent irrespective of the user's locale. Dates, for instance, are always written in the format "YYYY-MM-DD", as in "2003-02-01". While some users might see this format, others might see it as "01.02.2003" or "February 1, 2003".

~pageにより伝送路~形式で与えられた［ 日付／時刻／実数 ］は、 利用者に表示される前に， 利用者が選好する呈示に（利用者-選好や ~page自身の~localeに基づいて）翻訳される。 同様に，~UAは、 利用者が選好する形式を利用して入力した［ 日付／時刻／実数 ］を — ~DOM内に~~挿入する前や, ~serverへ提出する前に — 伝送路~形式に逆~変換する。 ◎ The time, date, or number given by the page in the wire format is then translated to the user's preferred presentation (based on user preferences or on the locale of the page itself), before being displayed to the user. Similarly, after the user inputs a time, date, or number using their preferred format, the user agent converts it back to the wire format before putting it in the DOM or submitting it.

これにより，［ ~page内の~script ］や~serverは、［ 日付／時刻／実数 ］を一貫した方式で — 利用者の必要性を~supportしつつ，いくつもの異なる形式を~supportする必要なく — 処理できるようになる。 ◎ This allows scripts in pages and on servers to process times, dates, and numbers in a consistent manner without needing to support dozens of different formats, while still supporting the users' needs.

注記： ~form~controlの地域-化に関する`実装~上の注記＠~HEinput#input-impl-notes$も見よ。 ◎ See also the implementation notes regarding localization of form controls.