Skip to content

Comments

Improve baseline support across all widgets.#1671

Open
xStrom wants to merge 2 commits intolinebender:mainfrom
xStrom:baselines
Open

Improve baseline support across all widgets.#1671
xStrom wants to merge 2 commits intolinebender:mainfrom
xStrom:baselines

Conversation

@xStrom
Copy link
Member

@xStrom xStrom commented Feb 20, 2026

The existing baseline support was half-baked to say the least. None of the actual text baselines were ever even piped through!

This PR makes baseline alignment an actual thing for the existing widget set.

  • Instead of a single baseline there are now two baselines, called first baseline and last baseline. This follows CSS and provides useful opportunities to align multi-line text based on the last line, not just the first line.
  • Flex and Grid received CSS spec based baseline implementations. Flex got it both for child baseline alignment and its own baseline deriving, while for Grid I currently only implemented its own baseline deriving. Grid child baseline alignment remains as future work.
  • Changed the baseline bookkeeping to be defined as distance from the top of the widget not from the bottom. This more naturally matches what Parley gives us and how Masonry widgets do layout. For example the Label widget always paints the text starting from the top of the widget. So the baseline it reported (from the top) will match what it paints. This would not be true with a bottom-relative baseline if the Label gets assigned a fractional height that later gets pixel snapped. Our current pixel snapping strategy has no effect on distances from the top of the widget, but changes distances from the bottom.
  • Previously all container widgets had to do fragile manual math to derive their baseline from their child. Indeed, this was wrong for all widgets until very recently. This PR improves this situation even more by introducing a widely applicable helper method LayoutCtx::derive_baselines(child).
  • For more complex multi-child cases there are new methods LayoutCtx::child_origin and LayoutCtx::child_aligned_baselines that enable deriving the correct pixel-snapped baseline position. These are basically what derive_baselines uses under the hood.
  • For aligning children according to their baselines there's LayoutCtx::child_layout_baselines which returns the non-snapped baselines. This approach is actually flawed as evidenced by the new (currently incorrectly behaving) test flex_row_baseline_pixel_snapping. There are many potential solutions and none of them trivial, so I've decided to postpone solving it. In the meantime the alignment will semi-work, just not pixel perfect. This is also why I removed the old baseline pixel snapping. That was alignment theater because that rounding had zero effect on any actual drawing. Anyway, this is a deep rabbit hole so I'd like to avoid going deep into it in the context of this PR.
  • For Flex columns CrossAxisAlignment::Baseline was previously defined as Center. Now with FirstBaseline and LastBaseline I changed the fallback to Start and End which matches CSS, at least in most writing modes and certainly in horizontal-tb which is the only one Masonry currently supports.
  • Some widgets had debug mode baseline drawing. I moved that into core, so that all widgets now paint their explicit baselines in debug mode (F12). Implicit border-box bottom edge baselines are not painted to avoid noise.
  • The gallery transforms page got a slight update in the form of a multi-line label. This can be used to quickly verify with F12 that the baseline debug painting also draws last baselines.
  • In WidgetState I use f64::NAN to mean None i.e. no explicit baseline. That's because we have an ever growing size issue with that struct and using actual Option<f64> twice would mean an extra 16 bytes per widget which we can easily avoid with NAN. There are accessor methods for doing proper reading. I could also add setter methods and make the fields private if need be.

@xStrom xStrom added masonry Issues relating to the Masonry widget layer needs review Needs review before proceeding. labels Feb 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

masonry Issues relating to the Masonry widget layer needs review Needs review before proceeding.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant