[1] フォームを提出submitすると、 成功制御子の制御子名と現在値の組がフォーム処理エージェントに渡されます。 HTML 4 17.2, 17.13

仕様書

提出の指示

[152] フォーム提出は、次の手段で呼び出すことが出来ます。

[153] フォーム提出の実施

フォームの提出

[39] フォームの提出form submissionは、 次の入力を受け取ります。

フォーム
form 要素。
提出子
フォームの提出元の要素 (普通はボタン)。
submit メソッドからの提出フラグ
boolean。 既定値は偽。

[40] 次のようにしなければなりません >>38。

  1. [41] フォームのnavigateできないが真の場合、
    1. [121] ここで停止します。
  2. [146] フォームのconstructing entry listが真の場合、
    1. [147] ここで停止します。
  3. [43] フォーム文書を、フォームの節点文書に設定します。
  4. [42] フォーム文書の活性砂箱化フラグ集合の砂箱化フォーム閲覧文脈フラグが設定されている場合、
    1. [46] ここで停止します。
  5. [155] フォーム閲覧文脈を、 フォーム文書の閲覧文脈に設定します。
  6. [48] submit メソッドからの提出フラグが偽の場合、
    1. [156] フォームの提出イベント群発火中が真の場合、
      1. [157] ここで停止します。
    2. [158] フォームの提出イベント群発火中を、 真に設定します。
    3. [49] 提出子の非検証状態が偽なら、
      1. [50] 結果を、フォームについて制約群を対話的に検証した結果に設定します。
      2. [51] 結果が偽なら、
        1. [53] フォームの提出イベント群発火中を、 偽に設定します。
        2. [52] ここで停止します。
    4. [161] 提出子がフォームの場合、
      1. [160] 提出子ボタンを、 フォームに設定します。
    5. [162] それ以外の場合、
      1. [163] 提出子ボタンを、 提出子に設定します。
    6. [54] 結果を、イベントを発火した結果に設定します。
      イベントインターフェイス
      SubmitEvent
      イベント型
      submit
      イベント対象
      フォーム
      bubbles
      真
      cancelable
      真
      submitter
      提出子ボタン
    7. [164] フォームの提出イベント群発火中を、 偽に設定します。
    8. [55] 結果が偽の場合、
      1. [56] ここで停止します。
    9. [44] フォームのnavigateできないが真の場合、
      1. [45] ここで停止します。
  7. [57] フォームデータを、フォームと提出子についてフォームデータ集合を構築した結果に設定します。
  8. [148] フォームがnavigateできない場合、
    1. [149] ここで停止します。
  9. [58] 符号化を、フォームについてフォームの符号化を選ぶ処理を実行した結果に設定します。
  10. [59] 作用を、提出子の作用action=""に設定します。
  11. [60] 作用が空文字列なら、
    1. [61] 作用を、フォーム文書のURL文書の番地に設定します。
  12. [62] URLを、作用を提出子の節点文書に対して構文解析URLの構文解析した結果に設定します。
  13. [63] URLが失敗なら、
    1. [64] ここで停止します。
  14. [69] 対象と置換有効と利用者が閲覧文脈を明示したと noopener を、 閲覧文脈の選択の結果に設定します。
    要素
    提出子
    利用者指示
    イベント
  15. [68] 対象が null の場合、
    1. [72] ここで停止します。
  16. [73] フォーム文書の completely loaded が偽で、 submit メソッドからの提出フラグが真の場合、
    1. [76] 置換有効を、真に設定します。
  17. [79] 提出子のメソッド要求メソッドにより、
    GET
    >>84 へ
    POST
    >>85 へ
    ダイアログ<dialog>
    >>80 へ

[159] フォームは、 提出イベント群発火中firing submission eventsを持ちます。 >>38 初期値は偽です。

フォーム検証

[9] 文章入力制御子の入力長制御を完全に行えないなど、環境の事情によっては提出の際に maxlength 属性に基づく検査が必要かもしれません。 (UA の実装方法によっては、初期値が maxlength を満たさない場合やスクリプトによる変更があった場合にも注意が必要です。)

提出のための直列化

[7] HTML 4 が確立された慣習として対応することを要求している HTML 4 17.13.3, 17.13.4 のは、次の場合だけです。
actionmethodenctypeその他
HTTP URIgetapplication/x-www-form-urlencodedフォーム・データは ASCII 文字のみ
HTTP URIpostapplication/x-www-form-urlencodedフォーム・データは ASCII 文字のみ
HTTP URIpostmultipart/form-data

これも含めて、様々な組合せが利用されています。

使用例のある URI scheme:

[25] 使用例のある媒体型:

  • application/x-www-form-urlencoded
  • application/sgml-form-urlencoded
  • application/x-www-form+xml
  • text/plain
  • multipart/form-data
  • application/vnd.wap.multipart.form-data
  • [11] application/vnd.wap.wml.form.urlencode
  • [20] application/x-w3-isindex Emacs/W3
  • [21] application/w-www-form-data Emacs/W3
  • [23] application/x-gopher-query Emacs/W3
  • [24] application/gopher-ask-block Emacs/W3

[26] フォームデータ集合に使われる MIME型の一覧は、
  • [27] data-web-defs/mime-types.txt at master · manakai/data-web-defs ( 版) https://github.com/manakai/data-web-defs/blob/master/doc/mime-types.txt
... にも「form_data」欄として含まれています。

GET の場合

[84] メソッドが GET の場合には、次のようにします >>38。

  1. [86] scheme を、URLの schemeURL scheme に設定します。
  2. [87] scheme が javascriptjavascript: でなければ (>>88)、
    1. [89] query を、フォームデータ集合と符号化について application/x-www-form-urlencoded 直列化器を適用した結果に設定します。
    2. [92] scheme が mailtomailto: なら、
      1. [93] query の + をすべて %20 に置換します。
    3. [90] URL のクエリーURL queryを、query に設定します。
  3. [91] plan to navigate します。
    要求
    URL要求URL
    URL

[88] >>87 は HTML Standard では ftp: の場合も除外されることになっていますが、 Chrome は ftp: でも http: と同じような処理とするようです。 また HTML Standard はその他の URL scheme について明確に規定していませんが、 やはり http: と同じような処理とするようです。

POST の場合

[85] メソッドが POST の場合には、 次のようにします >>38。

  1. [101] URLの schemeURL scheme が HTTP(S) scheme なら、
    1. [102] 提出子の enctype により、
      text/plain
      plan to navigate します。
      要求
      URL要求URL
      URL
      メソッド要求メソッド
      POST
      ヘッダーリスト
      Content-Type
      text/plain
      本体要求本体
      フォームデータ集合と符号化に関して text/plain 直列化器を適用した結果を符号化で符号化したもの
      multipart/form-data
      フォームデータ集合と符号化に関して multipart/form-data 符号化器を適用して得た本体と境界文字列を使って、 plan to navigate します。
      要求
      URL要求URL
      URL
      メソッド要求メソッド
      POST
      ヘッダーリスト
      Content-Type
      multipart/form-data;, U+0020, boundary=, 境界文字列を連結したもの
      本体要求本体
      本体
      application/x-www-form-urlencoded
      plan to navigate します。
      要求
      URL要求URL
      URL
      メソッド要求メソッド
      POST
      ヘッダーリスト
      Content-Type
      application/x-www-form-urlencoded
      本体要求本体
      フォームデータ集合と符号化に関して application/x-www-form-urlencoded 直列化器を適用した結果を UTF-8符号化したもの
  2. [103] それ以外なら、
    1. [104] URLの schemeURL scheme が mailtomailto: なら、
      1. [67] 提出子の enctype が text/plain なら、
        1. [81] 本体を、フォームデータ集合と符号化に関して text/plain 直列化器を適用した結果に設定します。
      2. [82] それ以外なら、
        1. [83] 本体を、フォームデータ集合と符号化に関して application/x-www-form-urlencoded 直列化器を適用した結果に設定します。
      3. [94] query を、URL のクエリーURL queryに設定します。
      4. [96] query が null なら、
        1. [97] query を、空文字列に設定します。
      5. [95] query が空でなければ、
        1. [98] query の末尾に、 & を追加します。
      6. [99] query の末尾に、 body= を追加します。
      7. [106] query の末尾に、本体を application/x-www-form-urlencoded 相当の UTF-8パーセント符号化 (ただし + は不使用。) した結果を追加します。
      8. [100] URL のクエリーURL queryを、 query に設定します。
    2. [105] plan to navigate します。
      要求
      URL要求URL
      URL

[107] mailto: の bodybody= の値について、 HTML Standard は、 application/x-www-form-urlencoded の時そのまま、 text/plain の時既定符号化集合を使った UTF-8パーセント符号化としているのですが、 Chrome はそれだけでなく本来必要な文字すべてをパーセント符号化 (つまり前者の場合二重にパーセント符号化) するようです。 (application/x-www-form-urlencoded と既定符号化集合の比較: Compare character sets "-$url:form:unencoded-byte-char" and "$url:default-encode-set" () https://chars.suikawiki.org/set/compare?expr1=-%24url%3Aform%3Aunencoded-byte-char&expr2=%24url%3Adefault-encode-set) [108] HTML Standard はその他の URL scheme の場合を明確にしていませんが、 Chrome はURLそのままの navigate とするようです。

提出の navigate

[109] form 要素は、 planned navigation を持ちます。 値は、タスクまたは null です。初期値は null です。 >>38

[110] フォームと要求に関して plan to navigate とは、次のようにしなければなりません >>38。

  1. [111] フォームの planned navigation がタスクなら、
    1. [112] フォームの planned navigation が含まれるタスクキューから当該タスクを削除します。
  2. [114] タスクを、タスクに設定します。
    タスク
    処理
    1. [116] フォームの planned navigation を、 null に設定します。
    2. [117] navigate します。
      navigate する閲覧文脈
      対象
      要求
      要求
      置換有効
      置換有効
      新しい最上位閲覧文脈
      置換有効
      ナビゲーション型
      form-submission
      利用者が閲覧文脈を明示した
      利用者が閲覧文脈を明示した
    タスク源
    DOM操作タスク源
  3. [113] フォームの planned navigation を、タスクに設定します。
  4. [115] タスクを、タスクキューに追加します。

ダイアログの提出

[80]

安全性

[14] フォームの提出機能が濫用され、 利用者に第3者を攻撃させるために使われることがあります。 例えば、 SMTP 鯖を提出先とし、 提出により利用者が気づかない間に spam が送信されてしまうことがあるかもしれません。

SMTP や telnet などよく知られたフォーム提出には使われないプロトコルのポート番号が提出先に指定されている時には、 提出を制限することが勧められています。 WF2 1.12

[15]

Certain actions, including submitting a form to a third-party site and making HTTP GET requests to remote sites (both of which would be blind attacks, assuming the UA implements a cross-domain scripting security mechanism) have been historically allowed, and many sites depend on these features for quite legitimate uses. User agents should allow them.

Servers therefore must also consider security. Servers should never perform non-idempotent actions in response to GET requests, as discussed by the HTTP specification. Servers should also check the Referer header to ensure that only requests from trusted hosts are honoured.

Servers should also consider the client to be untrusted, since in most scenarios requests can be made to hosts by hostile parties directly, bypassing any security logic included in the page nominally intended to perform the submission. Thus servers should perform validation on all submitted data, whether such validation is expected to be performed on the client or not.

WF2 1.12

歴史

HTML4

[2]

[4] フォームの提出は、次の手順を経ます。 HTML 4 17.13.3

1. 成功制御子の識別
フォーム内の制御子から、成功しているものを選びます。
2. フォーム・データ集合の構築
成功制御子から、フォーム・データ集合 (制御子名と現在値の組の集合) を構築します。
3. フォーム・データ集合の符号化
フォーム・データ集合を指定された媒体型 (enctype) により符号化します。
4. 符号化フォーム・データ集合の提出
符号化したデータ集合を指定されたフォーム処理エージェント (action) に指定された方法 (method) で送信します。
(5. 結果のレンダリング)
UA は、提出の際の HTTP GET・POST に対する応答をレンダリングするべきです。

[5] >>4 で、提出されるのがフォーム・データ集合 (名前と現在値の組の集合) だけのように書かれていますが、 ファイル選択制御子の場合はそれに含まれないはずのファイルの内容も提出されます。 画像提出ボタン (input//image) の座標との関係も不明確で、概念の整理が不十分という印象を受けます。

[6] なお、 >>4 の流れは、4つの段階を完全に別のものとして扱えるわけではなく、 制御子の種類, 媒体型, 処理エージェントのプロトコルなどの依存関係があります。 仕様や実装によって実際に使用できる組合せは限られてきます。 >>7 をご覧ください。

HTML5

[65] Web Forms 2.0 ( 版) http://www.whatwg.org/specs/web-forms/current-work/#for-http

実装

[8] 2003-10-12 12:52:32 +00:00 名無しさん: 手元の Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 で試してみたら、 enctype は application/x-www-form-urlencoded と text/plain と multipart/form-data に対応していましたが、引数をつけたら全滅でした。

[2] >>1 WinIE 6 と WinOpera 7.20 でも同様でした。但し Opera は text/plain に対応していない模様。

メモ

[3] フォームの提出 (submit) は、意味を解して送信とも呼ばれます。 しかしながら、提出と送信ではニュアンスが異なりますから、 専門用語としては使い分けるべきでしょう。

[10] WAP 2.0 は XHTML m12n + α ですが、 追加の属性の関係でフォーム処理の方法を修正しています。

[12] ヘブライ語が含まれるかもしれない時に get を method に使うのは非推奨です。

[13] 提出先URI (action URI) に既に?が含まれているにもかかわらず提出方法がHTTP getの場合どうするかについて、

Web Forms 2.0の方法は、相対URI参照を使ってもどんどんqueryが長くなっていく虞が無いという利点があります。

Re: Compatibility between HTML, XForms, and WSDL from Ian Hickson on 2005-03-21 (www-forms-editor@w3.org from March 2005) http://lists.w3.org/Archives/Public/www-forms-editor/2005Mar/0008.html

[16] 公開メモ日記 - IEのフォームでsubmitボタンの値が送信されるかどうか http://knoa.jp/memo/?id=2006-07-18+17:26 (名無しさん 2006-07-18 12:02:21 +00:00)

[17] Form Submission by Pressing the Enter Key http://suika.suikawiki.org/~wakaba/-temp/test/html/form/submission/submit-by-enter-1.html

Form Submission by Pressing the Enter Key http://suika.suikawiki.org/~wakaba/-temp/test/html/form/submission/submit-by-enter-2.html

[18] Web Forms 2.0 http://www.whatwg.org/specs/web-forms/current-work/#enter-submit

[19] >>16-18

WinIE 6 では、テキスト入力制御子で Enter を押すと、

Firefox 1.5 と Opera 8 では、どちらも押したとして提出 (名無しさん 2006-07-18 12:05:24 +00:00)

[22] FORM submission and i18n (2006-05-19 20:53:32 +09:00 版) http://ppewww.physics.gla.ac.uk/~flavell/charset/form-i18n.html

メモ

[171] [acgiow] (0) Put method=DELETE and method=PUT to rest., Hixie, , https://github.com/whatwg/html/commit/6b902648c8a55e3a0bfc2aa0968e9b5fc04fd46e

[298] フォームの入力エラーを吹き出しで教えてくれる JavaScript (Kyosuke Takayama 著, 版) http://espion.just-size.jp/archives/07/035231221.html

[299] Web Applications 1.0 r5566 Put method=DELETE and method=PUT to rest.Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=10671 ( ( 版)) http://html5.org/tools/web-apps-tracker?from=5565&to=5566

[300] [whatwg] HTMLForms: Implicit Submission with {display:none} button ( ( 版)) http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033285.html

[301] [whatwg] HTMLForms: Implicit Submission with {display:none} button ( 版) http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-February/034924.html

[302] Web Applications 1.0 r7992 Make <form> submission more like reality. ( 版) http://html5.org/tools/web-apps-tracker?from=7991&to=7992

[303] W3C HTML JSON form submission ( 版) http://darobin.github.io/formic/specs/json/

[304] W3C HTML JSON form submission ( 版) http://www.w3.org/TR/html-json-forms/

[305] W3C HTML JSON form submission ( ( 版)) http://www.w3.org/TR/2014/WD-html-json-forms-20140529/

[306] darobin/formic ( ( 版)) https://github.com/darobin/formic

[28] Integrate Fetch into HTML · whatwg/html@7c5555a ( 版) https://github.com/whatwg/html/commit/7c5555a16f2920c02244c10756bb2f1a11e87a22

[29] W3C HTML JSON form submission ( 版) http://www.w3.org/TR/2015/NOTE-html-json-forms-20150929/

This specification is no longer in active maintenance and the HTML Working Group does not intend to maintain it further.

[30] Remove allow non-ASCII-compatible encodings flag · whatwg/html@c485b70 ( 版) https://github.com/whatwg/html/commit/c485b70bfe41ed1302c451bc62b58df80cffd325

[31] Let the URL Standard deal with application/x-www-form-urlencoded · whatwg/html@0fef169 ( 版) https://github.com/whatwg/html/commit/0fef169e6fca7433e3aac2a3640b4665b791ff8e

[32] Update integration with Encoding Standard · whatwg/html@6a31c26 ( 版) https://github.com/whatwg/html/commit/6a31c26cf12e39dab1a488e75dd56c03d6786d39

[33] Remove <isindex> and <input name=isindex> · whatwg/html@5c44abc ( 版) https://github.com/whatwg/html/commit/5c44abc734eb483f9a7ec79da5844d2fe63d9c3b

[34] Fix form submission for the data URL scheme ( (annevk著, )) https://github.com/whatwg/html/commit/e2d80d9285976c6c38bda188c59e97456006d0a3

[35] Clean up language around form submission and URLs ( (annevk著, )) https://github.com/whatwg/html/commit/69ea9df17bf1d7d70a2014c6d2aaf16670683feb

[36] Fix form submission's encoding algorithms ( (annevk著, )) https://github.com/whatwg/html/commit/ec42efb1d7c3a2e34db21b8076a8a3f4bd6dfb81

[37] Only allow form submission for forms in a shadow-including document ( (annevk著, )) https://github.com/whatwg/html/commit/4bdac7a69ebd8a65ed7a8f198d24515c95a07301

[118] Upstream navigation hooks from CSP (mikewest著, ) https://github.com/whatwg/html/commit/2083b0053a059f692a0a95547ba9b6bd0c511094

[74] Revamp the rules for choosing a browsing context (annevk著, ) https://github.com/whatwg/html/commit/5578a0495f826a56597288b7ba1f71163f17cdd6

[75] Fix form connectedness check, but also warn about it (domenic著, ) https://github.com/whatwg/html/commit/df520f824a0f5b705059855a602d47590629b2aa

[77] Editorial: centralize target attribute processing (annevk著, ) https://github.com/whatwg/html/commit/0b31844d6dcc7ef49b3815f4f709d4c0284378f1

[78] Deduplicate finding the correct target attribute · Issue #2619 · whatwg/html () https://github.com/whatwg/html/issues/2619

[119] Editorial: centralize target attribute processing by annevk · Pull Request #3007 · whatwg/html () https://github.com/whatwg/html/pull/3007

[120] Centralize checks for <a>, <area>, <form>, and <link> (annevk著, ) https://github.com/whatwg/html/commit/f3c354add894e1ac01e3732ff976aa9874a77b3f

[47] <a>, <area>, <link>, and <form> behavior · Issue #2615 · whatwg/html () https://github.com/whatwg/html/issues/2615

[122] Form submission: Should check connected twice · Issue #2708 · whatwg/html () https://github.com/whatwg/html/issues/2708

[123] Centralize checks for <a>, <area>, <form>, and <link> by annevk · Pull Request #2613 · whatwg/html () https://github.com/whatwg/html/pull/2613

[124] 10671 – consider adding support for PUT and DELETE as form methods () https://www.w3.org/Bugs/Public/show_bug.cgi?id=10671

[125] ISSUE-195: Enhance http request generation from forms - HTML Weekly Tracker () https://www.w3.org/html/wg/tracker/issues/195

[126] ISSUE-196: Define user agent http response handling behaviour - HTML Weekly Tracker () https://www.w3.org/html/wg/tracker/issues/196

[127] Remove _charset_ handling. by tkent-google · Pull Request #382 · whatwg/url () https://github.com/whatwg/url/pull/382

[128] Move _charset_ handling to construct the form data set (tkent-google著, ) https://github.com/whatwg/html/commit/8c212e549607a41b6d40d953b47d9f3e749533f3

[129] <input type=hidden name=_charset_> doesn't match to browser implementations · Issue #3560 · whatwg/html () https://github.com/whatwg/html/issues/3560

[130] Move _charset_ handling from "multipart/form-data encoding algorithm"… by tkent-google · Pull Request #3645 · whatwg/html () https://github.com/whatwg/html/pull/3645

[131] FormData: remove 'type' mapping for 'entry' (tkent-google著, ) https://github.com/whatwg/xhr/commit/0b0dce11579fc504c7f1799b9714e99bec9e9df1

[132] Remove 'type' mapping for 'entry'. by tkent-google · Pull Request #206 · whatwg/xhr () https://github.com/whatwg/xhr/pull/206

[133] Remove 'type' from form data set tuples (tkent-google著, ) https://github.com/whatwg/html/commit/a1e8b1a9725dc716326f564b91a29aca19daf2f2

[134] Remove 'type' from form data set tuples. by tkent-google · Pull Request #3658 · whatwg/html () https://github.com/whatwg/html/pull/3658

[135] Remove "type" from "form data set" entry · Issue #3648 · whatwg/html () https://github.com/whatwg/html/issues/3648

[136] Remove 'type' from from data entries. by tkent-google · Pull Request #384 · whatwg/url () https://github.com/whatwg/url/pull/384

[137] Remove form and submitter words and leave type declarations by amoseui · Pull Request #3688 · whatwg/html () https://github.com/whatwg/html/pull/3688

[138] Editorial: remove form and submitter type declarations (amoseui著, ) https://github.com/whatwg/html/commit/a3dca41f0bb379f4132689dd8fa435be28223a7c

[139] Editorial: replace "form data set" with "entry list" (from FormData) (tkent-google著, ) https://github.com/whatwg/html/commit/f95aba71309d831e75ed12fbc20c7d086e8244e3

[140] Use "entry" and "entry list" defined in XHR · Issue #3676 · whatwg/html () https://github.com/whatwg/html/issues/3676

[141] Use "entry" and "entry list" defined in XHR by tkent-google · Pull Request #3687 · whatwg/html () https://github.com/whatwg/html/pull/3687

[142] Editorial: replace "form data set" with "entry list" (from FormData) (tkent-google著, ) https://github.com/whatwg/html/commit/f95aba71309d831e75ed12fbc20c7d086e8244e3

[143] Change query state slightly to better deal with non-UTF-8 encodings (annevk著, ) https://github.com/whatwg/url/commit/f0e4390bf882446445e944215524ff3877aac95a

[144] "html" error mode somewhat incompatible with URLs · Issue #139 · whatwg/encoding () https://github.com/whatwg/encoding/issues/139

[145] Event-based form participation (tkent-google著, ) https://github.com/whatwg/html/commit/1375c0ca5dd95ecb2ae5ad1d8d7bcc9bc75981c0

[150] Need callback for form submit data · Issue #187 · w3c/webcomponents () https://github.com/w3c/webcomponents/issues/187

[151] Event-based form participation by tkent-google · Pull Request #4239 · whatwg/html () https://github.com/whatwg/html/pull/4239

[154] Introduce SubmitEvent for the form 'submit' event (tkent-google著, ) https://github.com/whatwg/html/commit/f476180797e6124074b3cfeaf1973ea39eb6c499

[70] Would be nice if submit events exposed the "submitter" element · Issue #3195 · whatwg/html () https://github.com/whatwg/html/issues/3195

[71] Forms: Introduce SubmitEvent for 'submit' event by tkent-google · Pull Request #4984 · whatwg/html () https://github.com/whatwg/html/pull/4984

[165] Add <form>'s "firing submission events" flag (tkent-google, , ) https://github.com/whatwg/html/commit/cb55dca6a71e79a5ce3e078dc8d7b525c890bfe8

[166] Add <form>'s "firing submission events" flag (tkent-google, , ) https://github.com/whatwg/html/commit/cb55dca6a71e79a5ce3e078dc8d7b525c890bfe8

[167] Reentrancy protection for 'submit' event · Issue #4620 · whatwg/html () https://github.com/whatwg/html/issues/4620

[168] Add form.requestSubmit() by domenic · Pull Request #4597 · whatwg/html () https://github.com/whatwg/html/pull/4597

[169] Add <form>'s "firing submission events" flag by tkent-google · Pull Request #4621 · whatwg/html () https://github.com/whatwg/html/pull/4621

[170] The WHATWG Blog — Newline normalizations in form submission, https://blog.whatwg.org/newline-normalizations-in-form-submission

[174] >>173 は Ian Hickson の最近?のコメントを取ってきてるらしいのが貴重だけど、それをそのまま書いてるわけではないのが残念。

[175] でもそのかいあって >>173 は >>172 より解像度は確かに上がっている気はする。 にも関わらず >>172 も >>173 も Web Forms 2.0 に一言も言及していないのはどういうことなんだろう。

[176] >>173 を読むと Hixie は初めから全てを見通していて、 幻想を抱く者たちを冷酷にも切り捨てていたように思えるが、 実際にはそうではない。 Hixie もまた同じ幻想に取り憑かれ、 敗れ去った者の1人だった。

[177] 後に HTML5 と呼ばれることになる WF2 は form で PUT / DELETE が使えたし、なんならそれが HTML4 と違う目玉機能の1つと受け止められていた。言うまでもなく WF2 の著者は Hixie。そして当時 Hixie が勤務していた Opera がこれを実装した。

[178] >>173 は HTML フォームで PUT しても payload がフォームデータでは意味がない、使いようがないと書いているが、 WF2 はそれに1つの回答を与えていた。 PUT と <input type=file> の組み合わせでファイルアップロード用フォームを作れる、 というのが WF2 の構想だった。

[179] このすべてが Hixie の独創かというとそうでもなく、 form で PUT や DELETE を使いたいというのは90年代の HTML 標準化の現場でたびたび出てきていた要望だったし、 WF2 の機能の大部分は XForms の新機能を HTML にバックポートしたものだった。 WF2 完成くらいまでの初期の Hixie の仕事は HTTP の力を十分活かせていない HTML を拡充したいという意思があちこちに見え隠れしている。 当時の Hixie は後のいわゆる「REST 信者」とそう遠くない位置にいたとみていい。

[180] ところが WF2 の方向性は (当時 Webブラウザー開発を事実上凍結していた MS 以外の) Webブラウザー事業者各社に支持されたものの、 WF2 を完全実装したのは Opera だけだった。 そのため WF2 が HTML5 に統合されるとき、取捨選択が行われた。 それで payload をフォームデータでなくファイルにする機能など、 実装が見込めないものは HTML5 には移されなかった。 それでも当初 PUT や DELETE が HTML5 に追加されたのは、きっと Hixie もまだ幻想を断ち切れてなかったんだろう。

[181] しかし残った機能だと PUT も DELETE も使いようがないのは >>173 が説明する通り。使い道がないならWebブラウザーに実装される見込みもない。 だから Hixie もあっさり削除の提案を受け入れた。 >>173 が紹介するような REST 信者の騒ぎはすべてそれより後の出来事で、 しかも状況を覆す新しい情報をもたらすものでもなかったから、 仕様書は再度変更されることはなかったし、 Webブラウザー事業者も反応しなかった。

[182] 需要があってもっともだと判断されればWebブラウザー事業者が実装し、 後から Hixie がしぶしぶそれに追随する、というルートもあった。 このケースではそのルートも辿らなかったということ。 Opera (Presto) が既に実装しているので、 他に1つでもそれに追随するWebブラウザー事業者があればきっと Hixie もそれに従う、という低いハードルだったにも関わらず。

[183] なおフォームの提出の仕組みはもっと活用できるはず、というアイデア自体は Hixie も大事にしていて、 平成22年に PUT や DELETE を method<form method> から削除した翌年の平成23年には method<form method> に dialog を追加して dialog 要素と結びつける案を作っている。

[184] WF2 時代には action<form action> に javascript: URL を指定できることになっていて、それは実際に Netscape Navigator 時代からあった機能を拡充したものだったが、その後セキュリティー的にどうかということで、 今では全廃されている。 <form method=dialog> はある種そのうちの特定の利用形態だけを取り出した後継機能と見ることもできる。 どちらもフォームの提出機能の宛先を HTTP でなく JavaScript コードにできるというのが大きな特徴。 従来も onsubmit などでフォームデータにアクセスはできたが、 フォームの提出それ自体が JavaScript に行き着くものではなかった。 ここに Ajax 時代を経ての HTTP との decoupling という思想を見ることもあるいは可能かもしれない。

[185] Firefox はフォームの提出にまだ何かおかしな (現行仕様になる前に由来するのであろう、現在からみると不適切な) 挙動が残っているみたいです。 form 要素の submit イベントハンドラー (独自の処理を行い、フォームの提出は取り消す。) を呼び出したいと submit イベントを発火してみると、なぜかフォームの提出が行われます。 かわりに <button type=submit> の click を実行すれば普通のフォームの提出 → submit イベントハンドラーでそれを取り消し、となって意図通りの挙動になるのですが。