CSS 表モジュール レベル 3

W3C 作業草案,

この文書についての詳細
このバージョン:
https://www.w3.org/TR/2025/WD-css-tables-3-20251216/
最新公開バージョン:
https://www.w3.org/TR/css-tables-3/
エディターズドラフト:
https://drafts.csswg.org/css-tables-3/
以前のバージョン:
履歴:
https://www.w3.org/standards/history/css-tables-3/
フィードバック:
CSSWG 課題リポジトリ
仕様内インライン
編集者:
Keith Cirkel (Mozilla)
以前の編集者:
François Remy (招待専門家)
Greg Whitworth (Microsoft)
Bert Bos (W3C)
L. David Baron (Google)
Markus Mielke (Microsoft)
Saloni Mira Rai (Microsoft)
この仕様への編集提案:
GitHub エディター
テストスイート:
https://wpt.fyi/results/css/css-tables/
実装の準備はまだ整っていない

この仕様は、まだ実装の準備が整っていない。 アイデアを記録し、議論を促進するために、このリポジトリに存在する。

この仕様の実装を試みる前に、 www-style@w3.org で CSSWG に連絡してほしい。


概要

この CSS モジュールは、表形式データのレンダリングに最適化された、二次元グリッドベースのレイアウトシステムを定義する。 表レイアウトモデルでは、各表示ノードは、連続する行の集合 と連続する列の集合との交差部分に割り当てられる。これらの行と列は表構造から生成され、 その内容に従ってサイズ決定される。

CSS は、構造化文書 (HTML や XML など) を画面、紙などにレンダリングする方法を記述するための言語である。

この文書のステータス

この節は、この文書の公開時点におけるステータスを説明する。 現在の W3C 公開物の一覧 およびこの技術報告の最新改訂は、 W3C 標準および草案インデックスで見つけることができる。

この文書は、 CSS Working Group により、勧告 トラックを用いた Working Draft として公開された。 Working Draft としての公開は、 W3C およびその会員による承認を意味しない。

これは草案文書であり、 いつでも他の文書により更新、置換、 または廃止される可能性がある。 この文書を進行中の作業以外として引用することは不適切である。

フィードバックは、 GitHub で課題を提出することにより送信してほしい(推奨)。 その際、タイトルには次のように仕様コード “css-tables” を含めること: “[css-tables] …コメントの概要…”。 すべての課題とコメントはアーカイブされる。 あるいは、フィードバックは(アーカイブ済みの)公開メーリングリスト www-style@w3.org に送信できる。

この文書は、2025年8月18日付 W3C プロセス文書により管理される。

この文書は、W3C 特許ポリシーの下で運営されるグループにより作成された。 W3C は、そのグループの成果物に関連して行われた特許開示の公開一覧を維持している。 そのページには、特許を開示するための手順も含まれている。 ある個人が、その個人の考えでは 必須クレームを含む特許について実際の知識を有する場合、 W3C 特許 ポリシーの 6 節に従って情報を開示しなければならない。

1. 導入

この節は規範的ではない

多くの種類の情報(例: 過去 1 年間に収集された気象観測値)は、 行が一覧の 1 項目 (例: 日付、およびその日に測定されたさまざまな気象特性)を表し、 列が項目の特性の連続する値 (例: 過去 1 年間に測定された気温)を表す、2 軸グリッドで視覚的に表すのが最適である。

時には、表現をより理解しやすくするために、 グリッドの一部のセルが、実際のデータではなく、親の行/列の説明または要約を表すために使用される。 これは、 最初の行および/または列にあるセル(ヘッダーと呼ばれる)、 または最後の行および/または列にあるセル(フッターと呼ばれる)でより頻繁に起こる。

この種の表形式データ表現は、通常、表として知られている。 表レイアウトは、カレンダーやタイムラインのような他のグリッド状の表現をレンダリングするために乱用され得るが、 表現される情報がデータ表として意味をなさない場合、 著者は他のレイアウトモードを優先するべきである。

HTML における表のレンダリングは、長い間 HTML 仕様で定義されてきた。 しかし、CSS で定義される機能との相互作用は長い間未定義のままであった。 この仕様の目的は、 HTML 表と CSS の両方をサポートするユーザーエージェントに期待される挙動を定義することである。

この文書で定義される一部の挙動は、 解決しようとする問題に対して最も論理的または有用な解決方法ではない場合があることに注意してほしい。 しかし、そのような挙動は多くの場合、互換性要件の結果であり、 この仕様の編集者による意図的な選択ではない。 より複雑なレイアウトを使用したい著者には、 CSS Grid など、より現代的な CSS モジュールに依存することが推奨される。

テスト

次のテストは、この仕様で説明される機能の一般的な使用に関連する クラッシュテストであるが、 特定の規範的な記述には結び付けられていない。


表レイアウトに一般的に関連するテスト


1.1. 値の定義

この仕様は、[CSS2]CSS プロパティ 定義の慣例に従い、[CSS-VALUES-3]値定義構文を使用する。 この仕様で定義されない値型は CSS Values & Units [CSS-VALUES-3] で定義される。 他の CSS モジュールとの組み合わせにより、これらの値型の定義が拡張される可能性がある。

各プロパティの定義に列挙されているプロパティ固有の値に加えて、 この仕様で定義されるすべてのプロパティは、 プロパティ値として CSS 全域キーワードも受け入れる。 読みやすさのため、それらは明示的には繰り返されていない。

2. 内容モデル

2.1. 表構造

CSS 表モデルは HTML4 の表モデルに基づいており、 そこでは表の構造が表の視覚的レイアウトと密接に対応している。 このモデルでは、表は任意のキャプションと任意数のセル行から構成される。

さらに、隣接する行と列は構造的にグループ化でき、 このグループ化は表示に反映され得る(例: 行グループの周囲にボーダーを描くことができる)。

表モデルは「行優先」であると言われる。なぜなら、 著者は文書言語で列ではなく行を明示的に指定するからである。 列は、すべての行が指定された後に導出される。 すなわち、最初の行の最初のセルは最初の列 およびスパンに必要なだけの他の列に属する(必要ならそれらを作成する)。 そして、その行の後続のセルはそれぞれ次に利用可能な列 およびスパンに必要なだけの他の列に属する(必要ならそれらを作成する)。 後続の行のセルはそれぞれ、その行で次に利用可能な列(rowspan を考慮する)に属し、 スパンに必要なだけの他の列に属する(必要ならそれらを作成する)。 § 3.3 行/列グリッドの寸法決定を参照)

まとめると、表モデルのインスタンスは次から構成される:

[see-caption-below]
表の構造の 2 つの表現(木 vs レイアウト)

CSS モデルは、文書言語がこれらの各構成要素に対応する要素を含むことを要求しない。 定義済みの表要素を持たない文書言語(XML アプリケーションなど)については、 著者は文書言語の要素を表要素へ対応付けなければならない。 これは display プロパティで行われる。

次の display 値は、任意の要素に表整形規則を割り当てる:

table(HTML の <table> に相当)
要素が表を定義し、 フローレイアウトに置かれたとき ブロックレベルであることを指定する。
inline-table (HTML の <table> に相当)
要素が表を定義し、 フローレイアウトに置かれたとき インラインレベルであることを指定する。
table-row(HTML の <tr> に相当)
要素がセルの行であることを指定する。
table-row-group (HTML の <tbody> に相当)
要素がある量の行をグループ化することを指定する。

明示的に別段の記載がない限り、この仕様における table-row-groups への言及は、特殊化された table-header-groups および table-footer-groups も包含する。

table-header-group(HTML の <thead> に相当)
table-row-group と同様だが、レイアウト目的では、 そのような最初の行グループは常に他のすべての行および行グループより前に表示される。
表が複数の display: table-header-group ボックスを所有する場合、 最初のものだけがヘッダーとして扱われる。 その他は display: table-row-group であるかのように扱われる。
table-footer-group(HTML の <tfoot> に相当)
table-row-group と同様だが、レイアウト目的では、 そのような最初の行グループは常に他のすべての行および行グループの後に表示される。
表が複数の display: table-footer-group ボックスを所有する場合、 最初のものだけがフッターとして扱われる。 その他は display: table-row-group であるかのように扱われる。
table-column (HTML の <col> に相当)
要素がセルの列を記述することを指定する。
table-column-group(HTML の <colgroup> に相当)
要素が 1 個または複数の列をグループ化することを指定する。
table-cell(HTML の <td> または <th> に相当)
要素が表セルを表すことを指定する。
table-caption (HTML の <caption> に相当)
表のキャプションを指定する。 表キャプションは表のマージンとボーダーの間に配置される。
テスト

注記: 置換 要素で、display 値が table-row, table-row-group , table-header-group, table-footer-group, table-column, table-column-group, table-cell, および table-caption であるものは、インラインレベル ボックスとして扱われる。 これは CSS Display 3 § 2.4 Layout-Internal Display Types: the table-* and ruby-* keywords に従う。置換要素display 値が table または inline-table であるものは、その 外側 display 型に従って振る舞う。 これは CSS Display 3 § 2.1 Outer Display Roles for Flow Layout: the block, inline, and run-in keywords に従う。これは CSS 2.1 からの破壊的 変更だが、実装と一致している。

テスト

2.1.1. 用語

表構造 display 型に加えて、 この仕様では次の語句も使用される:

table wrapper box
table-caption が占有する空間を考慮するために、 table grid boxes の周囲に生成されるブロックコンテナボックス。
table grid box
キャプションを除く table-internal boxes を含むブロックレベルボックス。
table-root 要素
内側 display 型table である要素。
table-non-root ボックスまたは要素
proper table child、または table-cell ボックス。
table-track ボックスまたは 要素
table-row、または table-column ボックス。
table-track-group ボックスまたは要素
table-row-group、または table-column-group ボックス。
proper table child ボックスまたは要素
table-track-grouptable-track、または table-caption ボックス。
proper table-row parent ボックスまたは要素
table-root または table-row-group ボックス。
table-internal ボックスまたは要素
table-celltable-track、または table-track-group ボックス。
tabular container
table-row または proper table-row parent ボックス。
連続する ボックス
2 つの兄弟ボックスは、その間に介在する兄弟がない場合、 ただし空白だけを含む匿名インラインが任意で介在する場合を除き、連続している。 兄弟ボックスの列は、その列の各ボックスが、その前のボックスと連続している場合、 連続している。
テスト
table grid
table-root のすべての table-rows および table-cells の位置を記述するために必要な数の および を含む行列であり、 グリッド寸法決定アルゴリズムにより決定される。

グリッドの各行は table-row に対応し得るし、各列は table-column に対応し得る。

スロット of the table grid
スロット (r,c) は、 table grid 内の行 r と列 c の交差により 作成される利用可能な空間である。

table grid の各スロットは、少なくとも 1 つの table-cellその一部は 匿名)により覆われ、最大でも 2 つにより覆われる。 table-root の各 table-cell は少なくとも 1 つのスロットを覆う。

複数のスロットを覆う table-cells は、それを密に行う。 つまり、それらが覆うスロットの集合は常に、4 つの厳密に正の整数 (rowStart, colStart, rowSpan, colSpan) の集合として記述でき、 スロット (r,c) がその table-cell により覆われるのは、 rrowStart(含む)から rowStart+rowSpan(含まない)までの区間にあり、 かつ ccolStart(含む)から colStart+colSpan(含まない)までの区間にある場合、かつその場合に限られる。

そのような table-cell は、行 rowStart および列 colStart から 発生すると言われる。 また:

  • table-cell は、対応する行 (または列)から発生する場合、table-row (または table-column)を発生させると言われる
  • table-cell は、そのグループがそのセルの発生元の行 (または列)を含む場合、table-row-group (または table-column-group)を発生させると言われる

そのような table-cell は、上記の条件に一致するすべての行 r および列 cまたがると言われる。 また:

  • table-cell は、対応する行 (または列)にまたがる場合、table-row (または table-column)にまたがると言われる
  • (または列)に対応する table-row (または table-column)は、この行 (または列)にまたがると言われる
  • table-row (または table-column)は、グリッドのすべての列 (または行)にまたがると言われる
  • (または列)を含む table-row-group (または table-column)は、その行 (または列)にまたがると言われる
  • table-row-group (または table-column)は、グリッドのすべての列 (または行)にまたがると言われる

2.2. 補正

HTML 以外の文書言語は、CSS 2.1 表モデルのすべての要素を含まない場合がある。 そのような場合、表モデルが機能するために「欠落した」要素を仮定しなければならない。

任意の table-internal 要素は、必要であれば、自身の周囲に必要な 匿名表オブジェクトを自動的に生成する。 table-internal ではない table-root の任意の子孫は、 表内に少なくとも 3 つの入れ子オブジェクトからなる祖先集合を持たなければならない。 それらは table/inline-tabletable-row、および table-cell に対応する。 欠落したボックスは、次の規則に従って匿名ボックスの生成を引き起こす:

2.2.1. 補正アルゴリズム

これらの規則の目的では、フロー外 要素は幅と高さが 0 のインライン要素として表現される。 それらの包含ブロックはそれに応じて選択される。

次の手順は 3 段階で実行される:

  1. 無関係なボックスを除去する:
    次のボックスは display:none であるかのように破棄される:
    1. table-column の子。
    2. table-column-group の子であり、table-column ではないもの。
    3. 空白だけを含み、 かつそれぞれが table-non-root ボックスである 2 つの直接の兄弟の間にある 匿名インラインボックス。
    4. 次のすべての基準を満たす匿名インラインボックス:
      • 空白だけを含む
      • tabular container の最初および/または最後の子である
      • 直接の兄弟が存在する場合、その兄弟が table-non-root ボックスである
  2. 欠落した子ラッパーを生成する:
    1. proper table child ボックスではない、 table-root ボックスの連続する子の各列の周囲に、 匿名 table-row ボックスを 生成しなければならない。 !!Testcase
    2. table-row ボックスではない、 table-row-group ボックスの連続する子の各列の周囲に、 匿名 table-row ボックスを 生成しなければならない。 !Testcase
    3. table-cell ボックスではない、 table-row ボックスの連続する子の各列の周囲に、 匿名 table-cell ボックスを生成しなければならない。 !Testcase
  3. 欠落した親を生成する:
    1. 親が table-row ではない、連続する table-cell ボックスの各列の周囲に、 匿名 table-row ボックスを 生成しなければならない。 Testcase
    2. 親が誤っている、連続する proper table child ボックスの各列の周囲に、 匿名 table または inline-table ボックスを 生成しなければならない。 ボックスの親がインライン、run-in、または ruby ボックス(またはその子に対して インライン化を行う任意のボックス)である場合、 inline-table ボックスを生成しなければならない。 そうでなければ table ボックスでなければならない。 Testcase Testcase !Testcase
    3. table-root の周囲に、匿名 table-wrapper ボックスを生成しなければならない。 その display 型は、inline-table ボックスについては inline-block であり、table ボックスについては block である。 table wrapper box はブロック整形コンテキストを確立する。 inline-table のベースライン垂直整列を行うときには、 table-wrapper box ではなく table-root box が使用される。 table-wrapper box の幅は、その内部の table grid box のボーダー辺幅である。 table-wrapper box のサイズ上の width および height に依存するはずのパーセンテージは、 table-wrapper box 自身ではなく、代わりに table-wrapper box の包含ブロックに対して相対的である。
flexbox や grid のような一部のレイアウトモードは、 その子の display 型を上書きすることに注意。 これらの変換は表の補正より前に発生する。
float および position プロパティは、時として display算出値に影響することに注意。 これらのプロパティが table internal boxes であるべきものに使用されると、 代わりに block へ切り替わる。 この変換は表の補正より前に発生する。
この節のテキストは CSS 2.2 から、読みやすくするために修正している。 これらの変更に起因する誤りを見つけた場合は、課題を提出してほしい
テスト

2.2.2. 補正ボックスの特性

display 型を除き、補正目的で作成される匿名ボックスは、 この仕様で別段の記載がある場合を除いて、 特定のスタイルまたは既定のスタイルを受け取らない。

これは特に、 それらの算出背景が “transparent”、 算出 padding が “0px”、 算出 border-style が “none” であることを意味する。

また、匿名ボックスは、 ボックス木を通じてプロパティ値を継承することも思い出す価値がある。

2.2.3.

<div class="row">
  <div class="cell">George</div>
  <div class="cell">4287</div>
  <div class="cell">1998</div>
</div>

関連するスタイルは次のとおりである:

.row { display: table-row }
.cell { display: table-cell }

補正後、これは初期 HTML が次のようであったかのようにレイアウトボックスを生成する:

<table>
  <tr>
    <td>George</td>
    <td>4287</td>
    <td>1998</td>
  </tr>
</table>

この例では、3 つの table-cell 匿名ボックスが、行内のテキストを含むものと仮定される。display: table-row を持つ div 内のテキストは、視覚 整形モデルで説明されるように、匿名インラインボックスにカプセル化される:

<div class="inline-table">
  <div class="row">This is the top row.</div>
  <div class="row">This is the middle row.</div>
  <div class="row">This is the bottom row.</div>
</div>
.inline-table { display: inline-table; }
.row { display: table-row; }

これは初期 HTML が次のようであったかのようにレイアウトボックスを生成する:

<table>
  <tr>
    <td>This is the top row.</td>
  </tr>
  <tr>
    <td>This is the middle row.</td>
  </tr>
  <tr>
    <td>This is the bottom row.</td>
  </tr>
</table>

3. レイアウト

3.1. 中核レイアウト原則

他のブロックレベルボックスとは異なり、表は既定では包含ブロックを満たさない。 それらの widthauto に算出されると、代わりに fit-content が指定されたかのように振る舞う。 これは、代わりに stretch を持つかのように振る舞うほとんどのブロックレベルボックスとは異なる。

表の min-content 幅は、 すべての列の min-content 幅およびその 分配不能な空間を収めるために必要な幅である。

表の max-content 幅は、 すべての列の max-content 幅およびその 分配不能な空間を収めるために必要な幅である。

表に割り当てられた幅がその min-content 幅より大きい場合、 利用可能な幅の分配アルゴリズムは それに応じて列幅を調整する。

この節は、他の仕様で説明される幅計算に適用される汎用規則を上書きする。 特に、表のマージンが 0 に設定され、幅が auto に設定されている場合、 表は包含ブロックを満たすように自動的にサイズ決定されない。 ただし、表の width の使用値が見つかった後(下記のアルゴリズムを使用)、 それらの規則の他の部分は適用される。 したがって、たとえば左右の auto マージンを使用して表を中央揃えにできる。

3.2. 表レイアウトアルゴリズム

表をレイアウトするために、ユーザーエージェントは次の動作を適用しなければならない:

  1. 表が必要とする行/列の数を決定する。
    これは § 3.3 行/列グリッドの寸法決定で説明される手順を実行することで行われる。
  2. [A] 行/列グリッドに少なくとも 1 つの スロットがある場合:
    1. 各セル スロットが少なくとも 1 つのセルに占有されるようにする。
      これは § 3.4 欠落セルの補正で説明される手順を実行することで行われる。
    2. 各列の最小幅を計算する。
      これは § 3.8 表の尺度の計算で説明される手順を実行することで行われる。
    3. 表の幅を計算する。
      これは § 3.9.1 表幅の計算で説明される手順を実行することで行われる。
    4. 表の幅を列の間で分配する。
      これは § 3.9.3 分配アルゴリズムで説明される手順を実行することで行われる。
    5. 表の高さを計算する。
      これは § 3.10.1 表高さの計算で説明される手順を実行することで行われる。
    6. 表の高さを行の間で分配する。
      これは § 3.10.5 分配アルゴリズムで説明される手順を実行することで行われる。

    [B] そうでなければ、空の 表がレイアウトされる:

    1. 表の幅を計算する。
      これは CAPMIN と table grid box の算出幅 (ボーダーと padding を含む)のうち大きい方の値を返すことで行われる。 それが確定的である場合に限る(そうでなければ 0 を使用する)。
    2. 表の高さを計算する。
      これはすべての table-caption 高さ (それらの幅は表幅に設定され、 マージンは適切に考慮される) と、table grid box の算出高さ(ボーダーと padding を含む)との合計を返すことで行われる。 それが確定的である場合に限る(そうでなければ 0 を使用する)。
  3. 各 table-caption および table-cell にその位置とサイズを割り当てる。
    これは § 3.11 セル、キャプション、およびその他の内部表ボックスの位置決めの手順を実行することで行われる。

次の図式は、理解しやすくするために、 アルゴリズムを別の方法で説明している。

[see-caption-below]
表レイアウトアルゴリズムの概観。規範的ではない。
テスト

3.3. 行/列グリッドの寸法決定

表構造の節で述べたように、 表がいくつの行と列を持つかは、 表構造から決定できる。 行/列グリッドの寸法決定と、そのグリッド内で table-cells に スロットを割り当てることの両方には、 表のための HTML アルゴリズムを実行する必要がある。

3.3.1. HTML アルゴリズム

display 型に相当する HTML 表要素に由来しない CSS ボックスは、 このアルゴリズムを適用できるようにする前に、 下記のように HTML の相当物へ変換する必要がある。 この仕様のこのレベルでは、css のみでセルのスパンを 指定する方法はなく、 そのためには HTML td 要素の使用が必要である。

HTML5 表整形 アルゴリズムを適用する。 ここで、ボックスはその display 型に相当する HTML 要素のように振る舞い、 それが同じ型の HTML 要素である場合に限り、その発生元要素の属性を使用する (そうでなければ、属性を持たないかのように振る舞う)。

<ul class="table">
  <li><b>One</b><i>1</i></li>
  <li><b>Two</b><i>2</i></li>
  <li><b>Three</b><i>3</i></li>
</ul>
<style>
  ul.table { display: table; }
  ul.table > li { display: table-row; }
  ul.table > li > * { display: table-cell; }
</style>

これは次と同じ行/列グリッドを生成する

<table><tbody>
  <tr>
    <td></td>
    <td></td>
  </tr>
  <tr>
    <td></td>
    <td></td>
  </tr>
  <tr>
    <td></td>
    <td></td>
  </tr>
</tbody></table>
<!-- built using dom api, as this would be fixed by the html parser -->
<grid style="display: table">
  <row style="display: table-row">
    <th rowspan="2">1</th>
    <colgroup style="display: table-cell" span="2" colspan="2">2</colgroup>
  </row>
  <tr>
    <td>A</td>
    <td>B</td>
    <td>C</td>
  </tr>
</grid>

これは次と同じ行/列グリッドを生成する

<table>
  <tr>
    <th rowspan="2">1</th>
    <td>2</td>
  </tr>
  <tr>
    <td>A</td>
    <td>B</td>
    <td>C</td>
  </tr>
</table>

最初の行の 2 番目のセルには ```colspan=2``` が適用されないことに注意。 なぜなら、その発生元要素は HTML TD 要素ではないからである。

Testcase. !!Testcase. !Test case. !!Test case. !!Test case.

テスト

3.3.2. トラックのマージ

HTML 表整形アルゴリズムは、表を適切にレイアウトするために必要な数より多いトラックを 生成することがある。 それらのトラックは歴史的にユーザーエージェントによって無視されてきたため、 次の手順では、仕様の後の部分で例外として扱わなくて済むように、それらを完全に取り除くだけである。 この変更でも機能を維持するよう努めたが、この変更に起因する問題を見つけた場合は、 課題を提出してほしい。

得られたグリッドを、次のように連続するトラックをマージすることで反復的に変更する: 得られた行/列グリッドに適格トラックが存在し、 そのトラックを明示的に定義する table-column/table-row ボックスが存在せず、 かつ当該トラックとその直前のトラックの両方がまったく同じセル集合によりまたがられている限り、 それら 2 つのトラックは、表のレイアウト計算の目的で 1 つの単一トラックへマージされなければならない。 補償のため、削除されたトラックにまたがっていたセルのスパンを 1 減らし、 必要に応じてセルが発生するトラックも同様にずらす。 spanning-ghost-rows テストケースを参照)

auto モードの表では、 トラックマージアルゴリズムの目的で、すべてのトラックが適格 トラックである。 fixed モードの表では、 行のみがそのようにマージ可能である。つまり、すべての列は保持される。

最後に、table-root グリッドに正しい行数と列数(対応付けられた要素から得られる)を割り当て、 各 table-cell に正確な rowStart/colStart/rowSpan/colSpan(対応付けられた要素から得られる)を割り当てる。

テスト

3.4. 欠落セルの補正

次の節は、欠落セルが、そのグリッド内の位置を匿名 table-cell ボックスが占有しているかのように レンダリングされる、という CSS 2.1 の記述を明確化し拡張する (「欠落セル」とは、まだどの table-cell ボックスにも覆われていない行/列グリッド内のスロットである)。

表内の列数が分かると、任意の table-row ボックスは、 スパンを考慮した上で、表のすべての列を満たすのに十分なセルを所有するように 変更されなければならない。 この条件が満たされるまで、新しい table-cell 匿名ボックスをその行の内容へ追加しなければならない。

テスト

3.5. 表レイアウトモード

この節では、表のレイアウト方法を変更するフラグを扱う。 表レイアウトには 3 つの主要なフラグがある: table-layoutborder-collapse、および caption-sideborder-collapse フラグには、任意の border-spacing パラメーターがある。

3.5.1. Table-Layout プロパティ

名前: table-layout
値: auto | fixed
初期値: auto
適用対象: table grid boxes
継承: no
パーセンテージ: n/a
算出値: 指定されたキーワード
正規順序: 文法に従う
アニメーション型: 離散
テスト

table-root は、table-layout プロパティの算出値が fixed に等しく、 かつ表ルートの指定幅が <length-percentage>min-content、または fit-content のいずれかであるとき、 fixed モードでレイアウトされると言われる。 指定幅がそれらの値のいずれでもない場合、 または table-layout プロパティの算出値が auto である場合、 table-root は auto モードでレイアウトされると言われる。

table-root が fixed モードでレイアウトされるとき、 その table-cells の内容は幅計算の目的では無視され、 列サイズ決定の集約アルゴリズムは、最初の行トラックに属する table-cells のみを考慮する。 そのため、レイアウトは表の table-columns または最初の行のセルに明示的に指定された値にのみ依存する。 不定幅の列には、確定幅を持つ列を考慮した後に残った空間の公平な取り分が割り当てられる。 残りの空間がない場合は 0px である (§ 3.8.3 列尺度の計算を参照)。

3.5.2. Border-Collapse プロパティ

名前: border-collapse
値: separate | collapse
初期値: separate
適用対象: table grid boxes
継承: yes
パーセンテージ: n/a
算出値: 指定されたキーワード
正規順序: 文法に従う
アニメーション型: 離散

border-collapse プロパティの値が collapse である場合、 隣接するセルのボーダーは、各セルが共有ボーダーの半分だけを描画するように結合される。 その結果、この場合、border-spacing のような他のプロパティは適用されない (§ 3.6.2 collapsed-borders モードで適用されるオーバーライドを参照)、 (§ 3.7 ボーダーの折り畳みを参照)。

この場合、table-rootcollapsed-borders モードでレイアウトされると言われる。 そうでなければ、table-rootseparated-borders モードでレイアウトされると言われる。

テスト
3.5.2.1. Border-Spacing プロパティ
名前: border-spacing
値: <length>{1,2}
初期値: 0px 0px
適用対象: table grid boxes で、border-collapseseparate のとき
継承: yes
パーセンテージ: n/a
算出値: 2 つの絶対長さ
正規順序: 文法に従う
アニメーション型: 算出値による

長さは、separated-borders モードで、 隣接するセルボーダーを分離する距離を指定し、 厳密に負であってはならない。

1 つの長さが指定された場合、それは水平および垂直の間隔の両方を与える。 2 つが指定された場合、1 つ目は水平間隔を、2 つ目は垂直間隔を与える。

これが表レイアウトにどのように影響するかの詳細は、§ 3.8.1 分配不能な空間の計算を参照。

テスト

3.5.3. Caption-Side プロパティ

名前: caption-side
値: top | bottom
初期値: top
適用対象: table-caption boxes
継承: yes
パーセンテージ: n/a
算出値: 指定されたキーワード
正規順序: 文法に従う
アニメーション型: 離散
テスト

このプロパティは、表グリッドボックスに対するキャプションボックスの位置を指定する。 値は次の意味を持つ:

top
キャプションボックスを表グリッドボックスの上に配置する。
bottom
キャプションボックスを表グリッドボックスの下に配置する。
CSS2 は異なる幅および水平整列の挙動を説明していた。 その挙動は CSS3 で top-outside および bottom-outside の値を使用して導入される予定であった。 #REF
Gecko は "left" および "right" の値もサポートしているが、現在この 仕様は それらの値の実装を定義しようとしていない。
Gecko には複数キャプションの扱いにバグがある。 !Testcase

キャプション内容をキャプションボックス内で水平方向に整列するには、text-align プロパティを使用する。

この例では、caption-side プロパティがキャプションを表の下に配置する。 キャプションは表の親と同じ幅になり、キャプションテキストは左揃えになる。

caption {
  caption-side: bottom;
  width: auto;
  text-align: left
}

3.6. スタイルオーバーライド

一部の css プロパティは、css 表の内部で異なる挙動をする。 次の節では、その例外と効果を列挙する。

3.6.1. すべてのモードで適用されるオーバーライド

次の規則は、使用中のレイアウトモードに関わらず、すべての表に適用される。

3.6.2. collapsed-borders モードで適用されるオーバーライド

表が collapsed-borders モードでレイアウトされる場合、次の規則が適用される:

3.7. ボーダーの折り畳み

この節全体は、折り畳まれたボーダーのレンダリングをまともにするための提案である。 実装が非常に目に見えて分岐しているため、他の一部よりも多くの議論が必要になると予想される。 ブラウザーがこれを非常に異なる方法で処理しているため、再実装なしに収束は起こり得ない。 この提案の主要な懸念は、できるだけ多くの場合をサポートしつつ、 表の新しい実装に必要な労力をできるだけ低く保つことであった。

背景: CSS+HTML は表の接合部に対して前例のないボーダーモードの組み合わせを許可し、 すべての場合を適切にサポートすることを難しくしている。 実際、一部の組み合わせは適切に定式化された 問題ではなく、 したがって最適なレンダリングアルゴリズムは存在し得ない。

それらは単純なもの(HTML)から非常に複雑なもの(HTML+CSS)へと成長したため、 Web ブラウザーで使用される現在の表レンダリングモデル(背景とボーダー)は狂っている (バグがあり、相互運用性がなく、まったく CSS らしくないという意味で)。 通常の CSS の仮定の多くが破られ、レンダリングは大きく分岐している。

この提案はこの状況を修正することを目指している。

テスト

2.1 からの border-collapsing の破壊的 変更 [Issue #604]

3.7.1. 折り畳まれたボーダーの競合解決

テスト

collapsed-borders モードでレイアウトされるとき、ボーダーを共有する table-root および table-cell ボックスは、 同じスタイル、幅、および色を使用してレンダリングされるように(可能な場合)、 それらのボーダーを統一しようとする。 これは、次のアルゴリズムを実行することで達成される。

3.7.1.1. 折り畳まれた ボーダーの競合解決アルゴリズム
このアルゴリズムの目的では、ボーダー集合を「調和する」とは、 与えられたボーダー集合に「折り畳まれた ボーダーの調和アルゴリズム」を適用し、 それらのボーダーの使用値を、そのアルゴリズムの結果の値に設定することを意味する。 ただし、border-image-source が none と異なるセルについては例外であり、 それらは初期値を保持する。

table-root の任意の table-cell C° について:

次に、その table-root について:

実装はもちろん、前述のアルゴリズムの一部の手順について、 それらが最終結果に目に見える影響を与えないことを証明できるなら、省略してもよい。 特定のボーダーは前述の手順を使用して複数回調和されるが、 これを防ぐと仕様を読みづらくしてしまう。
このアルゴリズムが何をしているかを 読者がよりよく理解できるように、 サンプル表に前述のアルゴリズムを適用する主要な手順をここに概説する:

https://jsfiddle.net/bn3d1sm4/
https://jsfiddle.net/bn3d1sm4/1/
https://jsfiddle.net/bn3d1sm4/2/

https://jsfiddle.net/bn3d1sm4/15/
テスト
3.7.1.2. 折り畳まれた ボーダーの調和アルゴリズム
このアルゴリズムの目的では、ボーダーのプロパティを「考慮する」とは、 「そのプロパティが CurrentlyWinningBorderProperties より詳細である場合、 CurrentlyWinningBorderProperties をそのプロパティに設定する」ことを意味する。

折り畳まれたボーダーの 調和における詳細度を変更するか? [Issue #606]

ボーダースタイルの順序付き集合(セル C1, C2, … に位置する BC1, BC2, …)が与えられたとき、 それらの競合するボーダーについてボーダープロパティの使用値を決定するため、次のアルゴリズムを実行する。

3.7.1.3. ボーダースタイルの詳細度

2 つのボーダースタイルが与えられたとき、最も詳細度の高いボーダースタイルとは、次のボーダースタイルである…

  1. … 片方だけが border-style として "hidden" の値を持つ場合、それを持つもの
  2. … css ピクセルに変換された後で最大の border-width を持つもの
  3. … 次の一覧で最初に来る border-style を持つもの:
    double, solid, dashed, dotted, ridge, outset, groove, inset, none

これらの基準のいずれにも一致しない場合、両方のボーダーは同じ詳細度を共有する。

3.8. 表の尺度の計算

テスト

3.8.1. 分配不能な空間の計算

表の分配不能な 空間は、 連続する table-cells のボーダー間の距離 (および table-root のボーダーと table-cells の間の距離)の合計である。

2 つの連続する table-cells のボーダー間の距離は、存在するなら border-spacing である。

表ボーダーと 表の端にあるセルのボーダーとの距離は、 その側の表の padding に、 関連する border spacing 距離(存在する場合)を加えたものである。

たとえば、 右側では、距離は padding-right + 水平方向の border-spacing である。

3.8.2. セル尺度の計算

次の用語は、表または表セルのパラメーターである。 これらのパラメーターは、border-collapse の値 (separate または collapse)が異なる表の差異をカプセル化し、 この節の残りの小節がそれらを別々に参照する必要がないようにする。

セル固有 オフセット
セル固有オフセットは、固有幅計算に関連する表セルの padding と border の部分を捉えるための用語である。 これは、border-left-width、padding-left、padding-right、および border-right-width の算出値 (margin-left と margin-right についてはゼロ値)からなる集合であり、 次のように定義される:
  • separated-borders モード: table-cell の算出された 水平方向 padding および border
  • collapsed-borders モード: セルの算出された 水平方向 padding と、border 値については、 セルの使用 border-width 値(勝利した border-width の半分)
表固有 オフセット
表固有オフセットは、固有幅計算に関連する表の padding と border の部分を捉える。 これは、border-left-width、padding-left、padding-right、および border-right-width の算出値 (margin-left と margin-right についてはゼロ値)からなる集合であり、 次のように定義される:

マージンは表固有オフセットに含まれない。 なぜなら、マージンの扱いは caption-side プロパティに依存するからである。

border collapsing モードにおける固有オフセットの扱い [Issue #608]

水平方向 border spacing の合計
水平方向 border spacing の合計は、各表について定義される:
  • 少なくとも 1 つの列を含み、separated-borders モードでレイアウトされる表については、 border-spacing プロパティの算出値の水平方向成分に、表内の列数に 1 を加えたものを掛けた値
  • それ以外の場合は 0
オフセット調整済み min-width、width、および max-width
  • table-track および table-track-group ボックスについては、 幅プロパティのオフセット調整済み値は、要素に適用される box-sizing の値に関わらず、その算出値である。
  • table-cell ボックスについては、 幅プロパティのオフセット調整済み値はその算出値であり、 box-sizing の値に応じて、 セルの border-{left|right}-width および/または padding-{left|right} が最終的に差し引かれたものである。
    表が collapsed-borders モードでレイアウトされる場合、 差し引く border 値は各側で勝利した border 値の半分である (競合解決の説明 注記を参照)

Testcase. Testcase. Testcase.

外側 min-content および 外側 max-content
外側 min-content 幅および max-content 幅は、表セル、列、および列グループについて定義される。 これらの定義で使用される widthmin-width、および max-width の値は、 上で定義されたオフセット調整済み値である:
パーセンテージ 寄与
表セル、列、または列グループのパーセンテージ寄与は、 パーセンテージである算出値を持つ width および max-width の算出値に関して定義される:

min(percentage width, percentage max-width)

算出値がパーセンテージでない場合、 width には 0% が使用され、 max-width にはinfinite パーセンテージが使用される。
min-width はこの計算に含まれないことに注意。 その結果、パーセンテージの min-width は 無視される。 表レイアウトでは widthmin-width のように機能し、 列サイズ決定は長さベースとパーセントベースの両方にはなり得ないため、 著者は table-internal boxes で min-width を使用せず、 代わりに width のみに依存するべきである。
テスト

3.8.3. 列尺度の計算

この小節は、表の各列に関連付けられた 3 つの重要な値を定義する: そのmin-content 幅(この列に割り当てられる可能な最小幅)、 そのmax-content 幅(他の制約が適用されない場合に列に割り当てられる幅)、 その固有パーセンテージ幅(列が取得したい表幅のパーセンテージであり、 最終的にその max-content 幅を上書きする可能性がある)。

これらの値を計算するために、反復アルゴリズムが使用される。 まず、これらの値は複数列にまたがるセルを無視して計算される。 次に、徐々により多くの列にまたがるセルを考慮して、これらの値が更新される。 表のすべての列にまたがるセルが考慮されると、このアルゴリズムは終了し、値は確定される。

fixed モードでレイアウトされるときに列を測定する目的では、 (ヘッダーとフッターの並べ替え後に)表の最初の行で発生するセルのみが、 存在する場合に考慮される。 さらに、セルの min-content 幅および max-content 幅は、 length-percentage として直接指定されていない限りゼロとみなされ、 その場合は表幅に基づいて解決される(それが確定的であれば。そうでなければ 0 を使用する)。

セルの外側 min-content 幅を計算する目的では、 親セルの幅のパーセンテージに依存する幅を持つ表セルの子孫は、 auto 幅を持つものとみなされる。 Testcase Testcase

スパンが最大 1 のセルに基づく列の min-content 幅
次の最大値:
  • 列に指定された幅:
    • 対応する table-column の外側 min-content 幅(存在し、かつ auto でない場合)
    • 対応する table-column-group の外側 min-content 幅(存在する場合)
    • または、存在しない場合は 0
  • その列にまたがる各セルで、colSpan が 1 であるものの外側 min-content 幅 (またはfixed モードでは最初の行の 1 つだけ) または、存在しない場合は 0
スパンが最大 1 のセルに基づく列の max-content 幅
次の最大値:
スパンが最大 1 のセルに基づく列の固有パーセンテージ幅
その列にまたがる各セルで colSpan が 1 であるもの、 対応する table-column(存在する場合)、 および対応する table-column-group(存在する場合)のパーセンテージ寄与の最大値
スパンが最大 N (N > 1) のセルに基づく列の min-content 幅
スパンが最大 N-1 のセルに基づく列の min-content 幅と、 colSpan が N である、その列内のセルの寄与の最大値。 ここで、セルの寄与は次の手順を実行した結果である:
  1. 基準 min-content 幅を、 そのセルがまたがるすべての列について、 スパンが最大 N-1 のセルに基づく max-content 幅の合計として定義する。
  2. 基準 border spacing を、 セルがまたがる列のうち、セルが発生する列以外の任意の列についての水平方向 border-spacing の合計として定義する。
  3. セルの寄与は次の合計である:
    • スパンが最大 N-1 のセルに基づく列の min-content 幅
    • 次の積:
      • 次の比率:
        • 列の、スパンが最大 N-1 のセルに基づく max-content 幅 から、列のスパンが最大 N-1 のセルに基づく min-content 幅を引いたものと、
        • 基準 max-content 幅から基準 min-content 幅を引いたもの
        または、この比率が未定義の場合は 0、および
      • セルの外側 min-content 幅 から基準 min-content 幅および基準 border spacing を引いたもの。 これは少なくとも 0、かつ基準 max-content 幅と基準 min-content 幅との差以下にクランプされる
    • 次の積:
      • 列の、スパンが最大 N-1 のセルに基づく max-content 幅と、基準 max-content 幅との比率
      • セルの外側 min-content 幅 から基準 max-content 幅および基準 border spacing を引いたもの。 これが負の場合は 0
スパンが最大 N (N > 1) のセルに基づく列の max-content 幅
スパンが最大 N-1 のセルに基づく max-content 幅と、 colSpan が N である、その列内のセルの寄与の最大値。 ここで、セルの寄与は次の手順を実行した結果である:
  1. 基準 max-content 幅を、 そのセルがまたがるすべての列について、 スパンが最大 N-1 のセルに基づく max-content 幅の合計として定義する。
  2. 基準 border spacing を、 セルがまたがる任意の列についての水平方向 border-spacing の合計として定義する。 ただし、セルが発生する列は除く。
  3. セルの寄与は次の合計である:
    • スパンが最大 N-1 のセルに基づく列の max-content 幅
    • 次の積:
      • 列の、スパンが最大 N-1 のセルに基づく max-content 幅と、 基準 max-content 幅との比率
      • セルの外側 max-content 幅 から基準 max-content 幅および基準 border spacing を引いたもの。 これが負の場合は 0
スパンが最大 N (N > 1) のセルに基づく列の固有パーセンテージ幅
スパンが最大 N-1 のセルに基づく列の固有パーセンテージ幅が 0% より大きい場合、 スパンが最大 N のセルに基づく列の固有パーセンテージ幅は、 スパンが最大 N-1 のセルに基づく列の固有パーセンテージ幅と同じである。

そうでなければ、それは colSpan が N である列内のセルの 寄与の最大値であり、 ここで、セルの寄与は次の手順を実行した結果である:
  1. セルのパーセンテージ寄与から開始する。
  2. セルがまたがるすべての列について、スパンが最大 N-1 のセルに基づく列の固有パーセンテージ幅を引く。 これが負の結果を与える場合、0% に変更する。
  3. 次の比率を掛ける:
    • 列の非スパン max-content 幅と、
    • セルがまたがるすべての列のうち、 スパンが最大 N-1 のセルに基づく列の固有パーセンテージ幅が 0% に等しいものの 非スパン max-content 幅の合計。
    ただし、分母が 0 であるためこの比率が未定義の場合、 代わりに、セルがまたがる列のうち、 スパンが最大 N-1 のセルに基づく列の固有パーセンテージ幅が ゼロに等しいものの数で 1 を割ったものを使用する。
列の min-content 幅
スパンが最大 N のセルに基づく列の min-content 幅。ここで N は表内の列数である
列の max-content 幅
スパンが最大 N のセルに基づく列の max-content 幅。ここで N は表内の列数である
列の固有パーセンテージ幅
次のうち小さい方:
  • スパンが最大 N のセルに基づく列の固有パーセンテージ幅。 ここで N は表内の列数である
  • 100% から、表内の先行するすべての列の固有パーセンテージ幅の合計を引いたもの (direction が "ltr" のときはより左、"rtl" のときは右) Testcase

列の固有パーセンテージ幅の合計を最大 100% にクランプすることは、 表レイアウトアルゴリズムが列の入れ替えに対して不変ではないことを意味する。

制約性
列は、対応する table-column-group(存在する場合)、 対応する table-column(存在する場合)、 またはその列のみにまたがるセルのいずれかが、 "auto" ではなく、 かつパーセンテージでもない算出 width を持つ場合、 制約されている。
この仕様の将来の改訂では、このアルゴリズムはセルの文字揃え (<string> 値の text-align プロパティ)を考慮する必要がある。 これには(2011年3月9日の css3-text 編集者草案に基づき)、 揃え文字列の中心より前の列部分と、 揃え文字列の中心より後の列部分について、 max-content 幅を別々に追跡する必要がある。 min-content 幅の追跡については、2 つの選択肢がある: 追跡しないか、3 つの値を追跡するかである。 すなわち、改行点を持たないセルについて max-content 幅と同様の 2 つの値、 および改行点を持つセルについての 4 つ目の値である (したがって文字揃えが必須ではないもの)。
編集上の課題。 これが colspan するセルからの幅分配を説明する方法は誤っている。 min-content 幅および max-content 幅については、 固有幅計算のために余剰幅を列へ分配する規則を参照するべきである。
テスト

3.9. 利用可能な幅の分配

テスト

3.9.1. 表幅の計算

すべての列の最終幅を決定する前に、 表自体の幅を計算する必要がある。

前述のとおり、これは通常、すべての列の優先幅の合計に、 任意の追加分を加えたものになる。 この場合、幅の分配により各列にはその優先幅が与えられる。 ただし、著者が明示的に別の幅を求めるいくつかの場合、 および表が必要とする幅を与えられないいくつかの場合がある。

キャプション幅の最小値 (CAPMIN) は、 table captionsmin-content 寄与の最大値である。

行/列グリッド幅の最小値 (GRIDMIN) 幅は、 すべての列の min-content 幅の合計に、 セル間隔またはボーダーを加えたものである。

行/列グリッド幅の最大値 (GRIDMAX) 幅は、 すべての列の max-content 幅の合計に、 セル間隔またはボーダーを加えたものである。

表の使用 min-widthは、 解決済みの min-widthCAPMIN、および GRIDMIN のうち大きい方である。

表の使用幅は、 次のように列幅とキャプション幅に依存する:

テスト

割当可能な表幅は、 表の使用幅から、 水平方向 border spacing の合計(存在する場合)を引いたものである。 これは列に割り当てることができる幅である。

このアルゴリズムでは、行(および行グループ)と列(および列グループ)はどちらも、 それらが含むセルの寸法を制約し、 またそれによって制約される。 列の幅を設定すると、行の高さに間接的に影響する可能性があり、その逆も同様である。
テスト

3.9.2. 中核分配原則

この節は規範的ではない。

3.9.2.1. 規則

理想的には、各列はその優先幅(通常はその max-content 幅)を得るべきである。 しかし、前に計算された割当可能な表幅は、 この結果を達成するには大きすぎるか小さすぎる可能性があり、 その場合、ユーザーエージェントは幅分配アルゴリズムで説明されるように、 列にアドホックな幅を割り当てなければならない。

このアルゴリズムは、列の使用幅を決定する際に 3 つの規則に従う:

規則 0: fixed モードでは、 auto 列およびパーセンテージ列には最小幅 0 ピクセルが割り当てられ、 パーセンテージの解決は異なる規則群に従う。 その目的は、ピクセル列に常にその優先幅が割り当てられることを保証することである。

規則 1: 優先幅を割り当てるとき、 指定されたパーセント列は、 指定された単位値列より高い優先度を持ち、単位値列は auto 列より高い優先度を持つ。

規則 2: 同じサイズ指定型を使用する列(パーセント列、ピクセル列、または auto 列)は、同じ分配方法に従う。 たとえば、それらはすべて min-content 幅を得るか、すべて max-content 幅を得る。
この規則には 1 つの例外がある。 パーセント列にその優先パーセント幅を与えるとき、 それがその min-content 幅より小さいサイズになる場合、 その列には代わりに min-content 幅が割り当てられる。 ただし、パーセント列グループ全体としては依然として 優先パーセント幅が割り当てられているものとみなされる。

規則 3: すべての列に割り当てられる幅の合計は、割当可能な 表幅に等しくあるべきである。

テスト
3.9.2.2. 利用可能なサイズ指定

3 種類すべての列には、次の可能な使用幅がある。

  1. min-content 幅:
    列の内容を収めるために必要なサイズ
  2. min-content 幅 + delta:
    min-content 幅と優先幅の間の値
  3. 優先幅:
    列に指定されたサイズ、 または列の内容を折り返さずに収めるために必要なサイズ
  4. 優先幅 + delta
    優先幅より大きい値

分配アルゴリズムはこれらの値を定義し、それらをいつ使用するかを説明する。

3.9.3. 分配アルゴリズム

表が与えられた使用幅でレイアウトされるとき、 各列の使用幅は、必要に応じて このアルゴリズムへの変更fixed モードで適用した後、 次のように決定されなければならない。

まず、表の各列にはサイズ指定型が割り当てられる:

次に、有効なサイズ指定方法がサイズ指定型ごとに列へ割り当てられ、 次の sizing-guesses が得られる:

  1. min-content sizing-guess は、 各列にその min-content 幅が割り当てられる列幅割当ての集合である。
  2. min-content-percentage sizing-guess は、 次のような列幅割当ての集合である:
    • percent-column には、次のうち大きい方が割り当てられる:
      • その固有パーセンテージ幅に割当可能幅を掛けたもの、および
      • その min-content 幅。
    • その他すべての列には、その min-content 幅が割り当てられる。
  3. min-content-specified sizing-guess は、 次のような列幅割当ての集合である:
    • percent-column には、次のうち大きい方が割り当てられる:
      • その固有パーセンテージ幅に割当可能幅を掛けたもの、および
      • その min-content 幅
    • 制約されているその他の任意の列には、その max-content 幅が割り当てられる
    • その他すべての列には、その min-content 幅が割り当てられる。
  4. max-content sizing-guess は、次のような列幅割当ての集合である:
    • percent-column には、次のうち大きい方が割り当てられる:
      • その固有パーセンテージ幅に割当可能幅を掛けたもの、および
      • その min-content 幅
    • その他すべての列には、その max-content 幅が割り当てられる。
次に注意:

割当可能な 表幅max-content sizing-guess 以下である場合、 列の使用幅は、幅の合計が利用可能幅を挟む 2 つの連続する sizing-guesses の 線形結合(重みの合計が 1)でなければならない。

そうでなければ、列の使用幅は、max-content sizing-guess から開始し、 余剰幅を列へ分配する規則 (使用幅について)に従って、余剰幅を表の列へ分配した結果である。

次の図式は、理解しやすくするために、 アルゴリズムを別の方法で説明している。

凡例

サイズ指定アルゴリズム: 表の各描画は、列をサイズ指定する 1 つの方法を表す。 左側の 4 つの場合は、仕様で上に説明された sizing-guesses である: min-contentmin-content-percentagemin-content-specified、および max-content。 右側の場合は、4 つの sizing-guesses のいずれかと正確に一致しない利用可能サイズに必要な補間である。

サイズ指定方法の選択: サイズ指定方法の選択は常に min-content sizing-guess(左上)から開始し、 次に利用可能幅と現在使用中の方法により消費される幅を比較しながら進む。 緑の矢印は、現在の方法を適用した後に分配する余分な空間がある場合に 従うべき方向を示す。 赤の矢印は、現在の方法を適用して空間を分配しすぎており、 戻る必要がある場合に従うべき方向を示す。

列の型: 各列の型(auto、px、%)は図式内で独自の色(黄、 青、オレンジ)を持つ。 補間では、 前の sizing-guess でのサイズから縮小された列は赤で再描画され、 前の sizing-guess でのサイズから拡大された列は緑で再描画される。

[see-caption-below]
幅分配アルゴリズムの概観。規範的ではない。
3.9.3.1. fixed モードにおける幅分配の変更

前述のアルゴリズムへの次の変更は、fixed モードで適用される:

テスト
3.9.3.2. 余剰幅を列へ分配する

余剰幅を列へ分配する規則は、 2 つの方法で呼び出すことができる:

これら 2 つの場合の規則は大部分同じだが、わずかな違いがある。

この節の残りでは、分配されているこれらの幅の 1 つを指すために、 分配幅という用語を使用し、 余剰幅は、 分配されている幅が、それを分配先とする列の分配幅の合計を 超過する量を指すために使用される。

  1. 固有パーセンテージ幅が 0% であり、 かつ非ゼロの max-content 幅を持つ発生セルを有する 非制約列が存在する場合 (別名、この規則により成長が許される列)、 この規則により成長が許される列の分配 幅は、max-content 幅に比例して増加され、 増加の合計が余剰幅になるようにする。
  2. そうでなく、固有パーセンテージ幅が 0% である発生セルを有する 非制約列が存在する場合 (別名、この規則により成長が許される列であり、前の規則により max-content 幅がゼロでなければならないもの)、 この規則により成長が許される列の分配 幅は、等しい量ずつ増加され、 増加の合計が余剰幅になるようにする。
  3. そうでなく、固有パーセンテージ幅が 0% であり、 かつ非ゼロの max-content 幅を持つ 制約列が存在する場合 (別名、この規則により成長が許される列であり、他の規則により発生セルを持たなければならないもの)、 この規則により成長が許される列の分配 幅は、max-content 幅に比例して増加され、 増加の合計が余剰幅になるようにする。
  4. そうでなく、固有パーセンテージ幅が 0% より大きい列が存在する場合 (別名、この規則により成長が許される列であり、他の規則により発生セルを持たなければならないもの)、 この規則により成長が許される列の分配 幅は、固有パーセンテージ幅に比例して増加され、 増加の合計が余剰幅になるようにする。
  5. そうでなく、そのような列が存在する場合、 発生セルを持つすべての列の分配 幅は、等しい量ずつ増加され、 増加の合計が余剰幅になるようにする。
  6. そうでなければ、 すべての列の分配 幅は、等しい量ずつ増加され、 増加の合計が余剰幅になるようにする。
これらの規則は、表が fixed モードでレイアウトされる場合には適用されない。 この場合は、代わりに次のより単純な規則が適用される:
テスト

3.10. 利用可能な高さの分配

テスト

3.10.1. 表高さの計算

?Testcase ?Testcase ?Testcase

表の高さは、行の高さの合計に任意のセル間隔またはボーダーを加えたものである。 表が auto 以外の値を持つ height プロパティを持つ場合、それは表グリッドの最小高さとして扱われ、 それらの集合的な最小高さが最終的にこの数値より小さくなる場合、 行の高さへ分配される。 集合的なサイズが指定された height より大きくなる場合、指定された height は効果を持たない。

行の最小高さは次の最大値である:

ROWMIN は、 第 1 行レイアウトパス後の行の最小高さの合計として定義される。

表の高さを計算するには、したがって、 そのすべての行に対して第 1 パスレイアウトを実行し、 すべての最小行高さと間隔/ボーダーの合計を計算し、 その値と table-root に指定された height(min-height)のうち大きい方を返す必要がある。

表高さが決定されると、 行は通常第 2 レイアウトパスを受ける(そのセルの高さはもはや auto とみなされない)。 その後、高さ分配が行われ、行の高さが集合的に表高さを満たすように調整される。 その後、table-cell の子孫は第 2 レイアウトを受ける可能性がある (そのパーセンテージ高さが解決される)。

テスト

3.10.2. 行レイアウト(第 1 パス)

行の最小高さ(スパン関連の高さ分配を含まない)は、 その行から発生するセルを含む仮想 linebox の高さとして定義され、 複数行にまたがるセルは高さ 0px (ただし正しいベースラインを持つ)とみなされる。 この仮想 linebox では、セルの高さは auto とみなされ、 それらの幅(ボーダーと padding を含む)は、またがる列の幅および内側間隔に強制されるが、 その他のプロパティは保持される。

この高さを計算する目的では、 親セルの高さのパーセンテージに依存する高さを持つ表セルの子孫は (下の節を参照)overflowvisibleclip、または hidden に設定されている場合、または置換要素である場合、 auto 高さを持つものとみなされ、 そうでない場合は 0px 高さとみなされる。 Testcase !!Testcase

上記の結果としてパーセンテージ高さが無視された table-cell の子孫については、 高さ分配が完了すると、table-cell 内容の第 2 レイアウトパスが行われ、 このサイズ指定を適切に考慮しようとする (下の節を参照)

セルのベースラインは、 セル内の最初のフロー内 line box のベースライン、または セル内の最初のフロー内 table-row のうち、 どちらか先に現れるものとして定義される。 そのような line box または table-row が存在しない場合、 ベースラインはセルボックスの content edge の下端である。

テスト

これが実際にどのように機能するかを示す:

td { vertical-align: baseline; outline: 3px solid silver; }
img { float: left; clear: left; width: 32px; height: 32px; }
img[title] { float: none; }

<table><tr>
  <td>Baseline</td>
  <td>Baseline<table><tr><td>After</td></tr></table></td>
  <td><table><tr><td>Baseline</td></tr></table>After</td>
  <td><table align=right><tr><td>Before</td></tr></table><p>Baseline</p></td>
  <td><img src="http://w3.org/favicon.ico"><p>Baseline</p></td>
  <td><img src="http://w3.org/favicon.ico" title="Baseline"/><br/><img src="http://w3.org/favicon.ico" title="After"></td>
  <td><img src="http://w3.org/favicon.ico"><img src="http://w3.org/favicon.ico"><!--Baseline--></td>
</tr></table>
[see-caption-below]
適合ブラウザーにおけるこの例のレンダリング

ベースラインを見つける目的では、 スクロール機構を持つフロー内ボックス (overflow プロパティを参照)は、 その原点位置へスクロールされているかのようにみなされなければならない。

セルのベースラインは、その下ボーダーより下になることがある。 下の例を参照。

この例のセルは、その下ボーダーより下にベースラインを持つ:

div { height: 0; overflow: hidden; }

<table>
<tr>
<td>
<div> Test </div>
</td>
</tr>
</table>

各表セルの vertical-align プロパティは、 行内でのその整列を決定する。 各セルの内容にはベースライン、上端、中央、および下端があり、行自体も同様である。

表セルの文脈では、vertical-align の値は次の意味を持つ:

baseline セルのベースラインは、それがまたがる最初の行の他のセルのベースラインと揃えられる (セルおよびのベースラインの定義を参照)。
top セルボックスの上端は、それがまたがる最初の行の上端と揃えられる。
bottom セルボックスの下端は、それがまたがる最後の行の下端と揃えられる。
middle セルの中央は、それがまたがる行の中央と揃えられる。
... その他の値はセルには適用されない。代わりにセルはベースラインで揃えられる。

すべての 'vertical-align: baseline' を持つセルについて、 セルボックスの上端とベースラインとの最大距離が、 行のベースラインを設定するために使用される。 行に 'vertical-align: baseline' を持つセルがない場合、 その行のベースラインは行内で最も低いセルの bottom content edge である。

table-root のベースラインは、 存在する場合、その最初の行のベースラインである。 そうでなければ、table-root の bottom content edge である。

Testcase !!Testcase

曖昧な状況を避けるため、 セルの整列は次の順序で進む:

前述のアルゴリズムが行の各種整列線をどのように作成するかを示す例。

[see-caption-below]
表セルに対する vertical-align の各値の効果を示す図。 セルボックス 1 と 2 は、それらのベースラインで揃えられている。セルボックス 2 はベースラインより上の高さが最大であるため、 それが行のベースラインを決定する。

行レイアウト中には、その行内のセルに指定された高さは無視され、 複数の行にまたがるセルは正しくサイズ決定されていないため、 それらの高さは最終的に、それらがまたがる行集合へ分配される必要がある。 これは列測定と同じアルゴリズムを実行することで行われる。 span=1 値は、(min-content について)前の行レイアウトから得られた高さ、 対応する table-row に指定された高さ(存在する場合)、 およびこの行のみにまたがるセルに指定された最大高さのうち最大のもので初期化される (このアルゴリズムは、その割当ての上に span 2 のセルを考慮することから開始する)。

編集上の課題。§ 3.8.3 列尺度の計算の 関連する節をここに取り込む。

これらの手順を適用した結果としてサイズが増加する行は、 その下端を下げることで調整される。

任意の更新された行の下端に依存していたセルは、 それぞれの行内で再び正しく配置されなければならない。

この時点で、またがる行の集合的な高さより小さいセルボックスは、 追加の上側および/または下側 padding を受け取り、 その内容は垂直方向に移動しないが、 その上端/下端は、それがまたがる最初/最後の行のものと一致する。

行グループに定義された高さは、このアルゴリズムでは無視されることに注意
テスト

3.10.3. 行レイアウト(第 2 パス)

表高さが決定されると、必要であれば、第 2 行レイアウトパスが実行され、 行/セルに指定された height で使用されるパーセンテージを考慮して、 table rows に正しい最小高さを割り当てる。 それ以外については、第 1 パス行レイアウトのすべての命令が適用される(上を参照)

したがって、この第 2 パスの最小高さも、第 1 パスで勧告されたように table-cell の子孫のパーセンテージ高さを扱うことに注意 (上を参照)。 このため、新しい行の最小高さを計算するために table-cells の内容を再レイアウトする必要はない。 必要であれば、table-cell 内容は、 表高さ分配が完了した後で後ほど再レイアウトされる (下を参照)

次に、この第 2 パス後の table rows の新しい高さの合計が、 以前に決定された表高さを満たすために必要なものと異なる場合、 で定義される高さ分配アルゴリズムが適用される (行を、第 1 パスの最小高さと第 2 パスの最小高さとの間の中間サイズにして縮小するか、 または利用可能空間を満たすためにすべての行の高さを第 2 パスの最小高さを超えて増加させる。 いずれの場合も、これは行のベースラインには影響しない)。

3.10.4. 中核分配原則

編集上の課題。TODO。 現在の提案については、§ 3.10.5 分配アルゴリズムへ進む。
高さ分配に関する調査

3.10.5. 分配アルゴリズム

最初の手順は、各行にその基準サイズと参照サイズを割り当てることである。

その基準サイズは、表に指定高さがなかった場合に その行が得ていたサイズ (ROWMIN が評価されたときに割り当てられたもの)である。

その参照サイズは次の最大値である

第 2 の手順は、それらのサイズに基づいて各行の最終高さを計算することである。

表高さが参照サイズの合計以下である場合、 各行に割り当てられる最終高さは、 正しい合計高さを生じさせる、基準サイズと参照サイズの加重平均になる。

そうでなく、表がいずれかの “auto-height” 行 (サイズがその内容サイズのみにより決定され、指定高さを持たない行)を所有する場合、 各非 auto-height 行はその参照高さを受け取り、 auto-height 行は、その参照サイズに、 指定表高さに達するために不足する高さを そのような行の数で割った増分を加えたものを受け取る。

そうでなければ、すべての行はその参照サイズに、 指定表高さに達するために不足する高さを 行数で割った増分を加えたものを受け取る。

任意の更新された行の下端に依存していたセルは、 それぞれの行内で再び正しく配置されなければならない。

この時点で、またがる行の集合的な高さより小さいセルボックスは、 追加の上側および/または下側 padding を受け取り、 その内容は垂直方向に移動しないが、 その上端/下端は、それがまたがる最初/最後の行のものと一致する。

テスト

3.10.6. 表セル内容レイアウト(第 2 パス)

table-height 分配が完了し、行高さの合計に spacing/border を加えたものが表高さに等しくなると、 第 1 パス行レイアウト規則(上を参照)により パーセンテージ高さが無視された、または 0px として扱われた子孫を含んでいた table-cells の内容は、 下で定義されるように第 2 レイアウトパスを受けなければならない。

これは、UA が table-cell の任意の直接の子のプロパティにおける パーセンテージの使用を追跡することを要求されることを意味する。 これには、水平フローについては height および min-height プロパティ、 垂直フローについては width および min-width プロパティが含まれるが、それらに限定されない。 そうでなければ、すべての場合に table-cell 内容に対してこの第 2 レイアウトパスを実行することを要求される。

table-cell 内容内のパーセンテージ高さを解決する: 表および行の最終サイズが決定され、 高さ分配が完了した後、 table-cells の内容も第 2 レイアウトパスを通過しなければならない。 そこでは、適切な場合、パーセンテージベースの高さは 今回は親セルの使用高さに対して解決される。

table-cell の直接の子に対して パーセンテージ高さを解決することが適切であるのは、セルがその高さを 明示的に指定されているとみなされる場合、 または子が絶対位置指定されている場合である。CSS 2を参照。

互換性上の理由から、さらに次のことを明確化する。 セルの算出高さが長さである場合、 またはその table-root 祖先の算出高さが長さまたはパーセンテージである場合、 そのパーセンテージが auto として振る舞うかどうかに関わらず、 セルはその高さが明示的に指定されているとみなされる。

前述の記述を明確にするため、 使用される値に基づく結果の "A" div 高さの表を示す:
<section style="height: var(--wrapper-height)">
  <table style="height: var(--table-height)">
    <tr>
      <td style="height: var(--table-cell-height)">

        <div style="height:100%; background:yellow">A</div>

      </td>
      <td style="height: var(--other-table-cell-height)">

        B<br>C

      </td>
    </tr>
  </table>
</section>
--table-cell-height --table-height 結果
<length> <any> 100%
<any> <length> 100%
<any> <percentage> 100%
auto auto auto
<percentage> auto auto

--other-table-cell-height--wrapper-height も アルゴリズムの結果に影響しないことに注意。

この仕様の以前のバージョンでは、表がパーセンテージ高さを持つ場合に --wrapper-height が考慮されると誤って述べていたが、 実装が導入されたときに互換性問題が現れ、その挙動は特別扱いされるようになった。

この第 2 レイアウトパス(高さパーセンテージが解決されるもの)により、 一部のセル内容がその親セルからはみ出す可能性がある。 たとえば、使用されたすべてのパーセンテージの合計が 100% を上回る場合である。 これは意図された設計である。
テスト

3.11. セル、キャプション、およびその他の内部表ボックスの位置決め

テスト

visibility:collapse が何をするかについて、 解決が必要である。 [Issue #478]

表グリッドの各列の幅と各行の高さが決定されたら、 アルゴリズムの最後の手順は、各 table-internal ボックスに最終位置を割り当てることである。

下で計算される width/height/left/top は CSS レイアウトボックスの寸法を定義する。 つまり、CSSOM-VIEW で定義される offset* プロパティからアクセスできる (現在は、対応する HTMLElement 参照を取得できる css ボックスに限定される)。

table-wrapper ボックスは、 その後、 すべての table-non-root ボックスの margin box と、 table-root の border-box を含むようにサイズ決定される。

ここで定義される位置は、table-wrapper のために予約された空間内における子の位置であり、 そこから除外されるのはその margin のみである。 これは、表のキャプションが table-root の border-box 領域の外側に配置されるためである。

表内における、caption-side が "top" である 任意の table-caption の位置は、次を持つ矩形として定義される:

表内における任意の table-cell、table-track、または table-track-group ボックスの位置は、 次を持つ矩形として定義される:

注意: table-track および table-track-group ボックスについては、 グループ化方向と反対方向のすべてのトラックは、またがられているものとみなされる。 たとえば、table-header-group はすべての列にまたがるものとみなされ、 table-column-group はすべての行にまたがるものとみなされる。
上記の式は border-spacing を考慮しており、 それらの効果が何を意味するかは直接明らかではないかもしれないため、 これらの式の性質をいくつか示す:

表内における、caption-side が "bottom" である 任意の table-caption の位置は、次を持つ矩形として定義される:

セルの overflow: 表が fixed モードでレイアウトされ、 第 2 レイアウトパス中に一部のセルの内容がセルより大きく成長した場合、 または可視セルがまたがる一部のトラックが可視ではないとみなされる場合、 一部のセルの内容は利用可能な空間を超え、 overflow を生じる可能性がある。 そのような overflow は、 セルが絶対位置指定された display:block ボックスであり、 その内容を inline-start block-start 角(通常は左上)に相対して所定の位置に保つための 適切な整列が行われている場合とまったく同じように振る舞うべきである。 !Testcase !Testcase Testcase
可視トラック: このアルゴリズムの目的では、列または行は、 対応する table-track も、その table-track-group 親(存在する場合)も visibilitycollapse に設定されていない場合に、 可視 トラックとみなされる。
上にキャプションを持つ表。キャプションの margin が表の margin の内側に完全に入っているが、それでも表の border-box の外側にある様子を示している。
上にキャプションを持つ表の図。
~Testcase !!Testcase !!Testcase !!Testcase Testcase

4. 絶対位置指定

4.1. table-root を包含ブロックとする場合

絶対位置指定された要素の包含 ブロックtable-wrapper ボックスにより生成される場合、 その包含ブロックは、表 margin が適用される領域に対応し、 表ボーダーが描画される領域と、任意の table-caption の margin 領域を含む。 offset プロパティ(top/right/bottom/left)は、 通常どおり、この包含ブロックの対応する辺から内側へのオフセットを示す。

絶対位置指定は、とそのフロー内内容のレイアウト後に発生し、 いかなる表グリッドトラックのサイズ決定にも寄与せず、 表グリッドのサイズ/構成にいかなる形でも影響しない。

下の図は、表に相対して絶対位置指定されたボックスが どのようにレンダリングされるべきかを示している。

黄色の領域は 表の content edge、黄色の矢印は表の margin である。
の領域は表 キャプション、緑の矢印はキャプションの margin である。
の領域は表の背景領域であり、 より濃い青の領域は表のボーダー領域である。
の領域は 表に相対して位置指定された子孫であり、矢印は top/left/bottom/right の変位を表す。
[see-caption-above]
テスト

4.2. table-internal を包含ブロックとする場合

絶対位置指定された要素の包含 ブロックtable-internal により生成される場合、 その包含ブロックは、レイアウト中にそのボックスへ割り当てられるはずの領域の左上隅から始まる領域に対応するが、 そのサイズは、すべてのトラックが可視とみなされた場合の レイアウト中にそのボックスへ割り当てられるはずの領域のサイズとして計算される (一部のボックスで visibility が collapse に設定されているかどうかに関わらない)。 適切に、border と padding は含まれない。

これは、列を隠しても絶対位置指定されたボックスでレイアウトが発生せず、 クリップされる内容が動いているように見えないようにするために行われる。 !!Testcase !!Testcase

offset プロパティ(top/right/bottom/left)は、 通常どおり、この包含ブロックの対応する辺から内側へのオフセットを示す。

これは Firefox でしか機能しない。 ただし、将来 position:sticky を実装しやすくするだろう。 [Chrome bug] [Interop risk: Firefox bug] [Issue #858]

テスト

4.3. table-internal ボックスを非包含ブロック親とする場合

絶対位置指定されたボックスの非包含ブロック親が与える唯一の影響は、 top+bottom および/または left+right の両方が auto になる場合に、 その静的位置を定義することである。

table-cells については、絶対位置指定された内容は、通常どおりブロックレイアウトの規則に従って配置される。

表補正により、 table-cell ではない table-internal ボックスの子である絶対位置指定ボックスを 作成することはできない (詳細については float と position に関する注記を参照)。

5. レンダリング

テスト

5.1. セルの描画順序

表セルは、セルが実際に描画される場所に関係なく、 通常どおり DOM 順で table-root 内に描画される。

5.2. 空セルのレンダリング(separated-borders モード)

名前: empty-cells
値: show | hide
初期値: show
適用対象: table-cell boxes
継承: yes
パーセンテージ: n/a
算出値: 指定されたキーワード
正規順序: 文法に従う
アニメーション型: 離散
テスト

collapsed-borders モードでは、 このプロパティは効果を持たない。

separated-borders モードでは、 このプロパティが値 hide を持つとき、 空セルの周囲/背後には border も background も描画されない。

空セルとは、 次のいずれも含まない table-cell である:

empty-cells:hide を 単純化できるか? [Issue #605]

たとえば、次の markup と css を考える:

<table>
  <td><span></span></td>
  <td></td>
  <td><span></span></td>
</table>
table {
  width: 500px; height: 300px;
  empty-cells: hide;
}

table { background: black; border: 10px solid black; }
td { background: white; }

table { border-spacing: 0px; }
td { padding: 0; }

このコード片の正しいレンダリングはここに示される:

[see-caption-below]
empty-cells:hide により中央の 1 つが隠された 3 列のレンダリング

5.3. 背景とボーダーの描画

5.3.1. 表の背景とボーダーの描画

他のボックス型とは異なり、table および inline-table ボックスは、 その背景とボーダーを client rect 全体の周囲に描画しない。 実際、表キャプションは表の margin と border の間に視覚的に配置されるため、 table-root に適用される各種効果の描画領域は変更される必要がある。

描画領域:

これは、絶対位置指定のような、これらの概念の他の使用には影響しない。

!Testcase

テスト
5.3.1.1. collapsed-borders モードにおける変更

表がcollapsed-borders モードでレイアウトされるとき、 そのボーダーおよびその table-cells のボーダーのレンダリングは変更される。 次の規則は、その方法を説明する。

§ 5.3 背景とボーダーの描画で定義される背景とボーダーの描画規則は、 オーバーライドされない限り、引き続き適用される。

でない table-root のボーダーは、collapsed-borders モードでは描画されない。 ただし、border-image プロパティが設定されている場合を除く。

後者の場合、ボーダーは、表ボーダーがその使用値の指定より 2 倍大きいかのように描画され、 その超過分が table-root の padding 領域内に レンダリングされるかのように描画される。

それらが表により描画されない場合でも、表ボーダーはレイアウト内でその空間を占有し続ける。 セルはそれらの共有ボーダーをレンダリングする

テスト

5.3.2. セル背景の描画

欠落セルの補正手順により追加された匿名 table-cells は、 その背景を一切レンダリングしない。

自身の background に加えて、table-cell ボックスは、 それが属する table-track および table-track-group ボックスの背景もレンダリングする。 これは単にそれらの背景を継承することとは実際には異なる。 なぜなら、background-origin および background-size の計算は、 セルの bounds ではなく、グループ化ボックスの bounds 上で実際に行われるためである。

各表セルの背景を見つける目的では、 異なる表ボックスは、重ね合わされた 6 つの層上にあるものと考えることができる。 ある層に設定された背景は、 その上の層が透明な背景を持つ場合にのみ見える。

[see-caption-below]
表の層の図式。
  1. 表の背景は表によりレンダリングされ、 セル背景には影響しない。
  2. セルが最初に描画する背景は、その発生元 table-column-group(存在する場合)の背景である。 background-positioning の目的では、 column group は、row/column grid 内で単一セルが占有できる最大の領域を占有することが期待される。 ただし、その column group から発生し、column group の一部ではない列には入らないものとする。
  3. セルが 2 番目に描画する背景は、その発生元 table-column(存在する場合)の背景である。 background-positioning の目的では、 column は、row/column grid 内で単一セルが占有できる最大の領域を占有することが期待される。 ただし、その column から発生し、他の列には入らないものとする。
  4. セルが 3 番目に描画する背景は、その発生元 table-row-group(存在する場合)の背景である。 background-positioning の目的では、 row group は、row/column grid 内で単一セルが占有できる最大の領域を占有することが期待される。 ただし、その row group から発生し、row group の一部ではない行には入らないものとする。
  5. セルが 4 番目に描画する背景は、その発生元 table-row(存在する場合)の背景である。 background-positioning の目的では、 row は、row/column grid 内で単一セルが占有できる最大の領域を占有することが期待される。 ただし、その row から発生し、他の行には入らないものとする。
  6. セルが 5 番目に描画する背景は、そのセル自身の背景である。 これは、すべての背景がレンダリングされた後で最前面に現れるものである。

上の図が示すように、すべての行が同じ数のセルを含んでいても、 すべてのセルが指定された内容を持つとは限らない。 separated-borders モードでは、それらの empty-cells プロパティの値が hide の場合、 これらの空セルは まったくレンダリングされず、 visibility: hidden が指定されたかのように扱われ、 表背景が透けて見えるようにする。

テスト

5.3.3. セルボーダーの描画

separated-borders モードでは、表セルのボーダーは通常どおりレンダリングされる。

5.3.3.1. collapsed-borders モードにおける変更

table-cell のボーダーは、 collapsed-borders モードでは、セルボーダーがその使用値の指定より 2 倍大きいかのようにレンダリングされ、 その超過分がセルの margin 領域内にレンダリングされるかのようにレンダリングされる。 ただし、表の端の 1 つに位置していない border の各辺については、 その border は、実際の使用値が定義する border-box 描画領域へ実際にクリップされるという追加の制約を持つ。 ただし、border-image プロパティが設定されている場合を除く。

前述のクリップ挙動を適用した結果、border がデバイスピクセルの非整数量でクリップされる場合、 ブラウザーは、クリップ領域の x 値および y 値を切り上げることで、 代わりにクリップ領域をデバイスピクセルにスナップすることを決定してもよい。 値を切り上げることで、通常の writing mode では、 複数セル間で争われるピクセルを取得するセルが実際に最も左上のものになり、 この仕様に従えば、それは他のものより高い詳細度を持つ。 § 5.1 セルの描画順序および § 3.7.1.1 折り畳まれた ボーダーの競合解決アルゴリズムを参照。

テスト

5.3.4. ボーダースタイル(collapsed-borders モード)

border-style の値の一部は、collapsed-borders モードの表では、通常とは異なる意味を持つ。 それらの定義は、border-style 値の既定の挙動をオーバーライドする。

hidden

none と同じだが、他の任意のボーダーも抑制する(§ 3.7.1.3 ボーダースタイルの詳細度を参照)。

inset

ridge と同じ。

outset

groove と同じ。

5.4. visibility: collapse のレンダリング

表部分に visibility: collapse が設定されると、レンダリングは、 それが table-cell、スパンする table-cell、 または table-track/table-track-group のいずれにあるかに応じて、 異なる方法で処理される。

テスト

5.4.1. visibility: collapse の table cell のレンダリング

CSS 2.2 で述べられているように、table-cell の visibility が collapse に設定されている場合、それは visibility: hidden が設定されている場合と同じようにレンダリングされる。

これは、table-cell を含む table-row に visibility:collapse を設定したときに発生する。 行を隠しつつ、他の行にまたがるセルを表示し続けたい場合は、 それらのセルに visibility:visible を設定して、その値を継承しないようにする。

table-cell が複数の table-track にまたがっており、 それらの table-track の少なくとも 1 つが visibility: collapse に設定されている場合、 内容を table-cell の border-box にクリップする。 これは、セルの左上(rtl では右上)の内容が、 セルがまたがるどのトラックが collapse されたかに関わらず、表示され続けることを意味する。

5.4.2. visibility: collapse の table-track または table-track-group のレンダリング

table-track または table-track-groupvisibility: collapse が設定されている場合、 与えられた table-track または table-track-group 内のセルによって寄与されるすべての背景、ボーダー、またはアウトラインは、 完全に collapse されていないセル上で描画され続ける (それらが複数のトラックにまたがっていたため)。
テスト

6. 断片化

6.1. fragmentainer 間での分割

表を断片化するとき、ユーザーエージェントは、 行にまたがるセルが後続の行にまたがっておらず、かつ その高さが fragmentainer の高さおよび幅の両方の少なくとも半分未満である場合、 表の行を断片化せずに保持しようとしなければならない。 その他の行は自由に断片化可能であると言われる。

表全体が fragmentainer に収まらず、 少なくとも 1 つの行が fragmentainer に完全に収まり、 fragmentainer に収まらない最初の行が自由に断片化可能でない場合、 ユーザーエージェントは、overflow 点の前およびその位置にある行の間に いくらかの垂直方向の間隔を挿入し、 その 2 つの行が兄弟 fragmentainer 内で分離されるようにしなければならない。 断片化によりヘッダーとフッターの反復が必要で、フッターが反復される場合、 そのフッターは fragmentainer 内の最後の行の直後に来なければならず、 垂直方向の間隔は、反復されたフッターの後に挿入されなければならない。

[see-caption-below]
2 ページにわたって断片化された表の期待されるレンダリング

現在の fragmentainer に完全に収まる行がない場合、 または fragmentainer に収まらない最初の行が自由に断片化可能である場合、 ユーザーエージェントは、fragmentainer 内の残りの高さをすべてその行のセルに割り当て、 各セル内で可能な限り多くの内容を独立に収め、 次の断片へ分割し、各セルの内容を前の断片で停止した位置から開始しなければならない (継続断片では上ボーダーを再描画してはならない)。

[see-caption-below]
2 ページにわたって断片化された高い行を含む表の期待されるレンダリング

break-before または break-aftertable-row-group または table-row ボックスに適用される場合、 ユーザーエージェントは、分割点の前および後にある行の間に いくらかの垂直方向の間隔を挿入し、 プロパティ値により要求されるとおり、 その 2 つの行が兄弟 fragmentainer 内で分離されるようにしなければならない。 断片化によりヘッダーとフッターの反復が必要で、フッターが反復される場合、 そのフッターは fragmentainer 内の最後の行の直後に来なければならず、 垂直方向の間隔は、反復されたフッターの後に挿入されなければならない。

6.2. ページ間でのヘッダーの反復

文書をページ付きメディアへレンダリングする場合、 ページが表の fragmentainer であり、 header/footer に avoid の break-inside が適用されており、 そのために必要な高さがページ高さの 2 四分の 1 未満 (ヘッダー行については最大 1 四分の 1、 フッター行については最大 1 四分の 1)であり、 かつ、それによりそのページ上で行が 2 回表示されることがない場合、 ユーザーエージェントは、表がまたがる各ページ上で ヘッダー行および フッター行を反復しなければならない。

ヘッダー行が反復されるとき、ユーザーエージェントは 空間を残し、必要であれば表の上ボーダーをレンダリングしなければならない。 同じことがフッター行および表の下ボーダーにも適用される。

[see-caption-below]
ヘッダーとフッターを持つ表が 2 ページにわたって断片化された場合の期待されるレンダリング

ユーザーエージェントは、この挙動をより多くの断片化コンテキストへ拡張することを決定してもよい。 たとえば、ページに加えて列間でもヘッダー/行を反復するなどである。 静的文書をレンダリングするユーザーエージェントは、この挙動を採用する可能性が高いが、 これは仕様上要求されるものではない。

7. セキュリティに関する考慮事項

CSS Tables を使用しても、軽減すべきセキュリティリスクは生じない。

8. プライバシーに関する考慮事項

CSS Tables を使用しても、軽減すべきプライバシーリスクは生じない。

9. 追跡中のバグ一覧

この節は規範的ではない。

10. 付録

10.1. CSS 属性と HTML 属性の対応付け

HTML4 の既定スタイルシートは、そのモデルが css プロパティおよび値にどのように対応するかを示している:

現在の CSS 構成物に対応付けられない制約については、CSS へのいくつかの拡張が使用されている
table    { display: table }
thead    { display: table-header-group }
tbody    { display: table-row-group }
tfoot    { display: table-footer-group }
tr       { display: table-row }
td, th   { display: table-cell }
colgroup { display: table-column-group }
col      { display: table-column }
caption  { display: table-caption }
table, thead, tbody, tfoot, tr, td, th, colgroup, col, caption { box-sizing: border-box; }
thead, tfoot { break-inside: avoid }

table {
  box-sizing: border-box;
  border-spacing: 2px;
  border-collapse: separate;
  text-indent: initial;
}

thead, tbody, tfoot, table > tr { vertical-align: middle; }
tr, td, th { vertical-align: inherit; }

td, th { padding: 1px; }
th { font-weight: bold;  }

table, td, th { border-color: gray; }
thead, tbody, tfoot, tr { border-color: inherit; }



table[frame=box i], table[frame=border i], table[frame=hsides i], table[frame=above i], table[frame=below i], table[frame=vsides i], table[frame=lhs i], table[frame=rhs i] {
  border: 1px solid inset;
}


table:is([rules=all i], [rules=rows i], [rules=cols i], [rules=groups i], [rules=none i]) {
  border-collapse: collapse;
  border-style: hidden;
}

table:is([rules=all i], [rules=rows i], [rules=cols i], [rules=groups i], [rules=none i]),
table:is([rules=all i], [rules=rows i], [rules=cols i], [rules=groups i], [rules=none i]) > :is(thead,tbody,tfoot) > tr > :is(th,td) {
  border-color: black;
}

table[border=$border] /* if(parseInt($border) > 0) */ {
  border: /*(parseInt($border) * 1px)*/ outset rgb(128, 128, 128);
}
table[border=$border] > :is(thead,tbody,tfoot) > tr > :is(th,td) /* if(parseInt($border) > 0) */ {
  border: 1px inset rgb(128, 128, 128);
}

table[rules=all i] > :is(thead,tbody,tfoot) > tr > :is(th,td) {
  border: 1px solid grey;
}
table[rules=rows i] > :is(thead,tbody,tfoot) > tr > :is(th,td) {
  border: 1px solid grey;
  border-left: none;
  border-right: none;
}
table[rules=cols i] > :is(thead,tbody,tfoot) > tr > :is(th,td) {
  border: 1px solid grey;
  border-top: none;
  border-bottom: none;
}
table[rules=none i] > :is(thead,tbody,tfoot) > tr > :is(th,td) {
  border: none;
}

table[rules=groups i] > :is(thead,tbody,tfoot) {
  border-top-width: 1px; border-top-style: solid;
  border-bottom-width: 1px; border-bottom-style: solid;
}
table[rules=groups i] > colgroup {
  border-left-width: 1px; border-left-style: solid;
  border-right-width: 1px; border-right-style: solid;
}

table[frame=box i], table[frame=border i], table[frame=hsides i], table[frame=above i], table[frame=below i], table[frame=vsides i], table[frame=lhs i], table[frame=rhs i] {
  border-style: outset;
}
table[frame=below i], table[frame=vsides i], table[frame=lhs i], table[frame=rhs i] {
  border-top-style: hidden;
}
table[frame=above i], table[frame=vsides i], table[frame=lhs i], table[frame=rhs i] {
  border-bottom-style: hidden;
}
table[frame=hsides i], table[frame=above i], table[frame=below i], table[frame=rhs i] {
  border-left-style: hidden;
}
table[frame=hsides i], table[frame=above i], table[frame=below i], table[frame=rhs i] {
  border-right-style: hidden;
}

table[cellpadding=$x] > :is(thead,tbody,tfoot) > tr > :is(th,td) /* if(parseInt($x)>0) */ {
  padding: /*(parseInt($x) * 1px)*/;
}
table[cellspacing=$x] /* if(parseInt($x)>0) */ {
  border-spacing: /*(parseInt($x) * 1px)*/;
}


table[width=$w] /* if(parseInt($w) > 0) */ {
  width: /*(parseInt($w) * 1px)*/;
}
table[width=$w] /* if($w matches /(+|-|)([0-9]+([.][0-9]+|)|([.][0-9]+))[%]/) */ {
  width: /*(parseInt($w) * 1px)*/;
}
table[height=$h] /* if(parseInt($h) > 0) {
  height: /*(parseInt($h) * 1px)*/;
}
table[height=$h] /* if($h matches /(+|-|)([0-9]+([.][0-9]+|)|([.][0-9]+))[%]/) */ {
  height: /*(parseInt($h) * 1px)*/;
}


table[bordercolor=$color] {
  border-color: /*parseHTMLColor($color)*/;
}
table[bordercolor] > :is(tbody, thead, tfoot, tr, colgroup, col),
table[bordercolor] > :is(tbody, thead, tfoot) > tr,
table[bordercolor] > :is(tbody, thead, tfoot) > tr > :is(td, th),
table[bordercolor] > tr > :is(td, th)
table[bordercolor] > colgroup > col
) {
  border-color: inherit;
}
table[bgcolor=$color] {
  background-color: /*parseHTMLColor($color)*/;
}
table[align=left i] {
  float: left;
}
table[align=right i] {
  float: right;
}
table[align=center i] {
  margin-left: auto;
  margin-right: auto;
}

caption[align=bottom i] { caption-side: bottom; }
:is(thead,tbody,tfoot,tr,td,th)[valign=top i] {
  vertical-align: top;
}
:is(thead,tbody,tfoot,tr,td,th)[valign=middle i] {
  vertical-align: middle;
}
:is(thead,tbody,tfoot,tr,td,th)[valign=bottom i] {
  vertical-align: bottom;
}
:is(thead,tbody,tfoot,tr,td,th)[valign=baseline i] {
  vertical-align: baseline;
}

:is(thead,tbody,tfoot,tr,td,th)[align=absmiddle i] {
  text-align: center;
}

:is(colgroup,col,thead,tbody,tfoot,tr,td,th)[hidden] {
  visibility: collapse;
}

:is(td,th)[nowrap] { white-space: nowrap; }
:is(td,th)[nowrap][width=$w] /* if(quirksMode && parseInt($w) > 0) */ {
  white-space: normal;
}
テスト
ここにある内容の一部は、表の HTML から CSS への対応付けに関する WHATWG 仕様に由来する。 ただし、それらにはほとんどのブラウザーで真ではないものが含まれるため、 これは単純なコピーではない。 したがって、一方のソースから他方へ行われる任意のマージについて、それぞれ調査が必要である!

11. (欠落している節へのリンク)

12. 変更点

2019年7月27日付 Working Draft 以降の重要な変更:

適合性

文書の慣例

適合要件は、記述的な表明と RFC 2119 の用語を組み合わせて表現される。 この文書の規範部分におけるキーワード “MUST”、 “MUST NOT”、 “REQUIRED”、 “SHALL”、 “SHALL NOT”、 “SHOULD”、 “SHOULD NOT”、 “RECOMMENDED”、 “MAY”、および “OPTIONAL” は、 RFC 2119 で説明されるとおりに解釈される。 ただし、読みやすさのため、これらの語はこの仕様内で必ずしもすべて大文字で現れるわけではない。

この仕様のすべてのテキストは、明示的に非規範的と記された節、 例、および注記を除き、規範的である。 [RFC2119]

この仕様内の例は、“for example” という語で導入されるか、 次のように class="example" により規範的テキストから区別される:

これは参考情報としての例の一例である。

参考情報としての注記は “Note” という語で始まり、次のように class="note" により規範的テキストから区別される:

注記、これは参考情報としての注記である。

Advisements は、特別な注意を喚起するようにスタイル付けされた規範的な節であり、 次のように <strong class="advisement"> により他の規範的テキストから区別される: UA はアクセシブルな代替手段を提供しなければならない。

テスト

この仕様の内容に関係するテストは、 このような “Tests” ブロックに記録されることがある。 そのようなブロックはいずれも非規範的である。


適合クラス

この仕様への適合性は、3 つの適合クラスについて定義される:

style sheet
CSS スタイルシート
renderer
スタイルシートの意味論を解釈し、 それらを使用する文書をレンダリングする UA
authoring tool
スタイルシートを書く UA

スタイルシートは、このモジュールで定義される構文を使用するすべての文が、 汎用 CSS 文法およびこのモジュールで定義される各機能の個別文法に従って有効である場合、 この仕様に適合する。

renderer は、適切な仕様により定義されるとおりにスタイルシートを解釈することに加えて、 この仕様で定義されるすべての機能を正しく構文解析し、 それに従って文書をレンダリングすることにより、それらをサポートする場合、 この仕様に適合する。ただし、デバイスの制限により UA が文書を正しくレンダリングできないことは、その UA を非適合にはしない。 (たとえば、UA はモノクロモニター上で色をレンダリングすることを要求されない。)

authoring tool は、汎用 CSS 文法およびこのモジュールの各機能の個別文法に従って 構文的に正しいスタイルシートを書き、 このモジュールで説明されるスタイルシートのその他すべての適合要件を満たす場合、 この仕様に適合する。

部分的な実装

著者が前方互換な構文解析規則を利用してフォールバック値を割り当てられるようにするため、 CSS renderer は、利用可能なサポートレベルを持たない任意の at-rule、プロパティ、プロパティ値、キーワード、 およびその他の構文構成物を、無効として扱い(かつ適切に無視しなければならない。 特に、ユーザーエージェントは、単一の複数値プロパティ宣言内で、 サポートされていない成分値を選択的に無視し、サポートされている値を尊重してはならない。 いずれかの値が無効とみなされる場合(サポートされていない値はそうみなされなければならない)、 CSS はその宣言全体を無視することを要求する。

不安定な機能および 独自機能の実装

将来の安定した CSS 機能との衝突を避けるため、 CSSWG は CSS の不安定な機能および 独自拡張の実装について、 ベストプラクティスに従うことを推奨する。

非実験的実装

仕様が Candidate Recommendation 段階に到達すると、 非実験的実装が可能となり、実装者は仕様に従って正しく実装されていることを 実証できる任意の CR レベル機能について、接頭辞なしの実装をリリースするべきである。

実装間での CSS の相互運用性を確立し維持するため、 CSS Working Group は、非実験的な CSS renderer が任意の CSS 機能の接頭辞なし実装を リリースする前に、実装報告(必要であれば、その実装報告に使用したテストケース)を W3C へ提出することを要求する。 W3C へ提出されたテストケースは、CSS Working Group によるレビューおよび修正の対象となる。

テストケースおよび実装報告の提出に関するさらなる情報は、 CSS Working Group の Web サイト https://www.w3.org/Style/CSS/Test/ で見つけることができる。 質問は public-css-testsuite@w3.org メーリングリストへ送るべきである。

索引

この仕様で定義される用語

参照により定義される用語

参考文献

規範的参考文献

[COMPOSITING-1]
Chris Harrelson. Compositing and Blending Level 1. 2024年3月21日. CRD. URL: https://www.w3.org/TR/compositing-1/
[CSS-BACKGROUNDS-3]
Elika Etemad; Brad Kemper. CSS Backgrounds and Borders Module Level 3. 2024年3月11日. CRD. URL: https://www.w3.org/TR/css-backgrounds-3/
[CSS-BORDERS-4]
Elika Etemad; et al. CSS Borders and Box Decorations Module Level 4. 2025年7月22日. FPWD. URL: https://www.w3.org/TR/css-borders-4/
[CSS-BOX-4]
Elika Etemad. CSS Box Model Module Level 4. 2024年8月4日. WD. URL: https://www.w3.org/TR/css-box-4/
[CSS-BREAK-3]
Rossen Atanassov; Elika Etemad. CSS Fragmentation Module Level 3. 2018年12月4日. CR. URL: https://www.w3.org/TR/css-break-3/
[CSS-COLOR-4]
Chris Lilley; Tab Atkins Jr.; Lea Verou. CSS Color Module Level 4. 2025年4月24日. CRD. URL: https://www.w3.org/TR/css-color-4/
[CSS-DISPLAY-4]
Elika Etemad; Tab Atkins Jr.. CSS Display Module Level 4. 2025年11月6日. WD. URL: https://www.w3.org/TR/css-display-4/
[CSS-GRID-2]
Tab Atkins Jr.; et al. CSS Grid Layout Module Level 2. 2025年3月26日. CRD. URL: https://www.w3.org/TR/css-grid-2/
[CSS-INLINE-3]
Elika Etemad. CSS Inline Layout Module Level 3. 2024年12月18日. WD. URL: https://www.w3.org/TR/css-inline-3/
[CSS-MASKING-1]
Dirk Schulze; Brian Birtles; Tab Atkins Jr.. CSS Masking Module Level 1. 2021年8月5日. CRD. URL: https://www.w3.org/TR/css-masking-1/
[CSS-OVERFLOW-3]
Elika Etemad; Florian Rivoal. CSS Overflow Module Level 3. 2025年10月7日. WD. URL: https://www.w3.org/TR/css-overflow-3/
[CSS-POSITION-3]
Elika Etemad; Tab Atkins Jr.. CSS Positioned Layout Module Level 3. 2025年10月7日. WD. URL: https://www.w3.org/TR/css-position-3/
[CSS-SIZING-3]
Tab Atkins Jr.; Elika Etemad. CSS Box Sizing Module Level 3. 2021年12月17日. WD. URL: https://www.w3.org/TR/css-sizing-3/
[CSS-TEXT-4]
Elika Etemad; et al. CSS Text Module Level 4. 2024年5月29日. WD. URL: https://www.w3.org/TR/css-text-4/
[CSS-TRANSFORMS-1]
Simon Fraser; et al. CSS Transforms Module Level 1. 2019年2月14日. CR. URL: https://www.w3.org/TR/css-transforms-1/
[CSS-TRANSFORMS-2]
Tab Atkins Jr.; et al. CSS Transforms Module Level 2. 2021年11月9日. WD. URL: https://www.w3.org/TR/css-transforms-2/
[CSS-VALUES-3]
Tab Atkins Jr.; Elika Etemad. CSS Values and Units Module Level 3. 2024年3月22日. CRD. URL: https://www.w3.org/TR/css-values-3/
[CSS-VALUES-4]
Tab Atkins Jr.; Elika Etemad. CSS Values and Units Module Level 4. 2024年3月12日. WD. URL: https://www.w3.org/TR/css-values-4/
[CSS2]
Bert Bos; et al. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. 2011年6月7日. REC. URL: https://www.w3.org/TR/CSS2/
[FILTER-EFFECTS-1]
Dirk Schulze; Dean Jackson. Filter Effects Module Level 1. 2018年12月18日. WD. URL: https://www.w3.org/TR/filter-effects-1/
[MEDIAQUERIES-5]
Dean Jackson; et al. Media Queries Level 5. 2021年12月18日. WD. URL: https://www.w3.org/TR/mediaqueries-5/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. 1997年3月. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[SELECTORS-4]
Elika Etemad; Tab Atkins Jr.. Selectors Level 4. 2022年11月11日. WD. URL: https://www.w3.org/TR/selectors-4/

参考情報文献

[CSS-DISPLAY-3]
Elika Etemad; Tab Atkins Jr.. CSS Display Module Level 3. 2023年3月30日. CR. URL: https://www.w3.org/TR/css-display-3/
[CSS-TEXT-3]
Elika Etemad; Koji Ishii; Florian Rivoal. CSS Text Module Level 3. 2024年9月30日. CRD. URL: https://www.w3.org/TR/css-text-3/

プロパティ索引

名前 初期値 適用対象 継承 % アニメーション型 正規順序 算出値
border-collapse separate | collapse separate table grid boxes yes n/a 離散 文法に従う 指定されたキーワード
border-spacing <length>{1,2} 0px 0px border-collapse が separate である table grid boxes yes n/a 算出値による 文法に従う 2 つの絶対長さ
caption-side top | bottom top table-caption boxes yes n/a 離散 文法に従う 指定されたキーワード
empty-cells show | hide show table-cell boxes yes n/a 離散 文法に従う 指定されたキーワード
table-layout auto | fixed auto table grid boxes no n/a 離散 文法に従う 指定されたキーワード

課題索引

2.1 からの border-collapsing の破壊的変更 [Issue #604]
折り畳まれたボーダーの調和における詳細度を変更するか? [Issue #606]
border collapsing モードにおける固有オフセットの扱い [Issue #608]
編集上の課題。 これが colspanning cells からの幅分配を説明する方法は誤っている。 min-content 幅および max-content 幅については、 固有幅計算のために余剰幅を列へ分配する規則を参照するべきである。
編集上の課題。§ 3.8.3 列尺度の計算の関連する節をここに取り込む。
編集上の課題。TODO。現在の提案については、§ 3.10.5 分配アルゴリズムへ進む。
visibility:collapse が何をするかについて解決が必要である。 [Issue #478]
これは Firefox でしか機能しない。ただし、将来 position:sticky を実装しやすくするだろう。 [Chrome bug] [Interop risk: Firefox bug] [Issue #858]
empty-cells:hide を単純化できるか? [Issue #605]
セルは visibility:visible なグループ化要素の背景のみを描画すると述べることで、 row-group background を隠すべきか?