Difference between known_dimensions and available_space in measure functions

[ennis]

I'm not entirely sure what is the difference between the two. In the cosmic_text example (text_context.measure), if the width is known then the behavior is the same as a definite available width. In this case, why have two different parameters instead of just setting available_space.width to Definite(width)?
Other questions:

• is it possible to receive a Definite available space with different known_dimensions? (e.g. available_space.width = Definite(500) and known_dimensions.width = 200)
• when available_space.width == MaxContent, is it possible to also receive a known size (known_dimensions.width != None)? In which case which value should the node consider for layout?

[nicoburns]

Broadly:

• The available_space is the size of the "containing block" (roughly, the parent node) (closely related to the parent_size, but sometimes the available_space is set to MinContent or MaxContent as part of a multi-pass layout algorithm even if the size of parent is actually known. It's best to think of available_space as a constraint that asks: "If you had this much space, then what size would you be?".
• The known_dimensions are the size of the node itself. And indeed, if the known_dimension in a particular axis is set then you can generally (always I think) ignore the available_space in that axis. The purpose of known_dimensions is to allow the algorithm to ask "If your size in this dimension is exactly X, then what would you size in the other dimension be".

TL;DR: known_dimensions takes precedence over available_space.

P.S. known_dimensions is a hard constraint. If known_dimensions is set in an axis, then the output size in that axis will be ignored entirely and only the output size in the other axis used.
P.P.S. It may well be possible to combine them into a single enum at somepoint. In which case known_dimensions: Some(_) would become something like an AvailableSpace::Exact(_) variant.

[ennis]

Thanks! This clarified things for me.