とりわけ、次の条件のいずれかであれば、ユーザーエージェントはその要素を編集可能（下記参照）であるとして扱います。まず、HTML要素の contenteditable 属性が true 状態にセットされている場合です。次に、HTML要素の contenteditable 属性が inherit 状態にセットされており、かつ、contenteditable 属性が inherit 状態以外の状態にセットされている直近の祖先要素が true 状態にセットされている場合です。最後に、自身の要素とその祖先要素すべての contenteditable 属性が inherit 状態にセットされ、Document の designMode が有効になっている場合です。

そうでなければ、次の状況のいずれかになっています。まず、それぞれの HTML要素の contenteditable 属性は false 状態です。次に、その contenteditable 属性は inherit 状態にセットされ、inherit 状態以外の状態にセットされた直近の祖先の HTML要素の contenteditable 属性は false 状態です。最後に、すべての祖先要素の contenteditable 属性は inherit 状態にセットされ、Document の designMode は無効です。いずれの場合も、該当の要素を編集することはできません。

contentEditable IDL 属性は、該当のコンテンツ属性が true 状態にセットされていれば "true" を、該当のコンテンツ属性が false 状態にセットされていれば "false" を返し、いずれでもなければ "inherit" を返さなければいけません。値をセットする場合、その値が大文字と小文字を区別せずに文字列 "inherit" と一致すれば、そのコンテンツ属性は削除されなければいけません。大文字と小文字を区別せずに文字列 "true" と一致すれば、そのコンテンツ属性は "true" にセットされなければいけません。大文字と小文字を区別せずに文字列 "false" に一致すれば、そのコンテンツ属性は "false" にセットされなければいけません。そして、指定された値が、上記のいずれでもなければ、この属性のセッターは SYNTAX_ERR 例外を発出しなければいけません。

isContentEditable IDL 属性は、取得時においては、該当の要素が編集可能であれば true を返し、そうでなければ false を返します。

要素が編集可能で、その親要素がそうでない場合、または、要素が編集可能で、親要素がない場合は、その要素を編集ホストといいます。編集可能な要素をネストすることができます。通常は編集ホストはフォーカス可能になり、タブ・オーダーに加わることになります。編集ホストには編集不可のセクションを含めることができ、下記のように処理されます。編集ホストには、さらに編集ホストを含んだ編集不可セクションを含めることができます。

編集ホストがフォーカスされたら、その要素は編集位置を指し示すキャレット位置を持たなければいけません。その要素は選択範囲も持つことができます。

キャレットと選択範囲がどのように表示されるかは、完全にユーザーエージェントに依存します。

7.5.1 ユーザー編集アクション

ユーザーが編集ホストを操作する際に、ユーザーエージェントがユーザーに実行できるようにすべきいくつかのアクションがあります。正確にそれぞれのアクションがどのように引き起こされるかは、すべてのアクションで定義されているわけではありません。ただ、定義されていない場合は、実装者が参考にできるよう、推奨キー・バインドが提供されます。

キャレットの移動

ユーザーエージェントは、編集ホスト内でユーザーがキャレットをどこにでも移動できるようにしなければいけません。ネストされた編集可能要素においても同様です。これは、各種キー識別子を持つ keydown イベントのデフォルト・アクションとして、そして、mousedown イベントのデフォルト・アクションとして、引き起こされることになります。

選択範囲の変更

ユーザーエージェントは、ユーザーが編集ホスト内にある選択範囲を変更できるようにしなければいけません。ネストした編集可能要素においても同様です。ユーザーエージェントは、編集可能要素から編集不可要素の中にまたがるような選択範囲を選択できないようにすることができます（例：それぞれの編集不可の子孫をアトミックに選択できるようするが、その中ではテキストの選択を許可しない。）。これは、各種キー識別子を持つ keydown イベントのデフォルト・アクションとして、そして、mousedown イベントのデフォルト・アクションとして、引き起こされることになります。

テキストの挿入

このアクションは、textInput イベントのデフォルト・アクションとして引き起こされなければいけません。そして、他のコマンドによっても引き起こされることができます。ユーザーエージェントは、指定されたテキスト（textInput イベントの場合は、event オブジェクトの data 属性から得られます。）をキャレットの位置に挿入しなければいけません。

フレージング・コンテンツが許されていない場所にキャレットが置かれたら（例：空の ol 要素の中）、ユーザーエージェントはそのキャレットの位置にテキストを直接挿入してはいけません。そのような場合は、その挙動はユーザーエージェントに依存しますが、ユーザーエージェントは、テキスト挿入リクエストに対して、リクエスト前と比べて整合性がとれていない DOM を生成してはいけません。

ユーザーエージェントは、ユーザーが段落以外のコンテンツだけを含んだ要素に、新規の段落を挿入できるようにしなければいけません。

例えば、次のマークアップがあったとしましょう：

<section>
 <dl>
  <dt> Ben </dt>
  <dd> Goat </dd>
 </dl>
</section>

ユーザーエージェントは、ユーザーが dl 要素の前後に section 要素の子要素として p 要素を挿入できるようにしなければいけません。

ブロックの分割

ユーザーエージェントは、例えば、修飾キーを伴わない "Enter" キーが識別子となる keydown イベントのデフォルト・アクションとして、ユーザーにキャレットの位置での段落分割のリクエスト方法を提供しなければいけません。

正確な挙動はユーザーエージェントに依存しますが、ユーザーエージェントは、段落分割のリクエストに対して、リクエスト前と比べて整合性がとれていない DOM を生成してはいけません。

改行の挿入

ユーザーエージェントは、例えば、shift 修飾キーを伴う "Enter" キーが識別子となる keydown イベントのデフォルト・アクションとして、ユーザーが段落を分割せずにキャレット位置に明示的な改行を入れられる方法を提供すべきです。行区切りは、通常は、詩の節や住所などに見られます。改行を挿入するために、ユーザーエージェントは br 要素を挿入しなければいけません。

フレージング・コンテンツが許されていない場所にキャレットが置かれたら（例：空の ol 要素の中）、ユーザーエージェントはそのキャレット位置に br 要素を直接挿入してはいけません。そのような場合は、その挙動はユーザーエージェントに依存しますが、ユーザーエージェントは、改行挿入リクエストに対して、リクエスト前と比べて整合性がとれていない DOM を生成してはいけません。

削除

ユーザーエージェントは、例えば、"U+0008" や "U+007F" が識別子となる keydown イベントのデフォルト・アクションとして、編集不可の子孫要素も含めて、テキストと要素を削除する方法をユーザーに提供すべきです。

特に次の 5 つの場合においては、この機能の実装で熟考が求められます。要素の開始地点でバックスペース、要素の直後にキャレットがあるときのバックスペース、要素の最後でフォワード・デリート、要素の直前にキャレットがあるときのフォワード・デリート、そして、最初と最後の地点が共通の親ノードを持たないセレクションを削除する場合です。

いずれの場合においても、正確な挙動はユーザーエージェントに依存しますが、ユーザーエージェントは、テキストや要素の削除のリクエストに対して、リクエスト前と比べて整合性がとれていない DOM を生成してはいけません。

セマンティック要素を挿入したり、テキストをセマンティック要素に入れる

ユーザーエージェントは、HTML が表現可能なセマンティックを使って、ユーザーがテキストや段落をマークアップできることができるようにすべきです。

ユーザーエージェントは、後で手動でテキストを埋めることができるよう、空のセマンティック要素を挿入する方法をユーザーに提供すべきです。

ユーザーエージェントは、マークアップされたテキストからこれらのセマンティックと、すでに挿入された空のセマンティック要素を削除する方法を、ユーザーに提供すべきです。

ユーザーがイタリックでテキストをマークアップするリクエストをした場合は、ユーザーエージェントは、i 要素を使ってセマンティックを表すべきです。em 要素を使うのは、ユーザーが強調を意図していることがはっきりしているときだけに限るべきです。

ユーザーがボールドでテキストをマークアップするリクエストをした場合は、ユーザーエージェントは、b 要素を使ってセマンティックを表すべきです。strong 要素を使うのは、ユーザーが重要性を意図していることがはっきりしているときだけに限るべきです。

正確な挙動はユーザーエージェントに依存しますが、ユーザーエージェントは、テキストをセマンティクスで囲んだり、セマンティック要素を挿入したり削除するリクエストに対して、リクエスト前と比べて整合性がとれていない DOM を生成してはいけません。

編集ホストの中にネストされた編集不可の要素の選択と移動

ユーザーエージェントは、編集ホストの中のコンテンツの前後にあるイメージや編集不可の部分を移動する方法をユーザーに提供すべきです。これはドラッグ &ドロップのメカニズムを使うことができます。ユーザーエージェントは、編集ホストの中にネストされた編集不可の要素を移動するリクエストに対して、リクエスト前と比べて整合性がとれていない DOM を生成してはいけません。

編集ホストの中にネストされたフォーム・コントロールの編集

編集可能なフォーム・コントロールが編集されたとき、その変更は、その時点の値とデフォルト値の両方に反映されなければいけません。これは、input 要素であれば、value IDL 属性だけでなく defaultValue IDL 属性もアップデートされることを意味します。select 要素であれば、option 要素の selected IDL 属性だけでなく defaultSelected IDL 属性もアップデートされることを意味します。textarea 要素であれば、value IDL 属性だけでなく defaultValue IDL 属性もアップデートされることを意味します。（default* IDL 属性をアップデートすると、コンテンツ属性もアップデートされます。。）

ユーザーエージェントは、ユーザーのリクエストに対して複数のコマンドを実行することができます。例えば、ユーザーがテキストのブロックを選択し Enter を押したら、ユーザーエージェントは、その選択範囲のコンテンツを削除するリクエストに続いて、その位置で段落を分割するリクエストとして解釈するでしょう。

ユーザーエージェントは、アクションが引き起こされる都度、編集ホストの Document オブジェクトのアンドゥ処理履歴に、DOM 変更エントリーを追加することができます。

前述のすべてのアクションは、ユーザーもしくはプログラム（例： execCommand() コマンド）によって引き起こされますが、必要に応じて mutation イベントを発出しなければいけません。

ドキュメントは designMode を持ちますが、それは編集可能または編集不可のいずれかとなります。

Document オブジェクトの designMode IDL 属性は、"on" と "off" の2つの値を取ります。値がセットされたら、大文字と小文字は区別せずに、これらの2つの値と比較されなければいけません。セットされた値が "on" に一致すれば、designMode は有効にし、"off" に一致すれば、designMode は無効しなければいけません。いずれでもなければ無視しなければいけません。

designMode が有効なら、この IDL 属性は "on" を、無効なら "off" を返さなければいけません。

最後にセットされた状態は、ドキュメントが破棄されるか状態が変更されるまで維持されなければいけません。また、designMode の初期値は無効でなければいけません。