Edit

Page

Page title:

Page body:

[1] [ABBR[[[HTML]]] [ハイパーテキスト・マーク付け言語]] 
の[DFN[[RUBYB[フォーム] [form]]]]とは、
通常の[[内容]]、[[マーク]]、[DFN[[RUBY[[[制御子]]] [コントロール] [control]]]]と呼ぶ特殊な要素、
制御子の[RUBY[[[札]]] [ラベル]]からなる文書の部分です。
[[利用者]]は普通、制御子を編集することによってフォームを[Q[埋]]めてから、
フォームを提出します。

[2] 仕様書:
- [[HTML 4]]
-- [CITE[Forms in HTML documents]] <IW:HTML4:"interact/forms.html">
-- [CITE[B.6 Notes on forms]]
<IW:HTML4:"appendix/notes.html#notes-forms">
-- [CITE[B.10 Notes on security]]
<IW:HTML4:"appendix/notes.html#notes-security">

[3]
:フォームの[RUBY[[[再設定]]] [リセット] [reset]]:
フォームを再設定すると、[[制御子]]の[[現在値]]は[[初期値]]に戻されます。
初期値がない時の挙動は未定義です。 [SRC[HTML 4 17.2]]
:フォームの[RUBYB[[[提出]]] [submit]]:
フォームを提出すると、[[成功]]制御子の名前と現在値の組が[DFN[フォーム処理エージェント]]に渡されます。
[SRC[HTML 4 17.2, 17.13]]

* 概念

[17] 次のような概念や機能があります。
[FIG(short list)[
- [[フォーム制御子]]
-- [[ボタン]]
--- [[既定のボタン]]
- [[フォームの提出]]
- [[フォームデータ集合]]
]FIG]

* レンダリング

[5]
[[WWWブラウザ]]が頁を読み込みながら徐々に[[レンダリング]]していると、
その頁に含まれるフォームも当然徐々にレンダリングされていくことになります。
しかし、 [ABBR[[[UA]]] [[[利用者エージェント]]]] は、
フォーム全体をレンダリングするまで[[利用者]]がフォームを[[提出]]できないようにするべきです。
[[クライアント側スクリプト]]が使われている時にも、
フォームの絡みでうまく動作しなくなる虞があります。
[SRC[HTML 4 B.6.1]]

また、タブ移動 ([CODE(HTMLa)[[[tabindex]]]]) にも注意が必要です。
[SRC[HTML 4 B.6.1]]

[[#comment]]

** 法律に関して

[6] フォーム自体は純粋に技術ですが、そのフォームの使い方により[[法律]]に関する問題が関係することがよくあります。
例えば、[[日本国]]の法律が適用される場合、
[[個人情報]]を扱うのであれば[[個人情報保護法]]に注意する必要があります。
また、[[通信販売]]等の[[商取引]]の目的で使用するのであれば、
[[特定商取引に関する法律]]に基づく表示が必要かもしれません。

[[鯖]]や[[事業者]]や[[利用者]] ([[顧客]]) の所在地など、場合によっては複数の[[国]]・
[[地域]]の[[法律]]や[[条例]]などの対象になることがあるかもしれません。

[[#comment]]

** 安全性に関して

[7]
'''なりすまし''':
[[フォーム]]が含まれる部分を特定の 
[WEAK[(信頼できると思われている有名企業や公的機関、あるいは銀行や通販サイトなどの)]]
[[Webサイト]]の構成や特定のシステム
([[Webブラウザ]]や[[オペレーティング・システム]]の機能など)
の[[画面]]に見せかけたりして、実際の怪しい情報送信先を偽る手口が取られることがよくあります。
[WEAK[(一般に[[利用者]]が常にあらゆることに注意を払い続けることは困難なので、[[フォーム]]ではなく単純な[[リンク]]を用意するだけでも怪しい [[Web頁]]への誘導に十分利用可能です。)]]

[[Web]] が普及して多くの (知識の乏しい) 人も利用するようになったり、
[[商取引]]に利用されることが多くなったりしたこともあり、
近年このような[Q[[[なりすまし]]]]行為の温床となる機能や実装方法自体も
[[Webブラウザ]]等の[[脆弱性]]とみなされるようになっています。

しかし、単体の [[Webブラウザ]]の対策は進んでいますが、
仕様上回避不能な場合もありますし、 [[Webブラウザ]]以外の用途が主のソフトウェアに
[[Webブラウザ]]機能が組込まれている場合は対策が十分でないこともあります。

特に問題が起こり得ると考えられるのは[[電子メイル]]で
[[HTML]] などの[[フォーム]]を利用した場合です。
[[電子メイル]]の送信元情報などは容易に詐称可能なことや、
[[フォーム]]の[[提出]]先の情報を明示しない実装が一般的なことから、
信頼できる送信元からの情報提供依頼に偽装し、
しかも (知識の乏しい) 閲覧者に信頼させることが比較的容易です。

[8]
[[電子メイル]]に[[フォーム]]を含めて送信し、
[[受信者]]に[[提出]]させる方法は現在のところ然程使われていませんから、
[[電子メイル]]の[[利用者エージェント]]は[[フォーム]]を無効にするのがよいかもしれません。
ただ、正しく使えば非常に有益な機能なだけに、
安全対策のために利用できなくなるのは残念なことでもあります。

* 歴史

[4] ウェブのフォームのおおよその進化の過程:
[PRE[
         簡易版フォーム      完全版フォーム      追加機能              関連規格
                                                 isindex
                             HTML+
                               ↓
                             HTML 3
          HTML 2.0  ←←←← (I-D, W3C WD)       file upload
          (RFC 1866)           ↓                (RFC 1867)
            ↓  ↓             ↓                keygen (NN)
      HTML 3.2  HTML 2.x       ↓
     (W3C Rec)  (RFC 2070)→ HTML 4 (Web Forms 1.0)
         ↓                  (W3C Rec)           device-upload
         ↓                    ↓                (W3C Submission)
         ↓                  XHTML 1.0           自動補完 (WinIE 他)   ime-mode (WinIE)
         ↓                  (W3C Rec)           入力制御 (携帯電話)
    Basic        XHTML m12n    ↓                                       XForms 1.0
    Forms Module  (W3C Rec)  Forms Module                               (W3C Rec)
                               ↓
                             Web Forms 2.0                              CSS3
                             (WHAT WD)                                  (W3C Drafts)
]PRE]

** HTML4

[21] [[HTML 4]] 仕様書は、 既知の問題点として、
特に次のことを 
[WEAK[(もしかしたら将来の規格で改善するかもしれない例として)]] 
取り上げています。

[22] [[HTML 4]] 仕様書 [CITE[B.6.2 Future projects]]
<IW:HTML4:"appendix/notes.html#h-B.6.2">

- フォーム欄の種類が現代的な [ABBR[[[UI]]][[[利用者界面]]]]
に比べて少ない。例えば表データやスライド器や複数頁配置の機能が無い。
- 鯖が提出したフォームの欄の値を更新できず、
HTML 文書全体を送らなければならない。
- [[音声ブラウザ]]で[[視覚障害者]]がフォームと[[対話]]するのに問題がある。
- [[[CODE(HTMLe)[input]]//[CODE(HTML)[image]]]]
で[[クライアント側画像写像]]を使えるように [CODE(HTMLa)[[[usemap]]]]
属性を追加するのがよいかも。位置に対応する [CODE(HTMLe)[[[area]]]]
要素が鯖に渡す値を提供する。鯖側のスクリプトを修正しなくて済むように、
[CODE(HTMLe)[area]] が座標を提供できるよう拡張するのが適当かも。

*** Web Forms 1.0

[20] [DFN[Web Forms 1.0]] は、 [[HTML 4.01]] の[[フォーム]]機能の通称です。
[[Web Forms 2.0]] に対する拡張前という意味で使われることがあった語です。

* メモ

[9]
[Q[[CODE[*]] がついた項目は必須です]]のようになってることが多い中、逆に[Q[[CODE[*]] がついた項目は任意です]]なこともあって紛らわしい。

([[名無しさん]] [WEAK[2006-10-30 23:57:10 +00:00]])

* Web Forms

[10] [DFN[Web Forms]] は、[[ウェブ]]で用いられている
[[HTML]] の[[フォーム]]の仕組みです。

[11] 
[DFN[[[Web Forms 1.0]]]] は、 [[HTML 4]] のフォームの章で定義されたフォーム機能です。

元々の HTML 4 版と、そのまま [[XML]] に移植した [[XHTML 1.0]]
版、 [[XHTML m12n]] の [[Forms]] モジュールの大きく3種類がありますが、
いずれも本質的には同じです。

[12] 
[DFN[[[Web Forms 2.0]]]] は、 [[WHAT]] が提案する拡張されたフォーム機能です。
Web Forms 2.0 と既存の [[UA]] 
のフォーム関連の拡張に加えて様々な新機能が含められています。
HTML 4 の拡張と XHTML 1 モジュールの2種類の使い方ができます。

[13] ところで、 Web Forms 1.0 は初代のフォーム ([[HTML 2.0]] 版 ≒
[[HTML 3.2]] 版) にファイル[[うp]]とか [CODE(HTMLe)[[[fieldset]]]]
とかを追加したものなのですけど、初代の方にも誰か番号を付けてくれないのですかね?
0.0 とか 0.5 とか? [[HTTP]] のように 0.9 というのもありかも。

XHTML m12n [[Basic Forms]] モジュール (HTML 3.2 版 + [CODE(HTMLe)[[[label]]]])
にもついでに番号を振ってもらえるといいかもとか。

[14] [CITE@en-GB-x-Hixie[Web Forms 2.0]]
([TIME[2009-01-05 20:07:15 +09:00]] 版)
<http://www.whatwg.org/specs/web-forms/current-work/#forms>

[15] [CITE@ja[使いやすさ日記: 672. Googleが作るとクレジット決済Webフォームはこうなる]]
( ([TIME[2011-02-26 13:52:58 +09:00]] 版))
<http://usability.ueyesdesign.co.jp/diary/672_googleweb.html>

[16] [CITE@en-US[XBL 2.0]]
( ([TIME[2012-05-03 02:23:03 +09:00]] 版))
<http://dev.w3.org/2006/xbl2/Overview.html#html-forms>

[FIG(quote)[
[FIGCAPTION[
[18] [CITE[DocBook 5.x Customizations]]
([TIME[2015-11-14 18:20:15 +09:00]] 版)
<http://docbook.org/schemas/5x-custom.html>
]FIGCAPTION]

> This is a community project; it is not an official product of the DocBook Technical Committee.
> The “forms” schema adds HTML forms elements to DocBook.

]FIG]

[FIG(quote)[
[FIGCAPTION[
[19] [CITE@en[Google Online Security Blog: Next Steps Toward More Connection Security]]
([TIME[2017-05-04 09:56:34 +09:00]])
<https://security.googleblog.com/2017/04/next-steps-toward-more-connection.html>
]FIGCAPTION]

>  Beginning in October 2017, Chrome will show the “Not secure” warning in two additional situations: when users enter data on an HTTP page, and on all HTTP pages visited in Incognito mode.

]FIG]

[23] [CITE@en[New in Chrome 62  |  Web  |  Google Developers]]
([TIME[2017-10-18 04:02:40 +09:00]])
<https://developers.google.com/web/updates/2017/10/nic62>

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Page name(s)