4.10.1. 序論

~INFORMATIVE

~formは、[ ~text / ~button / ~checkbox / 範囲 / 色~picker ]などの~form~controlを持つ,~Web頁の~componentである。 利用者は,そのような~formと対話して~dataを提供でき、その~dataは,更なる処理のために(探索や計算の結果を返すなど)~serverへ送信できる。 多くの事例では,~client側の~scriptingは必要ないが、~scriptが[ 利用者~体験を増補する / ~formを~serverへ~dataを提出する以外の目的0で利用する ]ために可用な~APIもある。 ◎ A form is a component of a Web page that has form controls, such as text, buttons, checkboxes, range, or color picker controls. A user can interact with such a form, providing data that can then be sent to the server for further processing (e.g. returning the results of a search or calculation). No client-side scripting is needed in many cases, though an API is available so that scripts can augment the user experience or use forms for purposes other than submitting data to a server.

~formを書くには、 3 つの手続き — ~UIを書く, ~server側~処理を実装する, ~serverと通信するために~UIを環境設定する — が要るが、これらは任意の順序で遂行できる。 ◎ Writing a form consists of several steps, which can be performed in any order: writing the user interface, implementing the server-side processing, and configuring the user interface to communicate with the server.

4.10.1.1. ~form~UIの書き方

~INFORMATIVE

この概略的な序論の目的0においては、ピザを注文する~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:

`1^eX

次に、利用者にピザのサイズを選定してもらえるようにする — そのためには、一群の~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.

`2^eX

注記: 前~段からの変更点は、強調して示される。 ◎ 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:

`3^eX

この~formを書いているピザ屋は,よく間違いをおかすので、顧客に連絡する仕方も必要になる。 その目的0に特に用意された~form~controlとして、電話番号( `type$a 属性が `tel$v に設定された `input$e 要素 ),および ~e-mail~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 e-mail addresses (input elements with their type attribute set to email):

`4^eX

配達~時刻tを尋ねるには、 `type$a 属性が `time$v に設定された `input$e 要素を利用できる。 これらの~form~controlの多くには、正確にどの範囲の値を指定できるか制御するための属性がある。 この事例で特に関心があるのは、[ `min$a, `max$a, `step$a ]属性であり、順に,[ 時刻tの最小, 時刻tの最大, 時刻tに許容される(秒t~~単位による)間隔 ]を設定する。 このピザ屋の配達~営業時間は午前 11 時から午後 9 時までで, 15 分t刻みより細かい配達~時刻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:

`5^eX

`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:

`6^eX

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

`7^eX

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

~INFORMATIVE

~server側の処理器を書くための正確な詳細は、この仕様の視野~外である。 この序論の目的0においては、 `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
顧客の~e-mail~address ◎ Customer's e-mail address
`size^c
ピザのサイズ — 次のいずれか: `small^c, `medium^c, `large^c ◎ The pizza size, either small, medium, or large
`topping^c
選定された各トッピングごとに,次のいずれかが値に指定される: `bacon^c, `cheese^c, `onion^c, `mushroom^c ◎ A topping, specified once for each selected topping, with the allowed values being bacon, cheese, onion, and mushroom
`delivery^c
要請された配達~時刻t ◎ The requested delivery time
`comments^c
配達指示 ◎ The delivery instructions

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

~INFORMATIVE

~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:

`8^eX

注記: 属性の値には,引用符で括られているもの, 括られていないものがあるが、有意な違いはない。 構文~節 に論じられるように,~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.

例えば、顧客が次を手入力した場合:

  • 名前は "Mario Luigi"
  • 電話番号は "0999-123-4567"
  • ~e-mail~addressは 指定なし
  • ピザのサイズは 中サイズ
  • トッピングは チーズ増量+マッシュルーム
  • 配達~時刻tは 午後 7 時
  • 配達指示は 空欄のまま

~UAは,~online~Web~serviceに向けて次を提出することになる:

◎ For example, if the customer entered "Denise Lawrence" as their name, "555-321-8642" as their telephone number, did not specify an e-mail address, asked for a medium-sized pizza, selected the Extra Cheese and Mushroom toppings, entered a delivery time of 7pm, and left the delivery instructions text control blank, the user agent would submit the following to the online Web service:
~formData1

4.10.1.4. ~client側の~form検証

~INFORMATIVE

~formには、提出-前に,~UAに利用者の入力を検査してもらうよう注釈できる。 検査したとしても、~serverは,入力が妥当かどうか検証0する必要があるが(敵対的な利用者は、~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は提出されないよう,指示できる。 この属性を[ 顧客の名前, ピザのサイズ, 配達~時刻t ]の各~欄に追加すれば、利用者がそれらのうち いずれかの欄を埋めずに~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:

`9^eX

`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:

`10^eX

注記: ~formが提出される際に,妥当でない~form~controlがある場合、 `invalid$et ~eventが それらに向けて発火され,次に `form$e 要素にも発火される。 これは、~formにおける問題の要約を表示するときに有用になり得る — ~browserは概して,一時に 1 個の問題しか報告しないので。 ◎ When a form is submitted, invalid events are fired at each form control that is invalid, and then at the form element itself. 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の自動~充填を可能化する

~INFORMATIVE

~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にこれを促すような 欄の目的0を記述できる。 この~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:

`11^eX

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

~INFORMATIVE

特に,~screen上に~keyboardを出すものや,文字~種が多い言語(日本語など)の~localeで利用されているものなど、利用者に複数の入力~modalityを提供する機器もある。 例えば利用者は、~credit-card番号を打込むときは,数字 0-9 ~keyのみを見たいと望むであろうし、名前を打込む~form欄は,既定で~capitalizeさせたいと望むであろう。 ◎ Some devices, in particular those with on-screen keyboards and those in locales with languages with many characters (e.g. Japanese), 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 capitalises each word.

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

`12^eX

4.10.1.7. 欄の型( `type^a ), 自動充填される欄の名前( `autocomplete^a ), 入力~modality( `inputmode^a )の間の相違

~INFORMATIVE

`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.

まず、ある頁が利用者に電話番号を尋ねている場合を考える。 これに適任の~form~controlは `tel$stT になるが、どの `autocomplete$a 値を利用するかは,頁が どの電話番号を尋ねているか — 電話番号に 国際~形式か 地域~形式のどちらを期待するか, 等々 — に依存する。 ◎ 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を処理する頁は、 (支払い票のための)顧客の電話番号, (配達~票のための)知人の電話番号 の両方を必要とするであろう。 ~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 になるが、この目的0に利用される~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.

`inputmode$a は、~controlが~text~controlであるときに,どの種類の入力~modality(例: ~keyboard)を利用するかを決める。 ◎ The inputmode decides what kind of input modality (e.g. keyboard) to use, when the control is a text control.

頁が,利用者の名前を求める場合を考える。 関連する~controlは `text$stT になる。 頁が利用者の姓名を尋ねる場合、関連する `autocomplete$a 値は `name$v になる。 一方で、利用者が日本人で,頁が 利用者の日本語~名, ~romanized名を尋ねる場合、 2 つの欄の既定の~modalityが,順に 日本語~入力, ~Latin入力 にされていれば、利用者にとって便利になる(更には、~Latin入力~欄では自動的に~capitalizeしてくれれば理想的)。 `inputmode$a 属性が、~UAにそうするよう促してくれる: ◎ 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. But if the user is Japanese, and the page is asking for the user's Japanese name and the user's romanized name, then it would be helpful to the user if the first field defaulted to a Japanese input modality, while the second defaulted to a Latin input modality (ideally with automatic capitalization of each word). This is where the inputmode attribute can help:

<p><label>名前(日本語): <input name="j" type="text" autocomplete="section-jp name" inputmode="kana"></label>
<label>名前(~romanized): <input name="e" type="text" autocomplete="section-en name" inputmode="latin-name"></label>

この例では、 `autocomplete$a 属性の値~内の "`section-*$v" ~keywordが、期待する名前として 異なる 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にとっては不透明になる `単なる識別子でしかない^tnote — ~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.

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

~INFORMATIVE

このピザ配達~例では、時刻tは "HH:MM" の形式 — 24 時間~形式で時tを与える 2 個の数字と, 分tを与える 2 個の数字 — で指定される(秒tも指定できるが、この例には必要とされない)。 ◎ 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.)

しかしながら,利用者に呈示される時刻tの表し方は、~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".

日付tについても同様で、各 成分の順序ですら常に一貫するとは限らない。 例えば、英語の日付t "first of February 2003" は、~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.

したがって,[ 日付t / 時刻t / 実数 ]に対しては、 “伝送路” 上で — すなわち、~HTML~markupや~form提出にて — 利用される形式と,~browserが[ 利用者に呈示する形式や, 受容する利用者~入力の形式 ]とを判別することが重要になる。 伝送路~形式は、常に,この仕様で定義される形式になる(それは、機械読取可能な日付t&時刻tの形式~用に きちんと確立された 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に関わらず一貫する。 例えば日付tは、 "2003-02-01" のように,常に "YYYY-MM-DD" ( year-month-date )の形式で記される。 この形式が利用者から見えることは期待されていない。 ◎ 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". Users are not expected to ever see this format.

頁により伝送路~形式で与えられた[ 日付t / 時刻t / 実数 ]は、利用者に表示される前に,利用者が選好する呈示に(利用者の選好や 頁~自身の~localeに基づいて)翻訳される。 同様に,~UAは、利用者が選好する形式を利用して入力した[ 日付t / 時刻t / 実数 ]を,~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.

これにより,頁~内の~script, あるいは~serverは、利用者の必要性を~supportしつつ,いくつもの異なる形式を~supportする必要なく,[ 日付t / 時刻t / 実数 ]を一貫した方式で処理できるようになる。 ◎ 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の地域化に関する 実装~上の注記 も見よ。 ◎ See also the implementation notes regarding localization of form controls.