From 3da00508a768ce46c8757a07997fc1c8ddf26de4 Mon Sep 17 00:00:00 2001 From: Masahiro FUJIMOTO Date: Thu, 29 Apr 2021 22:41:47 +0900 Subject: Learn/Forms/HTML_forms_in_legacy_browsers を更新 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 2021/04/28 時点の英語版に更新 - 原語併記マクロを削除 --- .../forms/html_forms_in_legacy_browsers/index.html | 221 +++++++++++---------- 1 file changed, 113 insertions(+), 108 deletions(-) (limited to 'files/ja/learn') diff --git a/files/ja/learn/forms/html_forms_in_legacy_browsers/index.html b/files/ja/learn/forms/html_forms_in_legacy_browsers/index.html index edc9009df2..0deefd6cdd 100644 --- a/files/ja/learn/forms/html_forms_in_legacy_browsers/index.html +++ b/files/ja/learn/forms/html_forms_in_legacy_browsers/index.html @@ -1,5 +1,5 @@ --- -title: 古いブラウザでの HTML フォーム +title: 古いブラウザーでの HTML フォーム slug: Learn/Forms/HTML_forms_in_legacy_browsers tags: - Example @@ -10,54 +10,45 @@ tags: - Web translation_of: Learn/Forms/HTML_forms_in_legacy_browsers --- -
{{LearnSidebar}}{{PreviousMenuNext("Learn/HTML/Forms/Sending_forms_through_JavaScript", "Learn/HTML/Forms/Styling_HTML_forms", "Learn/HTML/Forms")}}
+

{{LearnSidebar}}

-

すべての Web 開発者は、Web が非常につらい場所であることをいち早く (時に痛いほど) 学びます。もっともいまいましいのは古いブラウザです。まあそれは受け入れて、我々が「古いブラウザ」と言うとき、みんなが古いバージョンの Internet Explorer を念頭に置いています...しかしそれだけではありません。ESR バージョンのような1年経過した Firefox もまた古いブラウザです。そしてモバイルの世界では？ ブラウザも OS もアップデートできないときは？そう、最新ではない標準的なブラウザを搭載している多くの古い Android 携帯電話または iPhone があります。これらも古いブラウザです。

+

ウェブ開発者は誰でも、ウェブが自分たちにとって非常に厳しい場所であることを、すぐに (時には痛みを伴って) 学びます。最悪の災いは古いブラウザーです。「古いブラウザー」というと、 Safari や古いバージョンの Internet Explorer を思い浮かべますが、それだけではありません。モバイルの世界では、古い Android スマホや iPhone のように、ブラウザーも OS もアップデートできない場合、アップデートされない純正ブラウザーも古いブラウザーです。

-

残念ながら、そのような困難に対処するのも仕事の一部です。幸い、古いブラウザによって起きる問題の 80% 程度を解決する助けになることがわかっている秘訣がいくつかあります。

+

この荒れた環境に対応するのも仕事のうちです。幸いなことに、知っておくと古いブラウザーによる問題のほとんどを解決することができる秘訣があります。また、 HTML5 の {{htmlelement('input')}} 型は、対応していなくても失敗はしません。 type=text で代替されます。

-

問題について学ぶ

+

問題について知る

-

実のところもっとも重要なことは、一般的なパターンを理解するためにそれらのブラウザに関するドキュメントを読むことです。例えば、多くの場合 CSS のサポート状況が HTML フォームにおける最大の問題です。あなたはスタートとして適切な場所にいます。使用したい要素 (または DOM インターフェイス) のサポート状況を確認しましょう。MDN では Web ページで使用できる多くの要素、プロパティあるいは API について、実装状況の一覧表を入手できます。しかし、驚くほど役に立つであろうリソースが他にもあります:

+

一般的なパターンを理解するには、ブラウザーのドキュメントを読むことが役立ちます。 MDN でこの記事を読んでいるのであれば、始めるのにふさわしい場所にいます。使用したい要素 (または DOM インタフェース) の対応状況を確認するだけです。 MDN には、ウェブページで使用できるほとんどの要素、プロパティ、API の互換性一覧表が用意されています。他にも驚くほど役に立つリソースがあります。

-

ブラウザベンダーのドキュメント

+

ブラウザベンダーのドキュメント

-

独自のドキュメント

+

物事をシンプルにする

- - -

物事をシンプルに

- -

HTML フォームは複雑なやりとりを伴うことから、一つの経験則があります: 可能な限りシンプルにしてください (日本語版)。フォームを "より立派に" あるいは "高機能に" したいケースはたくさんありますが、効率的なフォームの作成はデザインや技術の問題ではありません。それを忘れないように、UX For The Masses にあるフォームのユーザビリティに関する記事を読む時間をとってください。

+

HTML フォームでは複雑なやり取りが行われるため、シンプルに保つという経験則があり、「KISS の原則」とも呼ばれています。フォームを「よりかっこよく」あるいは「高機能に」したい場合はたくさんありますが、効率的なフォームの作成はデザインや技術の問題ではありません。むしろ、シンプルさ、直感性、そしてユーザーとの対話のしやすさが重要なのです。 forms usability on UX For The Masses のチュートリアルがこれをよく説明しています。

-

Graceful Degradation は Web 開発者の最高の味方

+

グレイスフルデグラデーションはウェブ開発者の最大の味方

-

Graceful Degradation と Progressive Enhancement は、一度に幅広いブラウザをサポートすることにより、すばらしいものを構築可能にする開発パターンです。新しいブラウザで何かを構築するときにそれが動作すると確信したい場合は、あれやこれやで古いブラウザにおいて Graceful Degradation を行っています。

+

グレイスフルデグラデーションとプログレッシブエンハンスメントは、様々なブラウザーに同時に対応することにより、優れたものを作ることができる開発パターンです。新しいブラウザーで何かを構築した場合、古いブラウザーでも同じ方法または別な方法で動作するのであれば、グレイスフルデグラデーションが実施できていることになります。

HTML フォームに関する例をいくつか見ていきましょう。

-

HTML input のタイプ

+

HTML の入力型

-

HTML5 でもたらされた新たな input のタイプは、退行手段がとてもわかりやすいことから、すばらしいものです。ブラウザが {{HTMLElement("input")}} 要素の {{htmlattrxref("type","input")}} 属性の値を知らない場合は、値が text であるかのようにフォールバックします。

+

HTML5 で追加された入力型は、劣化の仕方が高度に予測可能であるため、古いブラウザーでもすべて使用可能です。ブラウザーにとって未知の {{htmlattrxref("type","input")}} 属性の値が {{HTMLElement("input")}} 要素にあった場合、その値が text であったかのように代替されます。

-
<label for="myColor">
+
<label for="myColor">
   Pick a color
   <input type="color" id="myColor" name="color">
 </label>

@@ -65,114 +56,120 @@ translation_of: Learn/Forms/HTML_forms_in_legacy_browsers
 
-   
-   
+   
+   
-   
-   
+   
+   

  
   
Chrome 24Firefox 18対応済み未対応
   

  
  
   
Screen shot of the color input on Chrome for Mac OSXScreen shot of the color input on Firefox for Mac OSXScreen shot of the color input on Chrome for Mac OSXScreen shot of the color input on Firefox for Mac OSX
   

  
 

 
-
CSS 属性セレクタ

-
-
CSS の属性セレクタは HTML フォーム でとても有用ですが、一部の古いブラウザはサポートしていません。その場合、慣例では type と同等の class で二重化します:

-
-
<input type="number" class="number">

-
-
input[type=number] {
-  /* こちらは一部のブラウザで機能しません */
-}
-
-input.number {
-  /* こちらはどのブラウザでも動作するでしょう */
-}

-
-
以下の記述では役に立たず (冗長であるため)、一部のブラウザで機能しない可能性があります:

-
-
input[type=number],
-input.number {
-  /* セレクタのひとつが理解できない場合は規則全体が無視されるため、
-     これは一部のブラウザで動作しません */
-}

-
-
フォームボタン

+
フォームのボタン

 
-
HTML フォームでボタンを定義する方法は 2 つあります:

+
HTML フォームでボタンを定義する方法は 2 つあります。

 
 
 
-
{{HTMLElement("input")}} は、要素セレクタを使用して CSS を適用したい場合に若干難しいことになります:

+
{{HTMLElement("input")}}

+
+
{{HTMLElement("input")}} 要素は、要素セレクターを使用して CSS を適用したい場合に少し難しくなることがあります。

+
+
<input type="button" value="click me">

 
-
<input type="button" class="button" value="click me">

+
すべての input から境界線を削除する場合、ボタンについてのみ既定の外見に戻すことができるでしょうか？

 
-
input {
-  /* この規則は、input 要素で定義するボタンのデフォルトのレンダリングを無効にします */
+
input {
+  /* この規則は、input 要素で定義するボタンを含む、境界線を持つ入力型の
+  既定のレンダリングを無効にします */
   border: 1px solid #CCC;
 }
-
-input.button {
-  /* これはデフォルトのレンダリングを復元しません */
+input[type="button"] {
+  /* これでは既定のレンダリングを復元できません */
   border: none;
 }
-
-input.button {
-  /* こちらも同様です! 実際は、あらゆるブラウザでこれを行う標準的な方法はありません */
+input[type="button"] {
+  /* これでも復元できません。実際、どのブラウザーでもできる標準の方法はありませ */
   border: auto;
+  border: initial;
+}
+input[type="button"] {
+  /* 対応していれば、これが既定のレンダリングに戻す最も近い方法です。 */
+  border: revert;
 }

 
-
{{HTMLElement("button")}} 要素は、起こりうる 2 つの問題に悩まされます:

+
詳しくは、CSS のグローバル値である {{cssxref('revert')}} を参照してください。

+
+
{{HTMLElement("button")}}

+
+
{{HTMLElement("button")}} 要は 2 つの問題に悩まされていましたが、すでに解決しました。

 
 
    
- 
  • 古いバージョンの Internet Explorer に存在する不具合です。ユーザがボタンをクリックしたときに送信されるものは {{htmlattrxref("value","button")}} 属性の内容物ではなく、{{HTMLElement("button")}} 要素の開始タグと終了タグの間にある HTML コンテンツです。これはそのような値を送信する場合のみの問題であり、例えばユーザがクリックしたボタンに応じてデータを処理する場合です。
    • 
- 
  • 一部のとても古いブラウザは {{htmlattrxref("type","button")}} 属性のデフォルト値として submit を使用しないため、{{HTMLElement("button")}} 要素では常に {{htmlattrxref("type","button")}} 属性を設定することを推奨します。
    • 
+ 
  • 古いバージョンの Internet Explorer では、クリックされたときに、 {{HTMLElement("button")}} 要素の開始タグと終了タグの間にある HTML コンテンツが、 {{htmlattrxref("value","button")}} 属性の内容の代わりに送信されるというバグがありました。これは、ユーザーがどのボタンをクリックしたかによってデータ処理が決まる場合など、その値を送信する必要がある場合にのみ問題となっていました。
    • 
+ 
  • 一部のとても古いブラウザーは submit を {{htmlattrxref("type","button")}} 属性の既定値として使用していませんでした。すべての現在のブラウザーでは解決していますが、 {{htmlattrxref("type","button")}} 属性を常に {{HTMLElement("button")}} 要素に設定することを推奨します。
    • 
 

 
-
<!-- ボタンをクリックすると "A" ではなく "<em>Do A</em>" を送信する場合があります -->
+
<!-- ボタンをクリックすると "A" ではなく "<em>Do A</em>" を送信する場合があります -->
 <button type="submit" name="IWantTo" value="A">
   <em>Do A</em>
 </button>

 
 
プロジェクトの制約に基づいて、どちらの解決策を選択するかはあなた次第です。

 
-
CSS を手放そう

+
CSS を手放そう

+
+
HTML フォームの大きな問題の一つは、 CSS によるフォームウィジェットのスタイル付けです。フォームコントロールの外観は、ブラウザーや OS に依存します。例えば、 color 型の入力は、 Safari、Chrome、Firefox のそれぞれのブラウザーによって外見が異なりますが、カラーピッカーのウィジェットは、OSのネイティブカラーピッカーを開くため、端末上のどのブラウザーでも同じになります。

+
+
一般に、フォームコントロールの既定の外観は変更しない方が良いと考えられています。というのも、 1 つの CSS プロパティの値を変更すると、一部の入力型は変更されますが、他の入力型は変更されないからです。例えば、 input { font-size: 2rem; } と宣言した場合、 number、date、text には影響がありますが、 color や range には影響しません。プロパティを変更すると、予期せぬ形でウィジェットの外観に影響を与えることがあります。例えば、[value] { background-color: 例えば、 [value] { background-color: #ccc; } は、 value 属性を持つすべての {{HTMLElement("input")}} を対象としていますが、 {{HTMLElement("meter")}} の背景色や境界線の角の丸めを変更すると、ブラウザーによって異なる予期せぬ結果になる可能性があります。 {{cssxref('appearance', 'appearance: none;')}} と宣言してブラウザーのスタイルを削除することもできますが、一般的には目的を達成できません。すべてのスタイルが失われ、訪問者が慣れ親しんだ既定のルック＆フィールが削除されるからです。

+
+
まとめるとすると、フォームコントロールのウィジェットに CSS でスタイル付けすることで、予測できない副作用が発生することがあります。だからやめましょう。 フォームウィジェット向けプロパティ実装状況一覧の記事の複雑さからもわかるように、非常に難しいのです。テキスト要素に多少の調整 (サイズやフォントの色など) を行うことはまだ可能でも、必ず副作用が発生します。最良の方法は、 HTML フォームウィジェットにスタイルをまったく適用しないことです。しかし、周囲のアイテムになら、どれでも適用することはできます。また、どうしてもフォームウィジェットの既定のスタイルを変更しなければならない場合は、スタイルガイドを定義して、すべてのフォームコントロールの一貫性を確保し、ユーザーの使い勝手を損なわないようにしてください。また、 JavaScript でのウィジェットの再構築など、難しいテクニックを検討することもできます。しかし、その場合は、そのような愚かな要求をするクライアントに請求することをためらってはいけません。

 
-
HTML フォームと古いブラウザにおける最大の問題は CSS のサポートです。Property compatibility table for form widgets の記事の複雑さからおわかりいただけるとおり、これはとても難しい問題です。テキスト系の要素でいくらか調整が (サイズや文字色など) 可能であるとしても、それらには必ず副作用があります。残された最善の方法は、HTML フォームのウィジェットに一切スタイルを設定しないことです。ただし、それでも周囲のアイテムにはスタイルを設定してもかまいません。もしあなたがプロフェッショナルで、顧客が要求するようなことがあれば、JavaScript によるウィジェットの再構築といった難易度が高い技術について調査してみるとよいでしょう。しかしそのような場合でも、顧客の愚かさを変えることをためらってはいけません。

+
機能検出とポリフィル

 
-
機能検出とポリフィル

+
CSS や JavaScript は素晴らしい技術ですが、古いブラウザーで壊れないようにすることが重要です。ターゲットとしているブラウザーで完全に対応していない機能を使用する前には、機能検出を行う必要があります。

 
-
JavaScript は新しいブラウザにおいてすばらしい技術ですが、古いブラウザでは多くの問題を抱えています。

+
CSS の機能検出

 
-
控えめな JavaScript

+
置き換えられたフォームコントロールウィジェットをスタイル付けする前に、 {{cssxref('@supports')}} を使用してその機能にブラウザーが対応しているかどうかをチェックすることができます。

 
-
最大の問題のひとつは、API を利用できるかです。そのため、"{{原語併記("控えめな", "unobtrusive")}}" JavaScript によって取り組むことベストプラクティスであると考えられています。これは、2 つの要件によって定義される開発パターンです:

+
@supports (appearance: none) {
+ input[type="search"] {
+   appearance: none;
+   /* restyle the search input */
+ }

+
+
{{cssxref('appearance')}} プロパティは、要素をプラットフォームのネイティブのスタイルで表示したり、 none の値を指定することで、既定のプラットフォームのネイティブベースのスタイルを削除したりするために使用されます。

+
+
控えめな JavaScript

+
+
最大の問題のひとつは、API が利用できるかどうかです。そのため、「控えめな」 JavaScript によって取り組むことベストプラクティスであると考えられています。これは、2 つの要件によって定義される開発パターンです。

 
 
    
- 
  • 構造と振る舞いの厳密な分割。
    • 
- 
  • コードが動作しない場合でも、コンテンツや基本的な機能性には依然としてアクセス可能かつ利用可能でなければならない。
    • 
+ 
  • 構造と動作を厳密に分割する。
    • 
+ 
  • コードが動作しない場合でも、コンテンツや基本的な機能はアクセス可能かつ利用可能のままでなければならない。
    • 
 

 
-
The principles of unobtrusive JavaScript (原文は Peter-Paul Koch 氏によって Dev.Opera.com 向けに記述され、現在は Docs.WebPlatform.org に移動しました) で、これらのアイデアを明快に説明しています。

+
The principles of unobtrusive JavaScript (原文は Peter-Paul Koch 氏によって Dev.Opera.com 向けに記述され、現在は Docs.WebPlatform.org に移動しました) で、これらのアイデアを明快に説明しています。

 
-
Modernizr ライブラリ

+
Modernizr ライブラリー

 
-
欠けている API を提供することで、すばらしい "ポリフィル" が大きな助けになるケースが多数あります。ポリフィルは、古いブラウザにおける機能性の "穴を埋める" 小さな JavaScript コードです。ポリフィルは任意の機能のサポート状況を改善するために使用できますが、JavaScript 向けに使用するのは CSS や HTML 向けより低リスクです。JavaScript が動作しない可能性は多数あります(ネットワークの問題、スクリプトの競合 など)。しかし JavaScript については、控えめな JavaScript を念頭に置いて取り組む場合はポリフィルが欠けたとしても、重大な問題にはなりません。

+
欠けている API を提供することで、すばらしい "ポリフィル" が大きな助けになるケースが多数あります。ポリフィルは、古いブラウザにおける機能性の "穴を埋める" 小さな JavaScript コードです。ポリフィルは任意の機能のサポート状況を改善するために使用できますが、JavaScript 向けに使用するのは CSS や HTML 向けより低リスクです。JavaScript が動作しない可能性は多数あります(ネットワークの問題、スクリプトの競合 など)。しかし JavaScript については、控えめな JavaScript を念頭に置いて取り組む場合はポリフィルが欠けたとしても、重大な問題にはなりません。

 
-
欠けている API に対してポリフィルを適用する最善の方法は、Modernizr ライブラリおよびそこからスピンオフしたプロジェクトである YepNope を使用することです。Modernizr は、機能が利用できるかを確認して適宜対応を行えるようにするためのライブラリです。YepNope は、条件付きで読み込みを行うライブラリです。

+
欠けている API に対してポリフィルを適用する最善の方法は、Modernizr ライブラリー、およびそこからスピンオフしたプロジェクトである YepNope を使用することです。Modernizr は、機能が利用できるかを確認して適宜対応を行えるようにするためのライブラリーです。YepNope は、条件付きで読み込みを行うライブラリーです。

 
-
サンプルは以下のとおりです:

+
例を示します。

 
-
Modernizr.load({
-  // ブラウザが HTML5 の form validation API をサポートしているかを確認します
+
Modernizr.load({
+  // ブラウザーが HTML5 のフォーム検証 API に対応しているかを確認します
   test : Modernizr.formvalidation,
 
-  // ブラウザがサポートしない場合は、指定したポリフィルを読み込みます
+  // ブラウザーが対応していない場合は、以下のポリフィルを読み込みます
   nope : form-validation-API-polyfill.js,
 
   // どの場合でも、API に依存するコアアプリのファイルを読み込みます
@@ -184,36 +181,44 @@ input.button {
   }
 });

 
-
好都合なことに、Modernizr チームはすばらしいポリフィルのリストを管理しています。必要なポリフィルを選びましょう。

+
Modernizr チームはすばらしいポリフィルのリストを管理しています。必要なポリフィルを選びましょう。

 
 

-
注記: Modernizr は、控えめな JavaScript や Graceful Degradation のテクニックに取り組むことを支援するためのすばらしい機能を搭載しています。Modernizr のドキュメントをご覧ください。

+
注: Modernizr は、控えめな JavaScript や グレイスフルでグラデーションのテクニックに取り組むことを支援するためのすばらしい機能を搭載しています。Modernizr のドキュメントをご覧ください。

 

 
-
パフォーマンスに注意を払う

+
パフォーマンスに注意を払う

+
+
Modernizr のようなスクリプトはパフォーマンスを非常に意識していますが、200 キロバイトのポリフィルをロードすると、アプリケーションのパフォーマンスに影響を与えます。これは、古いブラウザーでは特に重要です。古いブラウザーの多くは JavaScript エンジンが非常に遅く、ポリフィルをすべて実行するとユーザーに負担がかかります。パフォーマンスはそれ自体が問題ですが、古いブラウザーはとても敏感です。基本的に古いブラウザーは遅く、ポリフィルが増えれば増えるほど、より多くの JavaScript を処理しなければなりません。つまり、新しいブラウザーに比べて二重に負担がかかるのです。古いブラウザーでコードをテストし、実際にどのように動作するかを確認してください。すべてのブラウザでまったく同じ機能を使うよりも、一部の機能を削除したほうがユーザーの使い勝手が向上することもあります。最後になりましたが、常にエンドユーザーのことを考えてください。

 
-
Modernizr のようなスクリプトはパフォーマンスを非常に意識していますが、200キロバイトのポリフィルをロードするとアプリケーションのパフォーマンスに影響を与えます。これは従来のブラウザでは特に重要です。多くは JavaScript エンジンが非常に遅く、すべての polyfill の実行はユーザにとって苦痛になります。パフォーマンスはそれ自体が課題ですが、従来のブラウザはそれに非常に敏感です。基本的にそれらは遅く、より多くのポリフィルが必要で、より多くの JavaScript を処理する必要があります。そのため現代のブラウザと比較して二重の負担をかけていることになります。従来のブラウザでコードをテストして、実際のパフォーマンスを確認しましょう。場合によっては、一部の機能を削除すると、すべてのブラウザでまったく同じ機能を使用するよりも優れたユーザーエクスペリエンスが得られます。最後に念のため、常にエンドユーザのことを考えるようにしてください。

+
おわりに

 
-
おわりに

+
このように、ブラウザーや OS における既定のフォームコントロールの外観を考慮することは重要です。これらの問題に対処するためのテクニックは数多くありますが、そのすべてをマスターすることは、この記事の範囲を超えています。大前提として、既定の実装を変更することに価値があるかどうかを検討してから挑戦してください。

 
-
お分かりのように、従来のブラウザを扱うことは単にフォームに関することだけではありません。テクニック一式です。 しかし、それらすべてをマスターすることは、この記事の範囲を超えています。

+
この HTML フォームガイドのすべての記事を読んでいれば、フォームの使用に慣れているはずです。新しいテクニックやヒントを見つけた場合は、ガイドの改善にご協力ください。

 
-
この HTML フォームガイドのすべての記事を読んでいれば、フォームの使用に慣れているはずです。新しいテクニックやヒントを見つけた場合は、ガイドの改善にご協力ください。

+
関連情報

 
-
{{PreviousMenuNext("Learn/HTML/Forms/Sending_forms_through_JavaScript", "Learn/HTML/Forms/Styling_HTML_forms", "Learn/HTML/Forms")}}

+
学習経路

+
+
 
-
このモジュール

+
高度なトピック

 
 
-- 
cgit v1.2.3-54-g00ecf