Module inline

Source
Expand description

§Inline Formatting Context Layout

Inline layout is divided into three phases:

  1. Box Tree Construction
  2. Box to Line Layout
  3. Line to Fragment Layout

The first phase happens during normal box tree constrution, while the second two phases happen during fragment tree construction (sometimes called just “layout”).

§Box Tree Construction

During box tree construction, DOM elements are transformed into a box tree. This phase collects all of the inline boxes, text, atomic inline elements (boxes with display: inline-block or display: inline-table as well as things like images and canvas), absolutely positioned blocks, and floated blocks.

During the last part of this phase, whitespace is collapsed and text is segmented into TextRuns based on script, chosen font, and line breaking opportunities. In addition, default fonts are selected for every inline box. Each segment of text is shaped using HarfBuzz and turned into a series of glyphs, which all have a size and a position relative to the origin of the TextRun (calculated in later phases).

The code for this phase is mainly in construct.rs, but text handling can also be found in text_runs.rs.

§Box to Line Layout

During the first phase of fragment tree construction, box tree items are laid out into LineItems and fragmented based on line boundaries. This is where line breaking happens. This part of layout fragments boxes and their contents across multiple lines while positioning floats and making sure non-floated contents flow around them. In addition, all atomic elements are laid out, which may descend into their respective trees and create fragments. Finally, absolutely positioned content is collected in order to later hoist it to the containing block for absolutes.

Note that during this phase, layout does not know the final block position of content. Only during line to fragment layout, are the final block positions calculated based on the line’s final content and its vertical alignment. Instead, positions and line heights are calculated relative to the line’s final baseline which will be determined in the final phase.

LineItems represent a particular set of content on a line. Currently this is represented by a linear series of items that describe the line’s hierarchy of inline boxes and content. The item types are:

The code for this can be found by looking for methods of the form layout_into_line_item().

§Line to Fragment Layout

During the second phase of fragment tree construction, the final block position of LineItems is calculated and they are converted into Fragments. After layout, the LineItems are discarded and the new fragments are incorporated into the fragment tree. The final static position of absolutely positioned content is calculated and it is hoisted to its containing block via PositioningContext.

The code for this phase, can mainly be found in line.rs.

Modules§

construct
inline_box
line
line_breaker 🔒
text_run

Structs§

BaselineRelativeSize 🔒
A block size relative to a line’s final baseline. This is to track the size contribution of a particular element of a line above and below the baseline. These sizes can be combined with other baseline relative sizes before the final baseline position is known. The values here are relative to the overall line’s baseline and not the nested baseline of an inline box.
ContentSizesComputation 🔒
A struct which takes care of computing ContentSizes for an InlineFormattingContext.
FontKeyAndMetrics 🔒
A collection of data used to cache FontMetrics in the InlineFormattingContext
InlineContainerState 🔒
InlineContainerStateFlags
InlineFormattingContext 🔒
InlineFormattingContextLayout 🔒
LineBlockSizes 🔒
LineUnderConstruction 🔒
Information about the current line under construction for a particular InlineFormattingContextLayout. This tracks position and size information while LineItems are collected and is used as input when those LineItems are converted into Fragments during the final phase of line layout. Note that this does not store the LineItems themselves, as they are stored as part of the nesting state in the InlineFormattingContextLayout.
SegmentContentFlags
SharedInlineStyles 🔒
TextRun and TextFragments need a handle on their parent inline box (or inline formatting context root)’s style. In order to implement incremental layout, these are wrapped in SharedStyle. This allows updating the parent box tree element without updating every single descendant box tree node and fragment.
UnbreakableSegmentUnderConstruction 🔒
The current unbreakable segment under construction for an inline formatting context. Items accumulate here until we reach a soft line break opportunity during processing of inline content or we reach the end of the formatting context.

Enums§

InlineItem 🔒

Statics§

FONT_SUBSCRIPT_OFFSET_RATIO 🔒
FONT_SUPERSCRIPT_OFFSET_RATIO 🔒

Functions§

char_prevents_soft_wrap_opportunity_when_before_or_after_atomic 🔒
Whether or not this character will rpevent a soft wrap opportunity when it comes before or after an atomic inline element.
effective_vertical_align 🔒
inline_container_needs_strut 🔒
Whether or not a strut should be created for an inline container. Normally all inline containers get struts. In quirks mode this isn’t always the case though.
is_baseline_relative 🔒
line_height 🔒
place_pending_floats 🔒