読み取り専用のテキストをプレーンテキストとして表示するか、読み取り専用のテキストボックスに表示する必要がありますか？
読み取り専用の情報にはラベルを使用する必要がありますか、またはフィールドの外観を維持するために読み取り専用のテキストボックスを使用する必要がありますか？
何かがテキストボックスにある場合、それを編集する方法があることを意味しているのに対し、プレーンテキストは明示的に読み取り専用であるように思えます。
更新：私の質問は 入力フォームフィールドのロック、それは理にかなっていますか？ に似ていますが、私はその点で異なります誰も編集できないフィールドを参照しています。ユーザーの権限や役割に基づくものではありません。
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
編集できない場合は、テキストフィールドではなくプレーンテキストとして表示します。
編集できないテキストをテキストフィールドに入力すると、混乱が生じる可能性があります。ユーザーはなぜ（そして正当な理由で）値を編集できないのか疑問に思うかもしれません。
ユーザーができない入力を編集する場合は、ユーザーの混乱を避けるためにラベルを使用することをお勧めします。
ユーザーがcanで入力を編集する場合は、読み取り専用のテキストボックスを使用することをお勧めします。
この回答は、明確なコントロールタイプを持つデスクトップUIに対するものであり、編集可能なコントロールにあるかどうかにかかわらず、ほとんどのコンテンツをとにかく選択できるブラウザー内フォームではありません。
これはユーザーとしての個人的な好みです（UIを開発するときはこれを行います）。編集できない情報には、テキスト（灰色ではない）と背景が灰色のロックされたテキストボックスを常に使用します。 （特定のフィールドが編集できない場合でも、これを行います。）
その理由は、この方法では、ユーザーが他の場所に入力することなく、UIからそのような情報を選択してコピーできるためです。私は通常、テキストボックスから境界線を削除して目立たないようにしますが、ユーザーがテキストボックスをダブルクリック/右クリックすると、（すべて選択およびコピーを選択できます。 。
私は一部のフォームラベルにもこのアプローチを使用しています（ほとんどが長いラベル）。長いUIの指示をメールや他のドキュメントにコピーする必要がある場合があり、長い文章を正しく入力するよりもユーザーがコピーして貼り付ける方が簡単だからです。
フィールド実際に有用な情報を提供しないの場合、それは隠しフィールド（display: none;のように）である必要があります。場合によっては、この情報は（トランザクションのIDのように）サーバーに送信される形式である必要がありますが、ユーザーが何らかの決定を下すのに役立ちません。そのような場合、フィールドを実際に表示する理由はなく、非表示にする必要があります。
この提案は明らかに、がユーザーの決定に関連する情報に適用されません。この場合、データは、いかなる種類のプレーンテキストでもありません。テキストフィールドの。
私の好みは、内容を編集できないが、選択してクリップボードにコピーできるフィールドを示すために背景をシェーディングすることです。編集可能な色の背景の薄暗い前景テキストは、フィールドの内容の一部ではない「透かし」を提案します（たとえば、「MM/YY」をぼんやりと表示する日付フィールドは、フィールドにこれらの文字が含まれていないことを示します。むしろ、フィールドは「MM/YY」というメッセージをユーザーに伝えたいと考えていました）。一般に、ボックスではなくテキストではなく、データにラベルを使用することを期待します。
経験則は、コンテキスト内であれば次のとおりです。
- テキストはnever編集可能、ラベルを使用
- テキストは時々コンテキスト内の他の変数に基づいて編集可能です。読み取り専用のテキストボックスを使用します（もちろん、該当する場合は編集可能に切り替わります）
これにより、ユーザーの選択に基づく潜在的な違いがユーザーに浸透します。
私の提案は他のほとんどの答えの組み合わせでしょう。
- フィールドがユーザーにとって重要ではない場合（この場合はフィールドIDのように非常に重要です）、ユーザーに表示しないでください。
- ユーザーが入力（RSAキー、URLなど）をコピーする場合は、読み取り専用のテキストボックスを使用すると簡単にできます（理想的には、select-allにフォーカスを当てます）。
- ユーザーが理論的にフィールド値を編集できても、現在はできない（つまり、プロファイル設定でのみ編集可能）*および/または多くのテキストボックスを含むテーブルにある場合、読み取り専用のテキストボックスを使用することもできますユーザーが指定した入力を示したり、他の入力フィールド行と同じスタイルで行を保持したりするため。この例では、IDは明らかにoverの行のスタイルを壊し、一貫性が低くなります。
- それ以外の場合は、おそらくラベルを使用する必要があります。
*この場合は、ユーザーにこのことを通知する必要があります。たとえば、「メールアドレスを変更するには、プロファイル設定に移動してください」のようにします。
直接編集できないフィールドを「無効」状態としてスタイリングする利点がある特定の状況があります。このフィールドはフォーム送信の一部であり、ユーザーは情報が正しいことを確認する必要があります。
例えば：
- フォーム上のユーザー編集可能な値の他の組み合わせに基づいて値が入力されている場合
- ユーザーがコンテンツを確認または拒否するためにのみフィールドを表示している場合（たとえば、請求書をサインオフする場合）、通常、データが別のソースからのものであり、アプリケーションには、これらのフィールドが編集可能なフォームがない場合があります） 。
これの価値は、ユーザーが処理する必要のないコンテキスト情報（ID）とフォーム送信に含まれる情報（フォーム送信自体が厳密に単なるトランザクションIDであっても、フォーム送信の影響）を区別することです。これらの値の使用を承認することです）。
frameworkで制約されていて、これらが2つのオプションしかない場合
LeafとDoddyの回答はあなたのジレンマに対する最善の解決策。
ただし、制約がなく、本当に設計を使用してユーザーエクスペリエンスを最適化できる場合は、次の状態をお勧めします。
編集可能
入力を編集する場合、ある程度の深さを与えるために、入力はわずかに3Dである必要があり、ユーザーはそれらが編集可能であることを知っています。
編集不可
データが同じモデルに属していて、テキストボックス内にあるか、ラベルが一貫しておらず見栄えが良いかのように見えるような、独特のルックアンドフィールを持っている。
1つの解決策は、編集できないフィールドの色と対照的な背景色が異なり、これらが完全にフラットであることです。フラットはプリントアウトのようなもので、ストーリーの終わりです。ここでこれ以上行うことはありません。
カーソルのある状況のデスクトップの場合：
カーソルをハンドカーソルに設定することを忘れないでください。アクションは、ユーザーがこのフラットフィールドをクリックすると、クリップボード内のテキストのコピーを取得することです。また、既存のクリップボードデータが失われないように、クリップボードへのコピーアクションをユーザーに通知するtooltipがあることを確認してください。
ユーザーがこの情報の意味や編集できない理由を考える必要がないように、この情報をフォームから完全に分離する方が良いでしょう。別の場合は、フォームの記入に専念できます。
他の回答にも同意します。フィールドを編集できない場合は混乱を避けるためにラベルを使用する必要がありますが、ユーザーがそこからコピーできるように、読み取り専用のテキストボックスを使用すると非常に便利な場合があります。プログラムの実行に何を使用しているかによって異なりますが、通常はラベルをコピーできません。