mirror of
https://github.com/servo/servo.git
synced 2025-08-04 21:20:23 +01:00
layout: Add documentation about table layout (#31535)
Co-authored-by: Oriol Brufau <obrufau@igalia.com>
This commit is contained in:
parent
dd6c929cc6
commit
7e8a1503ba
2 changed files with 61 additions and 6 deletions
|
@ -73,7 +73,7 @@ struct ColumnLayout {
|
||||||
/// A helper struct that performs the layout of the box tree version
|
/// A helper struct that performs the layout of the box tree version
|
||||||
/// of a table into the fragment tree version. This implements
|
/// of a table into the fragment tree version. This implements
|
||||||
/// <https://drafts.csswg.org/css-tables/#table-layout-algorithm>
|
/// <https://drafts.csswg.org/css-tables/#table-layout-algorithm>
|
||||||
struct TableLayout<'a> {
|
pub(crate) struct TableLayout<'a> {
|
||||||
table: &'a Table,
|
table: &'a Table,
|
||||||
pbm: PaddingBorderMargin,
|
pbm: PaddingBorderMargin,
|
||||||
rows: Vec<RowLayout>,
|
rows: Vec<RowLayout>,
|
||||||
|
|
|
@ -2,12 +2,67 @@
|
||||||
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
||||||
* file, You can obtain one at https://mozilla.org/MPL/2.0/. */
|
* file, You can obtain one at https://mozilla.org/MPL/2.0/. */
|
||||||
|
|
||||||
//! HTML Tables (╯°□°)╯︵ ┻━┻.
|
//! # HTML Tables (╯°□°)╯︵ ┻━┻
|
||||||
//!
|
//!
|
||||||
//! See <https://html.spec.whatwg.org/multipage/table-processing-model> and
|
//! This implementation is based on the [table section of the HTML 5 Specification][1],
|
||||||
//! <https://drafts.csswg.org/css-tables>. This is heavily based on the latter specification, but
|
//! the draft [CSS Table Module Level! 3][2] and the [LayoutNG implementation of tables][3] in Blink.
|
||||||
//! note that it is still an Editor's Draft, so there is no guarantee that what is implemented here
|
//! In general, the draft specification differs greatly from what other browsers do, so we
|
||||||
//! matches other browsers or the current specification.
|
//! generally follow LayoutNG when in question.
|
||||||
|
//!
|
||||||
|
//! [1]: https://html.spec.whatwg.org/multipage/#tables
|
||||||
|
//! [2]: https://drafts.csswg.org/css-tables
|
||||||
|
//! [3]: https://source.chromium.org/chromium/chromium/src/third_party/+/main:blink/renderer/core/layout/table
|
||||||
|
//!
|
||||||
|
//! Table layout is divided into two phases:
|
||||||
|
//!
|
||||||
|
//! 1. Box Tree Construction
|
||||||
|
//! 2. Fragment Tree Construction
|
||||||
|
//!
|
||||||
|
//! ## Box Tree Construction
|
||||||
|
//!
|
||||||
|
//! During box tree construction, table layout (`construct.rs`) will traverse the DOM and construct
|
||||||
|
//! the basic box tree representation of a table, using the structs defined in this file ([`Table`],
|
||||||
|
//! [`TableTrackGroup`], [`TableTrack`], etc). When processing the DOM, elements are handled
|
||||||
|
//! differently depending on their `display` value. For instance, an element with `display:
|
||||||
|
//! table-cell` is treated as a table cell. HTML table elements like `<table>` and `<td>` are
|
||||||
|
//! assigned the corresponding display value from the user agent stylesheet.
|
||||||
|
//!
|
||||||
|
//! Every [`Table`] holds an array of [`TableSlot`]. A [`TableSlot`] represents either a cell, a cell
|
||||||
|
//! location occupied by a cell originating from another place in the table, or is empty. In
|
||||||
|
//! addition, when there are table model errors, a slot may spanned by more than one cell.
|
||||||
|
//!
|
||||||
|
//! During processing, the box tree construction agorithm will also fix up table structure, for
|
||||||
|
//! instance, creating anonymous rows for lone table cells and putting non-table content into
|
||||||
|
//! anonymous cells. In addition, flow layout will collect table elements outside of tables and create
|
||||||
|
//! anonymous tables for them.
|
||||||
|
//!
|
||||||
|
//! After processing, box tree construction does a fix up pass on tables, converting rowspan=0 into
|
||||||
|
//! definite rowspan values and making sure that rowspan and celspan values are not larger than the
|
||||||
|
//! table itself. Finally, row groups may be reordered to enforce the fact that the first `<thead>`
|
||||||
|
//! comes before `<tbody>` which comes before the first `<tfoot>`.
|
||||||
|
//!
|
||||||
|
//! ## Fragment Tree Construction
|
||||||
|
//!
|
||||||
|
//! Fragment tree construction involves calculating the size and positioning of all table elements,
|
||||||
|
//! given their style, content, and cell and row spans. This happens both during intrinsic inline
|
||||||
|
//! size computation as well as layout into Fragments. In both of these cases, measurement and
|
||||||
|
//! layout is done by [`layout::TableLayout`], though for intrinsic size computation only a partial
|
||||||
|
//! layout is done.
|
||||||
|
//!
|
||||||
|
//! In general, we follow the following steps when laying out table content:
|
||||||
|
//!
|
||||||
|
//! 1. Compute track constrainedness and has originating cells
|
||||||
|
//! 2. Compute cell measures
|
||||||
|
//! 3. Compute column measures
|
||||||
|
//! 4. Compute intrinsic inline sizes for columns and the table
|
||||||
|
//! 5. Compute the final table inline size
|
||||||
|
//! 6. Distribute size to columns
|
||||||
|
//! 7. Do first pass cell layout
|
||||||
|
//! 8. Do row layout
|
||||||
|
//! 9. Compute table height and final row sizes
|
||||||
|
//! 10. Create fragments for table elements (columns, column groups, rows, row groups, cells)
|
||||||
|
//!
|
||||||
|
//! For intrinsic size computation this process stops at step 4.
|
||||||
|
|
||||||
mod construct;
|
mod construct;
|
||||||
mod layout;
|
mod layout;
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue