1. 導入
この節は規範的ではない
多くの種類の情報(例: 過去 1 年間に収集された気象観測値)は、 行が一覧の 1 項目 (例: 日付、およびその日に測定されたさまざまな気象特性)を表し、 列が項目の特性の連続する値 (例: 過去 1 年間に測定された気温)を表す、2 軸グリッドで視覚的に表すのが最適である。
時には、表現をより理解しやすくするために、 グリッドの一部のセルが、実際のデータではなく、親の行/列の説明または要約を表すために使用される。 これは、 最初の行および/または列にあるセル(ヘッダーと呼ばれる)、 または最後の行および/または列にあるセル(フッターと呼ばれる)でより頻繁に起こる。
この種の表形式データ表現は、通常、表として知られている。 表レイアウトは、カレンダーやタイムラインのような他のグリッド状の表現をレンダリングするために乱用され得るが、 表現される情報がデータ表として意味をなさない場合、 著者は他のレイアウトモードを優先するべきである。
HTML における表のレンダリングは、長い間 HTML 仕様で定義されてきた。 しかし、CSS で定義される機能との相互作用は長い間未定義のままであった。 この仕様の目的は、 HTML 表と CSS の両方をサポートするユーザーエージェントに期待される挙動を定義することである。
この文書で定義される一部の挙動は、 解決しようとする問題に対して最も論理的または有用な解決方法ではない場合があることに注意してほしい。 しかし、そのような挙動は多くの場合、互換性要件の結果であり、 この仕様の編集者による意図的な選択ではない。 より複雑なレイアウトを使用したい著者には、 CSS Grid など、より現代的な CSS モジュールに依存することが推奨される。
テスト
次のテストは、この仕様で説明される機能の一般的な使用に関連する クラッシュテストであるが、 特定の規範的な記述には結び付けられていない。
- colspan-zero-crash.html (ライブテスト) (ソース)
- caption-repaint-crash.html (ライブ テスト) (ソース)
- caption-with-multicol-table-cell.html (ライブ テスト) (ソース)
- cell-contents-with-negative-outer-size.html (ライブ テスト) (ソース)
- col_span_dynamic_crash.html (ライブ テスト) (ソース)
- dialog-table-crash.html (ライブ テスト) (ソース)
- dynamic-recompute-baseline.html (ライブ テスト) (ソース)
- dynamic_col_width_crash.html (ライブ テスト) (ソース)
- dynamic_table_layout_crash.html (ライブ テスト) (ソース)
- empty-tbody-after-tall-section-crash.html (ライブ テスト) (ソース)
- empty_cells_crash.html (ライブ テスト) (ソース)
- empty_table_with_cols.html (ライブ テスト) (ソース)
- expression_width_crash.html (ライブ テスト) (ソース)
- inline-splitting-crash.html (ライブ テスト) (ソース)
- large-border-crash.html (ライブ テスト) (ソース)
- large-col-widths.html (ライブ テスト) (ソース)
- legacy_ng_mix_crash.html (ライブ テスト) (ソース)
- move-oof-inside-section-row-with-borders.html (ライブ テスト) (ソース)
- negative-section-distribution.html (ライブ テスト) (ソース)
- negative_caption_margin.html (ライブ テスト) (ソース)
- orthogonal-cell-borders.html (ライブ テスト) (ソース)
- orthogonal-cell-crash.html (ライブ テスト) (ソース)
- table-column-display-change-chrome-crash.html (ライブ テスト) (ソース)
- textarea-intrinsic-size-crash.html (ライブ テスト) (ソース)
- transition-table-row-group-crash.html (ライブ テスト) (ソース)
- uninitialized_read_crash.html (ライブ テスト) (ソース)
- vertical_percentage_crash.html (ライブ テスト) (ソース)
- tfoot-crash-print.html (ライブテスト) (ソース)
- th-text-align.html (ライブテスト) (ソース)
- toggle-row-display-property-001.html (ライブ テスト) (ソース)
- table-collapsed-row-or-column-crash.html (ライブ テスト) (ソース)
表レイアウトに一般的に関連するテスト
- absolute-tables-001.html (ライブテスト) (ソース)
- absolute-tables-006.html (ライブテスト) (ソース)
- anonymous-table-cell-margin-collapsing.html (ライブ テスト) (ソース)
- chrome-rowspan-bug.html (ライブテスト) (ソース)
- col_removal.html (ライブテスト) (ソース)
- colspan-001.html (ライブテスト) (ソース)
- colspan-002.html (ライブテスト) (ソース)
- colspan-003.html (ライブテスト) (ソース)
- colspan-004.html (ライブテスト) (ソース)
- dynamic-rowspan-change.html (ライブ テスト) (ソース)
- html-display-table.html (ライブテスト) (ソース)
- inheritance.html (ライブテスト) (ソース)
- multicol-table-collapsed-border-crash.html (ライブ テスト) (ソース)
- multicol-table-crash.html (ライブ テスト) (ソース)
- remove-caption-from-anon-table.html (ライブ テスト) (ソース)
- remove-colgroup-from-anon-table.html (ライブ テスト) (ソース)
- row-group-order.html (ライブテスト) (ソース)
- table-position-sticky-computed.html (ライブ テスト) (ソース)
- table-cell-child-overflow-measure.html (ライブ テスト) (ソース)
- table-cell-inline-size-box-sizing-quirks.html (ライブ テスト) (ソース)
- table-cell-scroll-height.html (ライブ テスト) (ソース)
- table-cell-writing-mode-computed.html (ライブ テスト) (ソース)
- zero-rowspan-001.html (ライブテスト) (ソース)
- zero-rowspan-002.html (ライブテスト) (ソース)
- subpixel-table-cell-height-001.html (ライブ テスト) (ソース)
- subpixel-table-width-001.html (ライブ テスト) (ソース)
1.1. 値の定義
この仕様は、[CSS2] の CSS プロパティ 定義の慣例に従い、[CSS-VALUES-3] の 値定義構文を使用する。 この仕様で定義されない値型は CSS Values & Units [CSS-VALUES-3] で定義される。 他の CSS モジュールとの組み合わせにより、これらの値型の定義が拡張される可能性がある。
各プロパティの定義に列挙されているプロパティ固有の値に加えて、 この仕様で定義されるすべてのプロパティは、 プロパティ値として CSS 全域キーワードも受け入れる。 読みやすさのため、それらは明示的には繰り返されていない。
2. 内容モデル
2.1. 表構造
CSS 表モデルは HTML4 の表モデルに基づいており、 そこでは表の構造が表の視覚的レイアウトと密接に対応している。 このモデルでは、表は任意のキャプションと任意数のセル行から構成される。
さらに、隣接する行と列は構造的にグループ化でき、 このグループ化は表示に反映され得る(例: 行グループの周囲にボーダーを描くことができる)。
表モデルは「行優先」であると言われる。なぜなら、 著者は文書言語で列ではなく行を明示的に指定するからである。 列は、すべての行が指定された後に導出される。 すなわち、最初の行の最初のセルは最初の列 およびスパンに必要なだけの他の列に属する(必要ならそれらを作成する)。 そして、その行の後続のセルはそれぞれ次に利用可能な列 およびスパンに必要なだけの他の列に属する(必要ならそれらを作成する)。 後続の行のセルはそれぞれ、その行で次に利用可能な列(rowspan を考慮する)に属し、 スパンに必要なだけの他の列に属する(必要ならそれらを作成する)。 (§ 3.3 行/列グリッドの寸法決定を参照)。
まとめると、表モデルのインスタンスは次から構成される:
-
その table-root は次を含む:
-
0 個、1 個、または複数の table rows。任意で row groups 内にある。
- それぞれが 1 個または複数の table cells を含む
- 任意で: 1 個または複数の table columns。 任意で column groups 内にある
- 任意で: 1 個または複数の table caption。
-
0 個、1 個、または複数の table rows。任意で row groups 内にある。
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-group、table-track、または table-caption ボックス。
- proper table-row parent ボックスまたは要素
- table-root または table-row-group ボックス。
- table-internal ボックスまたは要素
- table-cell、table-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 により覆われるのは、rがrowStart(含む)からrowStart+rowSpan(含まない)までの区間にあり、 かつcがcolStart(含む)から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-table、 table-row、および table-cell に対応する。 欠落したボックスは、次の規則に従って匿名ボックスの生成を引き起こす:
2.2.1. 補正アルゴリズム
これらの規則の目的では、フロー外 要素は幅と高さが 0 のインライン要素として表現される。 それらの包含ブロックはそれに応じて選択される。
次の手順は 3 段階で実行される:
-
無関係なボックスを除去する:
次のボックスはdisplay:noneであるかのように破棄される:- table-column の子。
- table-column-group の子であり、table-column ではないもの。
- 空白だけを含み、 かつそれぞれが table-non-root ボックスである 2 つの直接の兄弟の間にある 匿名インラインボックス。
-
次のすべての基準を満たす匿名インラインボックス:
- 空白だけを含む
- tabular container の最初および/または最後の子である
- 直接の兄弟が存在する場合、その兄弟が table-non-root ボックスである
-
欠落した子ラッパーを生成する:
- proper table child ボックスではない、 table-root ボックスの連続する子の各列の周囲に、 匿名 table-row ボックスを 生成しなければならない。 !!Testcase
- table-row ボックスではない、 table-row-group ボックスの連続する子の各列の周囲に、 匿名 table-row ボックスを 生成しなければならない。 !Testcase
- table-cell ボックスではない、 table-row ボックスの連続する子の各列の周囲に、 匿名 table-cell ボックスを生成しなければならない。 !Testcase
-
欠落した親を生成する:
- 親が table-row ではない、連続する table-cell ボックスの各列の周囲に、 匿名 table-row ボックスを 生成しなければならない。 Testcase
-
親が誤っている、連続する proper table child ボックスの各列の周囲に、
匿名 table または inline-table ボックスを
生成しなければならない。
ボックスの親がインライン、run-in、または ruby ボックス(またはその子に対して
インライン化を行う任意のボックス)である場合、
inline-table ボックスを生成しなければならない。
そうでなければ table ボックスでなければならない。
- table-row は、 その親が table-row-group でも table-root ボックスでもない場合、 誤った親を持つ。
- table-column ボックスは、 その親が table-column-group ボックスでも table-root ボックスでもない場合、 誤った親を持つ。
- table-row-group、table-column-group、 または table-caption ボックスは、 その親が table-root ボックスでない場合、誤った親を持つ。
- 各 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 の包含ブロックに対して相対的である。
block へ切り替わる。
この変換は表の補正より前に発生する。
テスト
- anonymous-table-ws-001.html (ライブ テスト) (ソース)
- fixup-dynamic-anonymous-inline-table-001.html (ライブ テスト) (ソース)
- fixup-dynamic-anonymous-inline-table-002.html (ライブ テスト) (ソース)
- fixup-dynamic-anonymous-inline-table-003.html (ライブ テスト) (ソース)
- fixup-dynamic-anonymous-table-001.html (ライブ テスト) (ソース)
- table-model-fixup.html (ライブテスト) (ソース)
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. 中核レイアウト原則
他のブロックレベルボックスとは異なり、表は既定では包含ブロックを満たさない。
それらの width が
auto に算出されると、代わりに fit-content が指定されたかのように振る舞う。
これは、代わりに stretch を持つかのように振る舞うほとんどのブロックレベルボックスとは異なる。
表の min-content 幅は、 すべての列の min-content 幅およびその 分配不能な空間を収めるために必要な幅である。
表の max-content 幅は、 すべての列の max-content 幅およびその 分配不能な空間を収めるために必要な幅である。
表に割り当てられた幅がその min-content 幅より大きい場合、 利用可能な幅の分配アルゴリズムは それに応じて列幅を調整する。
この節は、他の仕様で説明される幅計算に適用される汎用規則を上書きする。
特に、表のマージンが 0 に設定され、幅が auto に設定されている場合、
表は包含ブロックを満たすように自動的にサイズ決定されない。
ただし、表の width の使用値が見つかった後(下記のアルゴリズムを使用)、
それらの規則の他の部分は適用される。
したがって、たとえば左右の auto マージンを使用して表を中央揃えにできる。
3.2. 表レイアウトアルゴリズム
表をレイアウトするために、ユーザーエージェントは次の動作を適用しなければならない:
- 表が必要とする行/列の数を決定する。
これは § 3.3 行/列グリッドの寸法決定で説明される手順を実行することで行われる。 -
[A] 行/列グリッドに少なくとも 1 つの スロットがある場合:
- 各セル スロットが少なくとも 1
つのセルに占有されるようにする。
これは § 3.4 欠落セルの補正で説明される手順を実行することで行われる。 - 各列の最小幅を計算する。
これは § 3.8 表の尺度の計算で説明される手順を実行することで行われる。 - 表の幅を計算する。
これは § 3.9.1 表幅の計算で説明される手順を実行することで行われる。 - 表の幅を列の間で分配する。
これは § 3.9.3 分配アルゴリズムで説明される手順を実行することで行われる。 - 表の高さを計算する。
これは § 3.10.1 表高さの計算で説明される手順を実行することで行われる。 - 表の高さを行の間で分配する。
これは § 3.10.5 分配アルゴリズムで説明される手順を実行することで行われる。
[B] そうでなければ、空の 表がレイアウトされる:
- 表の幅を計算する。
これは CAPMIN と table grid box の算出幅 (ボーダーと padding を含む)のうち大きい方の値を返すことで行われる。 それが確定的である場合に限る(そうでなければ 0 を使用する)。 - 表の高さを計算する。
これはすべての table-caption 高さ (それらの幅は表幅に設定され、 マージンは適切に考慮される) と、table grid box の算出高さ(ボーダーと padding を含む)との合計を返すことで行われる。 それが確定的である場合に限る(そうでなければ 0 を使用する)。
- 各セル スロットが少なくとも 1
つのセルに占有されるようにする。
- 各 table-caption および table-cell にその位置とサイズを割り当てる。
これは § 3.11 セル、キャプション、およびその他の内部表ボックスの位置決めの手順を実行することで行われる。
次の図式は、理解しやすくするために、 アルゴリズムを別の方法で説明している。
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 要素ではないからである。
テスト
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-layout、border-collapse、および caption-side。 border-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-root は collapsed-borders モードでレイアウトされると言われる。 そうでなければ、table-root は separated-borders モードでレイアウトされると言われる。
テスト
- background-clip-001.html (ライブテスト) (ソース)
- box-shadow-001.html (ライブテスト) (ソース)
- collapsed-border-color-change-with-compositing.html (ライブ テスト) (ソース)
- collapsed-border-remove-row-group.html (ライブ テスト) (ソース)
- collapsed-scroll-overflow.html (ライブ テスト) (ソース)
- border-collapse-computed.html (ライブ テスト) (ソース)
- border-collapse-invalid.html (ライブ テスト) (ソース)
- border-collapse-valid.html (ライブ テスト) (ソース)
3.5.2.1. Border-Spacing プロパティ
| 名前: | border-spacing |
|---|---|
| 値: | <length>{1,2} |
| 初期値: | 0px 0px |
| 適用対象: | table grid boxes で、border-collapse が separate のとき |
| 継承: | 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
- キャプションボックスを表グリッドボックスの下に配置する。
キャプション内容をキャプションボックス内で水平方向に整列するには、text-align プロパティを使用する。
この例では、caption-side プロパティがキャプションを表の下に配置する。 キャプションは表の親と同じ幅になり、キャプションテキストは左揃えになる。
caption {
caption-side: bottom;
width: auto;
text-align: left
}
3.6. スタイルオーバーライド
一部の css プロパティは、css 表の内部で異なる挙動をする。 次の節では、その例外と効果を列挙する。
3.6.1. すべてのモードで適用されるオーバーライド
次の規則は、使用中のレイアウトモードに関わらず、すべての表に適用される。
-
表上のプロパティ position、float、
margin-*、top、right、
bottom、および left の算出値は、
table grid box ではなく table-wrapper box 上で使用される。
同じことは、transform-style の使用値を
flatに強制し得るプロパティ (一覧を参照)と、その ショートハンド/ロングハンド関係にも当てはまる: この一覧には現在、overflow、opacity、 filter、clip、clip-path、isolation、mask-*、mix-blend-mode、transform-* および perspective が含まれる。
指定値が table grid および/または wrapper boxes に適用されない場合、 そのボックスには代わりに未設定値(プロパティに応じて inherit または initial)が使用される。 - overflow プロパティは、table-root および table-wrapper
ボックス上で、その値が
visible、clip、またはhiddenのいずれでもない場合、 無視され、その値がvisibleであったかのように扱われる。 - table-column および table-column-group ボックスのすべての css プロパティは、 この仕様で明示的に指定される場合を除き、無視される。
- margin、padding、overflow および z-index は、table-track および table-track-group ボックスでは無視される。
- margin は、table-cell ボックスでは無視される (0px に設定されたかのように)。
- background は、table-cell ボックスについて、 § 5.3.2 セル背景の描画で説明される特別な背景描画アルゴリズムを使用して描画される。
3.6.2. collapsed-borders モードで適用されるオーバーライド
表が collapsed-borders モードでレイアウトされる場合、次の規則が適用される:
- padding は、 table-root では 無視される(0px に設定されたかのように)。
- border-spacing は、table-root では無視される(0px に設定されたかのように)。
- border-radius は、table-root および table-non-root ボックスの両方で 無視される(0px に設定されたかのように)。
- table-root およびそれが所有する table-cell ボックスのボーダーの レイアウトとレンダリングに使用される値は、§ 3.7 ボーダーの折り畳みで説明される特別な競合解決アルゴリズムを使用して決定される。
3.7. ボーダーの折り畳み
この節全体は、折り畳まれたボーダーのレンダリングをまともにするための提案である。 実装が非常に目に見えて分岐しているため、他の一部よりも多くの議論が必要になると予想される。 ブラウザーがこれを非常に異なる方法で処理しているため、再実装なしに収束は起こり得ない。 この提案の主要な懸念は、できるだけ多くの場合をサポートしつつ、 表の新しい実装に必要な労力をできるだけ低く保つことであった。
背景: CSS+HTML は表の接合部に対して前例のないボーダーモードの組み合わせを許可し、 すべての場合を適切にサポートすることを難しくしている。 実際、一部の組み合わせは適切に定式化された 問題ではなく、 したがって最適なレンダリングアルゴリズムは存在し得ない。
それらは単純なもの(HTML)から非常に複雑なもの(HTML+CSS)へと成長したため、 Web ブラウザーで使用される現在の表レンダリングモデル(背景とボーダー)は狂っている (バグがあり、相互運用性がなく、まったく CSS らしくないという意味で)。 通常の CSS の仮定の多くが破られ、レンダリングは大きく分岐している。
この提案はこの状況を修正することを目指している。
テスト
- border-collapse-double-border.html (ライブ テスト) (ソース)
- border-collapse-dynamic-col-001.html (ライブ テスト) (ソース)
- border-collapse-dynamic-oof.html (ライブ テスト) (ソース)
- border-collapse-dynamic-section.html (ライブ テスト) (ソース)
- border-collapse-empty-cell.html (ライブ テスト) (ソース)
- border-collapse-rowspan-cell.html (ライブ テスト) (ソース)
- collapsed-border-remove-cell.html (ライブ テスト) (ソース)
2.1 からの border-collapsing の破壊的 変更 [Issue #604]
3.7.1. 折り畳まれたボーダーの競合解決
collapsed-borders モードでレイアウトされるとき、ボーダーを共有する table-root および table-cell ボックスは、 同じスタイル、幅、および色を使用してレンダリングされるように(可能な場合)、 それらのボーダーを統一しようとする。 これは、次のアルゴリズムを実行することで達成される。
3.7.1.1. 折り畳まれた ボーダーの競合解決アルゴリズム
table-root の任意の table-cell C° について:
-
border-right との競合を解決する:
- S を、RowStart/ColumnStart 順でセルによりソートされた table-cell ボーダースタイルの順序付き集合とする。 初期状態では、S は C° の border-right スタイルのみを含むものとする
- C° の右ボーダーと左ボーダーの一区間を共有するすべてのセルの border-left スタイルを、集合 S に追加する
-
新しいボーダースタイルが S に追加されなくなるまで、次の 2 つの命令を繰り返す:
- rowspan が 1 より大きいセル Ci から新たに追加されたすべての左ボーダーについて、 Ci の border-left と border-right の一区間を共有するすべてのセルの border-right スタイルを 集合 S に追加する
- rowspan が 1 より大きいセル Ci から新たに追加されたすべての右ボーダーについて、 Ci の border-right と border-left の一区間を共有するすべてのセルの border-left スタイルを 集合 S に追加する
- S の競合するボーダーを調和する
-
border-bottom との競合を解決する:
- S を、RowStart/ColumnStart 順でセルによりソートされた table-cell ボーダースタイルの順序付き集合とする。 初期状態では、S は C° の border-bottom スタイルのみを含むものとする
- C° の下ボーダーと上ボーダーの一区間を共有するすべてのセルの border-top スタイルを、集合 S に追加する
-
新しいボーダースタイルが S に追加されなくなるまで、次の 2 つの命令を繰り返す:
- rowspan が 1 より大きいセル Ci から新たに追加されたすべての上ボーダーについて、 Ci の border-top と bottom border の一区間を共有するすべてのセルの border-bottom スタイルを 集合 S に追加する
- rowspan が 1 より大きいセル Ci から新たに追加されたすべての下ボーダーについて、 Ci の border-bottom と top border の一区間を共有するすべてのセルの border-top スタイルを 集合 S に追加する
- S の競合するボーダーを調和する
-
すべてのボーダーの使用幅を 2 で割る。
この効果は必要な箇所でレンダリング時に補償されるが、 レイアウトの正しさのために必要である。 (§ 5.3.3.1 collapsed-borders モードでの変更を参照)
次に、その table-root について:
- table-root の
border-{top,bottom,left,right} を、
表のボーダーを形成するすべてのセルの対応するボーダーと(独立に)調和する。
ただし、table-root のボーダープロパティを実際には変更しない。
表とセルのボーダー スタイルが同じ詳細度を持つ場合、 セルのボーダースタイルを保持する。
これが完了したら、table-root の border-{…}-width を、 そのボーダーについて調和プロセス中に見つかった最大幅の半分に設定し、 その後 border-{…}-style を solid に、border-{…}-color を transparent に設定する。
https://jsfiddle.net/bn3d1sm4/
https://jsfiddle.net/bn3d1sm4/1/
https://jsfiddle.net/bn3d1sm4/2/
…
https://jsfiddle.net/bn3d1sm4/15/
テスト
3.7.1.2. 折り畳まれた ボーダーの調和アルゴリズム
折り畳まれたボーダーの 調和における詳細度を変更するか? [Issue #606]
ボーダースタイルの順序付き集合(セル C1, C2, … に位置する BC1, BC2, …)が与えられたとき、 それらの競合するボーダーについてボーダープロパティの使用値を決定するため、次のアルゴリズムを実行する。
- CurrentlyWinningBorderProperties を “border: 0px none transparent” に設定する
-
各ボーダー BCi について:
- BCi ボーダーのプロパティを考慮する
-
ボーダーが 2 つの列を分離する場合:
- 各ボーダー BCi について: 存在する場合、Ci セルがまたがる各 table-column について。 BCi に連続して描画される table-column の任意のボーダーのボーダープロパティを考慮する。
- 各ボーダー BCi について: 存在する場合、Ci セルがまたがる列を含む各 table-column-group について。 BCi に連続して描画される table-column-group の任意のボーダーのボーダープロパティを考慮する。
-
ボーダーが 2 つの行を分離する場合:
- 各ボーダー BCi について: 存在する場合、Ci セルがまたがる各 table-row について。 BCi に連続して描画される table-column の任意のボーダーのボーダープロパティを考慮する。
- 各ボーダー BCi について: 存在する場合、Ci セルがまたがる列を含む各 table-row-group について。 BCi に連続して描画される table-row-group の任意のボーダーのボーダープロパティを考慮する。
- CurrentlyWinningBorderProperties を返す
3.7.1.3. ボーダースタイルの詳細度
2 つのボーダースタイルが与えられたとき、最も詳細度の高いボーダースタイルとは、次のボーダースタイルである…
- … 片方だけが border-style として "hidden" の値を持つ場合、それを持つもの
- … css ピクセルに変換された後で最大の border-width を持つもの
-
… 次の一覧で最初に来る 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 距離(存在する場合)を加えたものである。
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 についてはゼロ値)からなる集合であり、
次のように定義される:
- separated-borders モード: table-root の算出された 水平方向 padding および border
- collapsed-borders モード: セルの使用 border-width 値(勝利した border-width の半分)
マージンは表固有オフセットに含まれない。 なぜなら、マージンの扱いは 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 値の半分である (競合解決の説明 注記を参照)
- 外側 min-content および 外側 max-content 幅
-
外側 min-content 幅および max-content 幅は、表セル、列、および列グループについて定義される。
これらの定義で使用される width、min-width、および max-width の値は、
上で定義されたオフセット調整済み値である:
- table-cell の外側 min-content 幅は、
max(min-width, min-content width)をセル固有オフセットで調整したものである。 - table-column または table-column-group の外側 min-content 幅は、
max(min-width, width)である。 - 非制約列内の
table-cell の外側 max-content 幅は、
max(min-width, width, min-content width, min(max-width, max-content width))をセル固有オフセットで調整したものである。 - 制約列内の
table-cell の外側 max-content 幅は、
max(min-width, width, min-content width, min(max-width, width))をセル固有オフセットで調整したものである。 - table-column または table-column-group の外側 max-content 幅は、
max(min-width, min(max-width, width))である。
- table-cell の外側 min-content 幅は、
- パーセンテージ 寄与
-
表セル、列、または列グループのパーセンテージ寄与は、
パーセンテージである算出値を持つ width および
max-width の算出値に関して定義される:
min(percentage width, percentage max-width)。
算出値がパーセンテージでない場合、 width には0%が使用され、 max-width にはinfiniteパーセンテージが使用される。
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 幅
-
次の最大値:
- 対応する table-column-group の外側 max-content 幅(存在する場合)
- 対応する table-column の外側 max-content 幅(存在する場合)
- その列にまたがる各セルで、colSpan が 1 であるものの外側 max-content 幅 (またはfixed モードでは最初の行の 1 つだけ) または、そのようなセルが存在しない場合は 0
- スパンが最大 1 のセルに基づく列の固有パーセンテージ幅
- その列にまたがる各セルで colSpan が 1 であるもの、 対応する table-column(存在する場合)、 および対応する table-column-group(存在する場合)のパーセンテージ寄与の最大値
- スパンが最大 N (N > 1) のセルに基づく列の min-content 幅
-
スパンが最大 N-1 のセルに基づく列の min-content 幅と、
colSpan が N である、その列内のセルの寄与の最大値。
ここで、セルの寄与は次の手順を実行した結果である:
- 基準 min-content 幅を、 そのセルがまたがるすべての列について、 スパンが最大 N-1 のセルに基づく max-content 幅の合計として定義する。
- 基準 border spacing を、 セルがまたがる列のうち、セルが発生する列以外の任意の列についての水平方向 border-spacing の合計として定義する。
-
セルの寄与は次の合計である:
- スパンが最大 N-1 のセルに基づく列の min-content 幅
-
次の積:
-
次の比率:
- 列の、スパンが最大 N-1 のセルに基づく max-content 幅 から、列のスパンが最大 N-1 のセルに基づく min-content 幅を引いたものと、
- 基準 max-content 幅から基準 min-content 幅を引いたもの
- セルの外側 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 である、その列内のセルの寄与の最大値。
ここで、セルの寄与は次の手順を実行した結果である:
- 基準 max-content 幅を、 そのセルがまたがるすべての列について、 スパンが最大 N-1 のセルに基づく max-content 幅の合計として定義する。
- 基準 border spacing を、 セルがまたがる任意の列についての水平方向 border-spacing の合計として定義する。 ただし、セルが発生する列は除く。
-
セルの寄与は次の合計である:
- スパンが最大 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 である列内のセルの 寄与の最大値であり、 ここで、セルの寄与は次の手順を実行した結果である:- セルのパーセンテージ寄与から開始する。
- セルがまたがるすべての列について、スパンが最大 N-1 のセルに基づく列の固有パーセンテージ幅を引く。 これが負の結果を与える場合、0% に変更する。
-
次の比率を掛ける:
- 列の非スパン max-content 幅と、
- セルがまたがるすべての列のうち、 スパンが最大 N-1 のセルに基づく列の固有パーセンテージ幅が 0% に等しいものの 非スパン max-content 幅の合計。
- 列の 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 を持つ場合、 制約されている。
テスト
- computing-row-measure-0.html (ライブ テスト) (ソース)
- computing-row-measure-1.html (ライブ テスト) (ソース)
- percentage-sizing-of-table-cell-children.html (ライブ テスト) (ソース)
- percentage-sizing-of-table-cell-replaced-children-001.html (ライブ テスト) (ソース)
- computing-column-measure-0.html (ライブ テスト) (ソース)
- computing-column-measure-1.html (ライブ テスト) (ソース)
- computing-column-measure-2.html (ライブ テスト) (ソース)
3.9. 利用可能な幅の分配
テスト
- distribution-algo-1.html (ライブ テスト) (ソース)
- distribution-algo-2.html (ライブ テスト) (ソース)
- distribution-algo-min-content-guess.html (ライブ テスト) (ソース)
- distribution-algo-min-content-percent-guess.html (ライブ テスト) (ソース)
- distribution-algo-min-content-specified-guess.1.html (ライブ テスト) (ソース)
- distribution-algo-min-content-specified-guess.html (ライブ テスト) (ソース)
- td-with-subpixel-padding-vertical-rl.html (ライブ テスト) (ソース)
- td-with-subpixel-padding.html (ライブ テスト) (ソース)
3.9.1. 表幅の計算
すべての列の最終幅を決定する前に、 表自体の幅を計算する必要がある。
前述のとおり、これは通常、すべての列の優先幅の合計に、 任意の追加分を加えたものになる。 この場合、幅の分配により各列にはその優先幅が与えられる。 ただし、著者が明示的に別の幅を求めるいくつかの場合、 および表が必要とする幅を与えられないいくつかの場合がある。
キャプション幅の最小値 (CAPMIN) は、 table captions の min-content 寄与の最大値である。
行/列グリッド幅の最小値 (GRIDMIN) 幅は、 すべての列の min-content 幅の合計に、 セル間隔またはボーダーを加えたものである。
行/列グリッド幅の最大値 (GRIDMAX) 幅は、 すべての列の max-content 幅の合計に、 セル間隔またはボーダーを加えたものである。
表の使用 min-widthは、 解決済みの min-width、CAPMIN、および GRIDMIN のうち大きい方である。
表の使用幅は、 次のように列幅とキャプション幅に依存する:
-
table-root の width
プロパティが
auto以外の算出値 (resolved-table-width に解決される)を持つ場合、 使用幅は、resolved-table-width と 表の使用 min-widthのうち大きい方である。使用幅が GRIDMIN より大きい場合、 余分な幅は列に分配されるべきである。 § 3.9 利用可能な幅の分配を参照。 - table-root が 'width: auto' を持つ場合、 使用幅は、 min(GRIDMAX, 表の包含ブロック幅) と、 表の使用 min-widthのうち大きい方である。
割当可能な表幅は、 表の使用幅から、 水平方向 border spacing の合計(存在する場合)を引いたものである。 これは列に割り当てることができる幅である。
テスト
- visibility-collapse-col-001.html (ライブ テスト) (ソース)
- visibility-collapse-col-002.html (ライブ テスト) (ソース)
- visibility-collapse-col-003.html (ライブ テスト) (ソース)
- visibility-collapse-col-004-dynamic.html (ライブ テスト) (ソース)
- visibility-collapse-col-005.html (ライブ テスト) (ソース)
- visibility-collapse-colspan-001.html (ライブ テスト) (ソース)
- visibility-collapse-colspan-002.html (ライブ テスト) (ソース)
- visibility-hidden-col-001.html (ライブ テスト) (ソース)
- visibility-hidden-nested-001.html (ライブ テスト) (ソース)
- visibility-hidden-nested-002.html (ライブ テスト) (ソース)
- computing-table-width-0.html (ライブ テスト) (ソース)
- computing-table-width-1.html (ライブ テスト) (ソース)
- table-intrinsic-size-001.html (ライブ テスト) (ソース)
- table-intrinsic-size-002.html (ライブ テスト) (ソース)
- table-intrinsic-size-003.html (ライブ テスト) (ソース)
- table-intrinsic-size-004.html (ライブ テスト) (ソース)
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 種類すべての列には、次の可能な使用幅がある。
- min-content 幅:
列の内容を収めるために必要なサイズ - min-content 幅 + delta:
min-content 幅と優先幅の間の値 - 優先幅:
列に指定されたサイズ、 または列の内容を折り返さずに収めるために必要なサイズ - 優先幅 + delta
優先幅より大きい値
分配アルゴリズムはこれらの値を定義し、それらをいつ使用するかを説明する。
3.9.3. 分配アルゴリズム
表が与えられた使用幅でレイアウトされるとき、 各列の使用幅は、必要に応じて このアルゴリズムへの変更を fixed モードで適用した後、 次のように決定されなければならない。
まず、表の各列にはサイズ指定型が割り当てられる:
-
percent-column:
いずれかの制約がパーセンテージのみを使用するよう定義された列 (0% と異なる値を持つもの) -
pixel-column:
いずれかの制約が定義済みの長さのみを使用するよう定義された列 (かつ percent-column ではないもの) -
auto-column:
その他すべての列
次に、有効なサイズ指定方法がサイズ指定型ごとに列へ割り当てられ、 次の sizing-guesses が得られる:
- min-content sizing-guess は、 各列にその min-content 幅が割り当てられる列幅割当ての集合である。
-
min-content-percentage sizing-guess は、
次のような列幅割当ての集合である:
-
各 percent-column には、次のうち大きい方が割り当てられる:
- その固有パーセンテージ幅に割当可能幅を掛けたもの、および
- その min-content 幅。
- その他すべての列には、その min-content 幅が割り当てられる。
-
各 percent-column には、次のうち大きい方が割り当てられる:
-
min-content-specified sizing-guess は、
次のような列幅割当ての集合である:
-
各 percent-column には、次のうち大きい方が割り当てられる:
- その固有パーセンテージ幅に割当可能幅を掛けたもの、および
- その min-content 幅
- 制約されているその他の任意の列には、その max-content 幅が割り当てられる
- その他すべての列には、その min-content 幅が割り当てられる。
-
各 percent-column には、次のうち大きい方が割り当てられる:
-
max-content
sizing-guess は、次のような列幅割当ての集合である:
-
各 percent-column には、次のうち大きい方が割り当てられる:
- その固有パーセンテージ幅に割当可能幅を掛けたもの、および
- その min-content 幅
- その他すべての列には、その max-content 幅が割り当てられる。
-
各 percent-column には、次のうち大きい方が割り当てられる:
-
割当可能な表幅は常に、 min-content sizing-guess から得られる表幅以上である。
-
4 つの sizing-guesses (min-content、min-content-percentage、min-content-specified、および max-content) における各列の幅は非減少順である。
割当可能な 表幅が max-content sizing-guess 以下である場合、 列の使用幅は、幅の合計が利用可能幅を挟む 2 つの連続する sizing-guesses の 線形結合(重みの合計が 1)でなければならない。
そうでなければ、列の使用幅は、max-content sizing-guess から開始し、 余剰幅を列へ分配する規則 (使用幅について)に従って、余剰幅を表の列へ分配した結果である。
次の図式は、理解しやすくするために、 アルゴリズムを別の方法で説明している。
凡例
サイズ指定アルゴリズム: 表の各描画は、列をサイズ指定する 1 つの方法を表す。 左側の 4 つの場合は、仕様で上に説明された sizing-guesses である: min-content、min-content-percentage、min-content-specified、および max-content。 右側の場合は、4 つの sizing-guesses のいずれかと正確に一致しない利用可能サイズに必要な補間である。
サイズ指定方法の選択: サイズ指定方法の選択は常に min-content sizing-guess(左上)から開始し、 次に利用可能幅と現在使用中の方法により消費される幅を比較しながら進む。 緑の矢印は、現在の方法を適用した後に分配する余分な空間がある場合に 従うべき方向を示す。 赤の矢印は、現在の方法を適用して空間を分配しすぎており、 戻る必要がある場合に従うべき方向を示す。
列の型: 各列の型(auto、px、%)は図式内で独自の色(黄、 青、オレンジ)を持つ。 補間では、 前の sizing-guess でのサイズから縮小された列は赤で再描画され、 前の sizing-guess でのサイズから拡大された列は緑で再描画される。
3.9.3.1. fixed モードにおける幅分配の変更
前述のアルゴリズムへの次の変更は、fixed モードで適用される:
-
percent-columns および auto-columns の min-content 幅は 0 とみなされる
-
セルは、その幅がパーセンテージである場合、border と padding のサイズを無視する(box-sizing は無視される)
-
パーセンテージが割当可能な表幅に基づいて解決されるとき、 この解決に基づく列幅の合計が割当可能な表幅を超える場合、 代わりに、そのパーセンテージ値に相対して解決され、 列幅の合計が割当可能な表幅に正確に一致するようにする。
-
サイズがパーセンテージとピクセル長の合計として計算される列は、 2 つの列として数えられるかのようにサイズ指定されなければならない。 1 つはピクセル値を持ち、もう 1 つはパーセンテージ値を持つ。これはパーセンテージを解決して取り除くこととは異なる。 なぜなら、パーセンテージベースの列に対する幅分配の仕組みがあるためである。
3.9.3.2. 余剰幅を列へ分配する
余剰幅を列へ分配する規則は、 2 つの方法で呼び出すことができる:
- 表の余剰幅をその列へ分配するため。 それらの列の使用幅の計算中(使用幅計算のため)に行うもの、または
- 複数列にまたがるセルの余剰 max-content または min-content 幅を、 それがまたがる列の max-content または min-content 幅へ分配するため(固有幅計算のため)。
これら 2 つの場合の規則は大部分同じだが、わずかな違いがある。
この節の残りでは、分配されているこれらの幅の 1 つを指すために、 分配幅という用語を使用し、 余剰幅は、 分配されている幅が、それを分配先とする列の分配幅の合計を 超過する量を指すために使用される。
- 固有パーセンテージ幅が 0% であり、 かつ非ゼロの max-content 幅を持つ発生セルを有する 非制約列が存在する場合 (別名、この規則により成長が許される列)、 この規則により成長が許される列の分配 幅は、max-content 幅に比例して増加され、 増加の合計が余剰幅になるようにする。
- そうでなく、固有パーセンテージ幅が 0% である発生セルを有する 非制約列が存在する場合 (別名、この規則により成長が許される列であり、前の規則により max-content 幅がゼロでなければならないもの)、 この規則により成長が許される列の分配 幅は、等しい量ずつ増加され、 増加の合計が余剰幅になるようにする。
- そうでなく、固有パーセンテージ幅が 0% であり、 かつ非ゼロの max-content 幅を持つ 制約列が存在する場合 (別名、この規則により成長が許される列であり、他の規則により発生セルを持たなければならないもの)、 この規則により成長が許される列の分配 幅は、max-content 幅に比例して増加され、 増加の合計が余剰幅になるようにする。
- そうでなく、固有パーセンテージ幅が 0% より大きい列が存在する場合 (別名、この規則により成長が許される列であり、他の規則により発生セルを持たなければならないもの)、 この規則により成長が許される列の分配 幅は、固有パーセンテージ幅に比例して増加され、 増加の合計が余剰幅になるようにする。
- そうでなく、そのような列が存在する場合、 発生セルを持つすべての列の分配 幅は、等しい量ずつ増加され、 増加の合計が余剰幅になるようにする。
- そうでなければ、 すべての列の分配 幅は、等しい量ずつ増加され、 増加の合計が余剰幅になるようにする。
- 幅が指定されていない列が存在する場合、余剰幅はそのような列に等しく分配される
- そうでなく、基準割当てから非ゼロの長さ幅を持つ列が存在する場合、余剰幅はそれらの列の幅に比例して分配される
- そうでなく、基準割当てから非ゼロのパーセンテージ幅を持つ列が存在する場合、余剰幅はそれらの列のパーセンテージ幅に比例して分配される
- そうでなければ、余剰幅はゼロサイズ列に等しく分配される
テスト
3.10. 利用可能な高さの分配
テスト
3.10.1. 表高さの計算
表の高さは、行の高さの合計に任意のセル間隔またはボーダーを加えたものである。
表が auto 以外の値を持つ height
プロパティを持つ場合、それは表グリッドの最小高さとして扱われ、
それらの集合的な最小高さが最終的にこの数値より小さくなる場合、
行の高さへ分配される。
集合的なサイズが指定された height より大きくなる場合、指定された height は効果を持たない。
行の最小高さは次の最大値である:
- 対応する table-row(存在する場合)の算出 height (確定的な場合。パーセンテージは 0px とみなされる)
- 現在の行だけにまたがる各セルの算出 height (確定的な場合。パーセンテージは 0px として扱われる)、および
- その行にまたがるセルにより要求される最小高さ(ROWMIN)。
ROWMIN は、 第 1 行レイアウトパス後の行の最小高さの合計として定義される。
表の高さを計算するには、したがって、 そのすべての行に対して第 1 パスレイアウトを実行し、 すべての最小行高さと間隔/ボーダーの合計を計算し、 その値と table-root に指定された height(min-height)のうち大きい方を返す必要がある。
表高さが決定されると、 行は通常第 2 レイアウトパスを受ける(そのセルの高さはもはや auto とみなされない)。 その後、高さ分配が行われ、行の高さが集合的に表高さを満たすように調整される。 その後、table-cell の子孫は第 2 レイアウトを受ける可能性がある (そのパーセンテージ高さが解決される)。
テスト
- absolute-crash.html (ライブテスト) (ソース)
- absolute-tables-004.html (ライブテスト) (ソース)
- absolute-tables-005.html (ライブテスト) (ソース)
- absolute-tables-007.html (ライブテスト) (ソース)
- empty-table-height.html (ライブテスト) (ソース)
- max-height-table.html (ライブテスト) (ソース)
- min-height-table.html (ライブテスト) (ソース)
- min-height-table-2.html (ライブテスト) (ソース)
- min-max-size-table-content-box.html (ライブ テスト) (ソース)
- table-border-paint-caption-change.html (ライブ テスト) (ソース)
- percentages-grandchildren-quirks-mode-001.html (ライブ テスト) (ソース)
- percentages-grandchildren-quirks-mode-002.html (ライブ テスト) (ソース)
- table-as-item-cell-percentage-001.html (ライブ テスト) (ソース)
- table-as-item-cell-percentage-002.html (ライブ テスト) (ソース)
- table-as-item-cell-percentage-003.html (ライブ テスト) (ソース)
- table-as-item-cell-percentage-004.html (ライブ テスト) (ソース)
- visibility-collapse-non-rowcol-001.html (ライブ テスト) (ソース)
- visibility-collapse-row-001.html (ライブ テスト) (ソース)
- visibility-collapse-row-002-dynamic.html (ライブ テスト) (ソース)
- visibility-collapse-row-003-dynamic.html (ライブ テスト) (ソース)
- visibility-collapse-row-004.html (ライブ テスト) (ソース)
- visibility-collapse-row-005.html (ライブ テスト) (ソース)
- visibility-collapse-row-group-001.html (ライブ テスト) (ソース)
- visibility-collapse-row-group-002.html (ライブ テスト) (ソース)
- visibility-collapse-rowcol-001.html (ライブ テスト) (ソース)
- visibility-collapse-rowcol-002.html (ライブ テスト) (ソース)
- visibility-collapse-rowspan-001.html (ライブ テスト) (ソース)
- visibility-collapse-rowspan-003-border-separate.html (ライブ テスト) (ソース)
- visibility-collapse-rowspan-003.html (ライブ テスト) (ソース)
- visibility-hidden-row-001.html (ライブ テスト) (ソース)
- visibility-hidden-row-002.html (ライブ テスト) (ソース)
3.10.2. 行レイアウト(第 1 パス)
行の最小高さ(スパン関連の高さ分配を含まない)は、 その行から発生するセルを含む仮想 linebox の高さとして定義され、 複数行にまたがるセルは高さ 0px (ただし正しいベースラインを持つ)とみなされる。 この仮想 linebox では、セルの高さは auto とみなされ、 それらの幅(ボーダーと padding を含む)は、またがる列の幅および内側間隔に強制されるが、 その他のプロパティは保持される。
この高さを計算する目的では、 親セルの高さのパーセンテージに依存する高さを持つ表セルの子孫は (下の節を参照)、 overflow が visible、clip、または に設定されている場合、または置換要素である場合、 auto 高さを持つものとみなされ、 そうでない場合は 0px 高さとみなされる。 Testcase !!Testcase
セルのベースラインは、 セル内の最初のフロー内 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>
ベースラインを見つける目的では、 スクロール機構を持つフロー内ボックス (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 である。
曖昧な状況を避けるため、 セルの整列は次の順序で進む:
- まず、ベースラインで揃えられるセルが配置される。 これにより行のベースラインが確立される。
- 次に 'vertical-align: top' を持つセルが配置される。 行はこの時点で上端、場合によってはベースライン、および暫定高さを持つ。 これは上端から、ここまでに配置されたセルの最も低い下端までの距離である。
- 残りのセル、すなわち下端または中央で揃えられるセルのいずれかが、 行の現在の高さより大きい高さを持つ場合、 行の高さは、それらのセルの最大値まで、 下端を下げることで増加される。
- 最後に、残りのセルにその位置を割り当てる。
前述のアルゴリズムが行の各種整列線をどのように作成するかを示す例。
行レイアウト中には、その行内のセルに指定された高さは無視され、 複数の行にまたがるセルは正しくサイズ決定されていないため、 それらの高さは最終的に、それらがまたがる行集合へ分配される必要がある。 これは列測定と同じアルゴリズムを実行することで行われる。 span=1 値は、(min-content について)前の行レイアウトから得られた高さ、 対応する table-row に指定された高さ(存在する場合)、 およびこの行のみにまたがるセルに指定された最大高さのうち最大のもので初期化される (このアルゴリズムは、その割当ての上に span 2 のセルを考慮することから開始する)。
これらの手順を適用した結果としてサイズが増加する行は、 その下端を下げることで調整される。
任意の更新された行の下端に依存していたセルは、 それぞれの行内で再び正しく配置されなければならない。
この時点で、またがる行の集合的な高さより小さいセルボックスは、 追加の上側および/または下側 padding を受け取り、 その内容は垂直方向に移動しないが、 その上端/下端は、それがまたがる最初/最後の行のものと一致する。
テスト
- dynamic-table-cell-height.html (ライブ テスト) (ソース)
- percent-height-overflow-auto-in-restricted-block-size-cell.html (ライブ テスト) (ソース)
- percentage-sizing-of-table-cell-007.html (ライブ テスト) (ソース)
- percentage-sizing-of-table-cell-children-003.html (ライブ テスト) (ソース)
- percentage-sizing-of-table-cell-children-004.html (ライブ テスト) (ソース)
- percentage-sizing-of-table-cell-children-005.html (ライブ テスト) (ソース)
- percentage-sizing-of-table-cell-children-006.html (ライブ テスト) (ソース)
3.10.3. 行レイアウト(第 2 パス)
表高さが決定されると、必要であれば、第 2 行レイアウトパスが実行され、 行/セルに指定された height で使用されるパーセンテージを考慮して、 table rows に正しい最小高さを割り当てる。 それ以外については、第 1 パス行レイアウトのすべての命令が適用される(上を参照)。
次に、この第 2 パス後の table rows の新しい高さの合計が、 以前に決定された表高さを満たすために必要なものと異なる場合、 下で定義される高さ分配アルゴリズムが適用される (行を、第 1 パスの最小高さと第 2 パスの最小高さとの間の中間サイズにして縮小するか、 または利用可能空間を満たすためにすべての行の高さを第 2 パスの最小高さを超えて増加させる。 いずれの場合も、これは行のベースラインには影響しない)。
3.10.4. 中核分配原則
高さ分配に関する調査
3.10.5. 分配アルゴリズム
最初の手順は、各行にその基準サイズと参照サイズを割り当てることである。
その基準サイズは、表に指定高さがなかった場合に その行が得ていたサイズ (ROWMIN が評価されたときに割り当てられたもの)である。
その参照サイズは次の最大値である
- その初期基準高さ、および
- その新しい基準高さ (第 2 レイアウトパス中に評価されたもの。 ここでは rowgroups/rows/cells に指定された高さで使用されるパーセンテージが、 0px として無視される代わりに、表高さに従って解決される)。
第 2 の手順は、それらのサイズに基づいて各行の最終高さを計算することである。
表高さが参照サイズの合計以下である場合、 各行に割り当てられる最終高さは、 正しい合計高さを生じさせる、基準サイズと参照サイズの加重平均になる。
そうでなく、表がいずれかの “auto-height” 行 (サイズがその内容サイズのみにより決定され、指定高さを持たない行)を所有する場合、 各非 auto-height 行はその参照高さを受け取り、 auto-height 行は、その参照サイズに、 指定表高さに達するために不足する高さを そのような行の数で割った増分を加えたものを受け取る。
そうでなければ、すべての行はその参照サイズに、 指定表高さに達するために不足する高さを 行数で割った増分を加えたものを受け取る。
任意の更新された行の下端に依存していたセルは、 それぞれの行内で再び正しく配置されなければならない。
この時点で、またがる行の集合的な高さより小さいセルボックスは、 追加の上側および/または下側 padding を受け取り、 その内容は垂直方向に移動しないが、 その上端/下端は、それがまたがる最初/最後の行のものと一致する。
テスト
- extra-height-given-to-all-row-groups-001.html (ライブ テスト) (ソース)
- extra-height-given-to-all-row-groups-002.html (ライブ テスト) (ソース)
- extra-height-given-to-all-row-groups-003.html (ライブ テスト) (ソース)
- extra-height-given-to-all-row-groups-004.html (ライブ テスト) (ソース)
- extra-height-given-to-all-row-groups-005.html (ライブ テスト) (ソース)
- td-different-subpixel-padding-in-same-row-vertical-rl.html (ライブ テスト) (ソース)
- td-different-subpixel-padding-in-same-row.html (ライブ テスト) (ソース)
3.10.6. 表セル内容レイアウト(第 2 パス)
table-height 分配が完了し、行高さの合計に spacing/border を加えたものが表高さに等しくなると、 第 1 パス行レイアウト規則(上を参照)により パーセンテージ高さが無視された、または 0px として扱われた子孫を含んでいた table-cells の内容は、 下で定義されるように第 2 レイアウトパスを受けなければならない。
table-cell 内容内のパーセンテージ高さを解決する: 表および行の最終サイズが決定され、 高さ分配が完了した後、 table-cells の内容も第 2 レイアウトパスを通過しなければならない。 そこでは、適切な場合、パーセンテージベースの高さは 今回は親セルの使用高さに対して解決される。
table-cell の直接の子に対して パーセンテージ高さを解決することが適切であるのは、セルがその高さを 明示的に指定されているとみなされる場合、 または子が絶対位置指定されている場合である。CSS 2を参照。
互換性上の理由から、さらに次のことを明確化する。 セルの算出高さが長さである場合、 またはその table-root 祖先の算出高さが長さまたはパーセンテージである場合、 そのパーセンテージが auto として振る舞うかどうかに関わらず、 セルはその高さが明示的に指定されているとみなされる。
<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> | |
| <any> | <length> | |
| <any> | <percentage> | |
| auto | auto | |
| <percentage> | auto |
--other-table-cell-height も --wrapper-height も
アルゴリズムの結果に影響しないことに注意。
この仕様の以前のバージョンでは、表がパーセンテージ高さを持つ場合に
--wrapper-height が考慮されると誤って述べていたが、
実装が導入されたときに互換性問題が現れ、その挙動は特別扱いされるようになった。
テスト
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 を含むようにサイズ決定される。
表内における、caption-side が "top" である 任意の table-caption の位置は、次を持つ矩形として定義される:
-
width/height は:
- レイアウト中にキャプションへ割り当てられた width/height
-
top 位置は次の合計:
- 前の top キャプションのために予約された高さ(margin を含む)があればそれ
- 前のキャプションとの margin の相殺後に残る、必要な追加の top margin があればそれ。
-
left 位置は次の合計:
- キャプションの左 margin
- (表幅からキャプション幅とその水平方向 margin の合計を引いたもの)の半分。
表内における任意の table-cell、table-track、または table-track-group ボックスの位置は、 次を持つ矩形として定義される:
-
width/height は次の合計:
- すべてのまたがられる可視列/行の幅/高さ
- 水平方向/垂直方向の border-spacing に、 またがられる可視列/行の数から 1 を引いたものを掛けた値
-
left/top 位置は次の合計:
- top については: top キャプションのために予約された高さ(margin を含む)があればそれ
- 表の padding-left/padding-top および border-left-width/border-top-width
- すべての前の可視列/行の幅/高さ
- 水平方向/垂直方向の border-spacing に、 前の可視 列/行の数に 1 を加えたものを掛けた値
- ある方向の最初のトラックの前、または最後のトラックの後の border-spacing は、 いかなる track または track-group の breadth にも含まれない。
- トラック間の border-spacing は、いかなる track の breadth にも含まれないが、 両方のトラックにまたがる track-groups の breadth には含まれる。
表内における、caption-side が "bottom" である 任意の table-caption の位置は、次を持つ矩形として定義される:
-
width/height は:
- レイアウト中にキャプションへ割り当てられた width/height
-
top 位置は次の合計:
- top キャプションのために予約された高さ(margin を含む)があればそれ
- 表の padding-top および border-top-width
- すべての可視行の高さ
- 表の padding-bottom および border-bottom-width
- 前の bottom キャプションのために予約された高さ(margin を含む)があればそれ
- 前の bottom キャプションとの margin の相殺後に残る、必要な追加の top margin があればそれ。
-
left 位置は次の合計:
- キャプションの左 margin
- (表幅からキャプション幅とその水平方向 margin の合計を引いたもの)の半分。
collapse に設定されていない場合に、
可視
トラックとみなされる。
4. 絶対位置指定
4.1. table-root を包含ブロックとする場合
絶対位置指定された要素の包含 ブロックが table-wrapper ボックスにより生成される場合、 その包含ブロックは、表 margin が適用される領域に対応し、 表ボーダーが描画される領域と、任意の table-caption の margin 領域を含む。 offset プロパティ(top/right/bottom/left)は、 通常どおり、この包含ブロックの対応する辺から内側へのオフセットを示す。
絶対位置指定は、表とそのフロー内内容のレイアウト後に発生し、 いかなる表グリッドトラックのサイズ決定にも寄与せず、 表グリッドのサイズ/構成にいかなる形でも影響しない。
黄色の領域は 表の content edge、黄色の矢印は表の margin である。
緑の領域は表 キャプション、緑の矢印はキャプションの margin である。
青の領域は表の背景領域であり、 より濃い青の領域は表のボーダー領域である。
黒の領域は 表に相対して位置指定された子孫であり、矢印は top/left/bottom/right の変位を表す。
テスト
4.2. table-internal を包含ブロックとする場合
絶対位置指定された要素の包含 ブロックが table-internal により生成される場合、 その包含ブロックは、レイアウト中にそのボックスへ割り当てられるはずの領域の左上隅から始まる領域に対応するが、 そのサイズは、すべてのトラックが可視とみなされた場合の レイアウト中にそのボックスへ割り当てられるはずの領域のサイズとして計算される (一部のボックスで visibility が collapse に設定されているかどうかに関わらない)。 適切に、border と padding は含まれない。
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 である:
- 浮動内容、または
- フロー内内容(white-space プロパティ処理により相殺された空白以外)。
empty-cells:hide を 単純化できるか? [Issue #605]
たとえば、次の markup と css を考える:
< table > < td >< span ></ span ></ td > < td ></ td > < td >< span ></ span ></ td > </ table >
table{ width : 500 px ; height : 300 px ; empty-cells : hide; } table{ background : black; border : 10 px solid black; } td{ background : white; } table{ border-spacing : 0 px ; } td{ padding : 0 ; }
このコード片の正しいレンダリングはここに示される:
5.3. 背景とボーダーの描画
5.3.1. 表の背景とボーダーの描画
他のボックス型とは異なり、table および inline-table ボックスは、 その背景とボーダーを client rect 全体の周囲に描画しない。 実際、表キャプションは表の margin と border の間に視覚的に配置されるため、 table-root に適用される各種効果の描画領域は変更される必要がある。
描画領域:
- table-root の content-box に相対して描画される背景、ボーダー、およびアウトラインは、 表グリッドとその border spacings が占める矩形領域に相対して描画される。
- table-root の padding-box に相対して描画される背景、ボーダー、およびアウトラインは、 表グリッドとその border spacings が占める矩形領域を、各辺で table-root の padding だけ拡張したものに相対して描画される。
- table-root の border-box に相対して描画される背景、ボーダー、およびアウトラインは、 表グリッドとその border spacings が占める矩形領域を、各辺で table-root の padding および border-width だけ拡張したものに相対して描画される。
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. セル背景の描画
自身の background に加えて、table-cell ボックスは、 それが属する table-track および table-track-group ボックスの背景もレンダリングする。 これは単にそれらの背景を継承することとは実際には異なる。 なぜなら、background-origin および background-size の計算は、 セルの bounds ではなく、グループ化ボックスの bounds 上で実際に行われるためである。
各表セルの背景を見つける目的では、 異なる表ボックスは、重ね合わされた 6 つの層上にあるものと考えることができる。 ある層に設定された背景は、 その上の層が透明な背景を持つ場合にのみ見える。
- 表の背景は表によりレンダリングされ、 セル背景には影響しない。
- セルが最初に描画する背景は、その発生元 table-column-group(存在する場合)の背景である。 background-positioning の目的では、 column group は、row/column grid 内で単一セルが占有できる最大の領域を占有することが期待される。 ただし、その column group から発生し、column group の一部ではない列には入らないものとする。
- セルが 2 番目に描画する背景は、その発生元 table-column(存在する場合)の背景である。 background-positioning の目的では、 column は、row/column grid 内で単一セルが占有できる最大の領域を占有することが期待される。 ただし、その column から発生し、他の列には入らないものとする。
- セルが 3 番目に描画する背景は、その発生元 table-row-group(存在する場合)の背景である。 background-positioning の目的では、 row group は、row/column grid 内で単一セルが占有できる最大の領域を占有することが期待される。 ただし、その row group から発生し、row group の一部ではない行には入らないものとする。
- セルが 4 番目に描画する背景は、その発生元 table-row(存在する場合)の背景である。 background-positioning の目的では、 row は、row/column grid 内で単一セルが占有できる最大の領域を占有することが期待される。 ただし、その row から発生し、他の行には入らないものとする。
- セルが 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-group に visibility: collapse が設定されている場合、 与えられた table-track または table-track-group 内のセルによって寄与されるすべての背景、ボーダー、またはアウトラインは、 完全に collapse されていないセル上で描画され続ける (それらが複数のトラックにまたがっていたため)。テスト
- visibility-collapse-colspan-003.html (ライブ テスト) (ソース)
- visibility-collapse-colspan-crash.html (ライブ テスト) (ソース)
- visibility-collapse-rowspan-002-border-separate.html (ライブ テスト) (ソース)
- visibility-collapse-rowspan-002.html (ライブ テスト) (ソース)
- visibility-collapse-rowspan-004-dynamic.html (ライブ テスト) (ソース)
- visibility-collapse-rowspan-005.html (ライブ テスト) (ソース)
- visibility-collapse-rowspan-crash.html (ライブ テスト) (ソース)
6. 断片化
6.1. fragmentainer 間での分割
表を断片化するとき、ユーザーエージェントは、 行にまたがるセルが後続の行にまたがっておらず、かつ その高さが fragmentainer の高さおよび幅の両方の少なくとも半分未満である場合、 表の行を断片化せずに保持しようとしなければならない。 その他の行は自由に断片化可能であると言われる。
表全体が fragmentainer に収まらず、 少なくとも 1 つの行が fragmentainer に完全に収まり、 fragmentainer に収まらない最初の行が自由に断片化可能でない場合、 ユーザーエージェントは、overflow 点の前およびその位置にある行の間に いくらかの垂直方向の間隔を挿入し、 その 2 つの行が兄弟 fragmentainer 内で分離されるようにしなければならない。 断片化によりヘッダーとフッターの反復が必要で、フッターが反復される場合、 そのフッターは fragmentainer 内の最後の行の直後に来なければならず、 垂直方向の間隔は、反復されたフッターの後に挿入されなければならない。
現在の fragmentainer に完全に収まる行がない場合、 または fragmentainer に収まらない最初の行が自由に断片化可能である場合、 ユーザーエージェントは、fragmentainer 内の残りの高さをすべてその行のセルに割り当て、 各セル内で可能な限り多くの内容を独立に収め、 次の断片へ分割し、各セルの内容を前の断片で停止した位置から開始しなければならない (継続断片では上ボーダーを再描画してはならない)。
break-before または break-after が table-row-group または table-row ボックスに適用される場合、 ユーザーエージェントは、分割点の前および後にある行の間に いくらかの垂直方向の間隔を挿入し、 プロパティ値により要求されるとおり、 その 2 つの行が兄弟 fragmentainer 内で分離されるようにしなければならない。 断片化によりヘッダーとフッターの反復が必要で、フッターが反復される場合、 そのフッターは fragmentainer 内の最後の行の直後に来なければならず、 垂直方向の間隔は、反復されたフッターの後に挿入されなければならない。
6.2. ページ間でのヘッダーの反復
文書をページ付きメディアへレンダリングする場合、 ページが表の fragmentainer であり、 header/footer に avoid の break-inside が適用されており、 そのために必要な高さがページ高さの 2 四分の 1 未満 (ヘッダー行については最大 1 四分の 1、 フッター行については最大 1 四分の 1)であり、 かつ、それによりそのページ上で行が 2 回表示されることがない場合、 ユーザーエージェントは、表がまたがる各ページ上で ヘッダー行および フッター行を反復しなければならない。
ヘッダー行が反復されるとき、ユーザーエージェントは 空間を残し、必要であれば表の上ボーダーをレンダリングしなければならない。 同じことがフッター行および表の下ボーダーにも適用される。
ユーザーエージェントは、この挙動をより多くの断片化コンテキストへ拡張することを決定してもよい。 たとえば、ページに加えて列間でもヘッダー/行を反復するなどである。 静的文書をレンダリングするユーザーエージェントは、この挙動を採用する可能性が高いが、 これは仕様上要求されるものではない。
7. セキュリティに関する考慮事項
CSS Tables を使用しても、軽減すべきセキュリティリスクは生じない。
8. プライバシーに関する考慮事項
CSS Tables を使用しても、軽減すべきプライバシーリスクは生じない。
9. 追跡中のバグ一覧
この節は規範的ではない。
10. 付録
10.1. CSS 属性と HTML 属性の対応付け
HTML4 の既定スタイルシートは、そのモデルが 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 : 2 px ; border-collapse : separate; text-indent : initial; } thead, tbody, tfoot, table > tr{ vertical-align : middle; } tr, td, th{ vertical-align : inherit; } td, th{ padding : 1 px ; } 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 : 1 px 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)*/ outsetrgb ( 128 , 128 , 128 ); } table[ border=$border] >:is ( thead, tbody, tfoot) > tr >:is ( th, td) /* if(parseInt($border) > 0) */ { border : 1 px insetrgb ( 128 , 128 , 128 ); } table[ rules=all i] >:is ( thead, tbody, tfoot) > tr >:is ( th, td) { border : 1 px solid grey; } table[ rules=rows i] >:is ( thead, tbody, tfoot) > tr >:is ( th, td) { border : 1 px solid grey; border-left : none; border-right : none; } table[ rules=cols i] >:is ( thead, tbody, tfoot) > tr >:is ( th, td) { border : 1 px 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 : 1 px ; border-top-style : solid; border-bottom-width : 1 px ; border-bottom-style : solid; } table[ rules=groups i] > colgroup{ border-left-width : 1 px ; border-left-style : solid; border-right-width : 1 px ; 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; }
テスト
11. (欠落している節へのリンク)
12. 変更点
2019年7月27日付 Working Draft 以降の重要な変更:
- paged media および continuous media という用語を [MEDIAQUERIES-5] から参照した。
- :matches() 疑似クラスへの言及を :is() に置き換えた。
- 外側の表要素がその外側 display 型に従って振る舞うことを明確化した。
- clip を table-root および table-wrapper ボックスへ適用できるようにした。
- Web Platform Test のカバレッジを追加した。