[1] フォームコントロールは、 フォームの構成要素のひとつです。利用者は、 フォームコントロールを通じてフォームと対話します。
[2] 仕様書:
name
属性で指定します。制御子名の適用範囲は当該フォームです。value
属性で指定します。[4] Web Forms 1.0 では、次の種類の制御子が定義されています。
input
要素型または input
要素型の要素で定義します。input
要素型の要素で定義します。input
要素型の要素で定義します。select
要素型の要素で定義します。input
と複数行の textarea
があります。input
要素型の要素で定義します。input
要素型の要素で定義します。object
要素型の要素で定義します。[5] 制御子に使う要素型は、通常 form
内でフォーム制御子を作成するために使いますが、
利用者界面を作成するためにフォーム外で使うこともできます。
但し、フォーム外の制御子は成功しません。 HTML 4 17.2.1
[6] 制御子要素 (input
, select
,
button
, textarea
, label
)
はフォーム外では GUI を補うために使うことができます。
HTML 4 18.2.3 (fieldset
は?)
[7] 多くの Webブラウザでは、フォーム制御子にその GUI 環境の標準の制御子を使用したり、非常によく似せていたりします。
[8] 古い Webブラウザはフォーム制御子の部分とその他の部分のレンダリングや操作性をうまく統一できていませんでした。 例えば WinIE 3 は文書の他の部分 (画面に収まっていない部分も含みます。) の読込みとレンダリングが済んでからフォーム制御子を Windows 標準のものを使って追加していました。 このため長い文書は読み終わるまでフォームに関する操作を利用者が行うことができませんでしたし、 みっともないことにフォーム制御子が画面表示に追加される直前に一瞬、 表示領域の左上隅 (座標原点に相当します。) にこれから配置される制御子が表示されたりもしました。
[9] Netscape Navigator 2 (Windows 95 版) はフォーム制御子に Windows 標準のものを使っていましたが、例えば文章入力制御子の文脈メニュー (鼠の補助ボタンのかちっにより出てくるメニュー) を表示している間に頁の遷移が行われると制御子は破棄されてそのメニューだけが取り残されてしまい、 何の操作もできなくなって Netscape Navigator 自体を終了するまで画面の最前面 (他のプログラムの窓よりも前) に居座り続けました。 (Netscape 側の制御子の処理に問題があったのか、 Windows 側で不具合があったのかはわかりませんが・・・。)
[10] WinIE 6 や Gecko (環境や版にもよります。) などの Webブラウザでは CSS による指定がフォーム制御子では反映されないことがあったりします。 この問題の背景にはその環境の標準のフォーム制御子を利用することによって生じる制限があると思われます。 元々フォーム制御子は利用者界面としての性質が強く、 著者がどこまで制御できるべきかという問題があります。 Webブラウザの実装に使われる GUI toolkit の類が提供している機能も様々です。 CSS 2 もフォーム制御子のレンダリングに関しては触れていません (CSS 3 は扱っています)。
[12] Why styling form controls with CSS is problematic | 456 Berea Street (Roger Johansson 著, 版) http://www.456bereastreet.com/archive/200705/why_styling_form_controls_with_css_is_problematic/ (名無しさん 2007-05-25 00:32:37 +00:00)
[13] Web Forms 2.0 ( 版) http://www.whatwg.org/specs/web-forms/current-work/#presentation
[14] [whatwg] Should a textarea outside of a document be immutable? ( 版) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-June/036396.html
[15] IRC logs: freenode / #whatwg / 20140130 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20140130
[17] Editorial: text field → text control (annevk著, ) https://github.com/whatwg/html/commit/f5cf21cbae5a6227221a0eba62688cfbc198256b
[18] CSS Form Styling Module Level 1 () https://drafts.csswg.org/css-forms/
[19] [shadow-styling] Named parts, styling built-in form controls, and shadow styling (was Re: Goals for Shadow DOM review) (Edward O'Connor著, ) https://lists.w3.org/Archives/Public/www-style/2014Feb/0621.html
[20] Require autofilling to not discriminate against shadow DOM (domenic著, ) https://github.com/whatwg/html/commit/74e44b43c58576d9310c663931937886256d7364
[22] [css-display] Make form controls and replaced elements behave like 'd… (fantasai著, ) https://github.com/w3c/csswg-drafts/commit/f4780dcab4c32d7f04da1c644bcba50dbe116867
[23] [css-display] Use HTML definition of “submittable element” since that… (fantasai著, ) https://github.com/w3c/csswg-drafts/commit/6ed5d98de476344d8b7b23566ab5693dc7d6b1e8
[27] Fix form inheritance behavior for autocapitalize (rlanday著, ) https://github.com/whatwg/html/commit/b7c21b1b56d77215d3d85ae14a072c090dbe6266
[28] 942341 - "top:0" for abspos content in a fieldset is no longer at the top of the <legend> (breaking e.g. the Mozillians "edit" page) () https://bugzilla.mozilla.org/show_bug.cgi?id=942341
[29] Do not inherit text-transform (et al.) on form controls (jugglinmike著, ) https://github.com/whatwg/html/commit/b9997b7488a3b35515c30bb1627d361053cf2c2f
[30] Do not inherit text-transform (et al.) on form controls by jugglinmike · Pull Request #4672 · whatwg/html () https://github.com/whatwg/html/pull/4672
[31] Inhibiting text-transform in form fields · Issue #1310 · whatwg/html () https://github.com/whatwg/html/issues/1310
[32] Rendering section applies CSS properties to form controls where behavior is (currently) undefined · Issue #4676 · whatwg/html () https://github.com/whatwg/html/issues/4676
form
label
datalist
option
optgroup
fieldset