[css-inline-3] Tight vs loose fit into a line box

In today's discussion about how to decide whether content fits, we talked a bit about the models we use for fit. Mostly we focused on the question of “what do we consider to be the size of the inline” when deciding whether it fits, but the other question is what do we consider to be the “container” representing the line box?

Currently we have two models for the height of container:

• A) root inline including half-leading (the minimum height of this line box)
• B) root inline including full leading on both sides (basically, pretending there's an equivalent line box both above and below this line, and that nothing is in their leading areas)

For an illustration of this, see slide 52 here.

The idea for sizing a line box is, if an item sticks outside of that bounds, it doesn't fit, and we increase the size of the line box to make it fit.

In general, CSS uses model A. This guarantees that there will be no overflow, no overlap of content unless the author specifically indicated the desire for that effect through negative margins or negative leading.

However, for ruby annotations, we use model B. This is a bit risky, but as long as the text is fairly consistently sized and there is only ruby on one side (and the start of the block has enough margin or padding), it works. We increase the height of the line if the author didn't provide sufficient line gaps (which is advantageous in certain typographic environments) but when they do, the ruby fits within that gap.

The question came up, if the effects of slicing down the size of ascent/descent inline down to internal metrics isn't sufficient to get the desired typographical fits, we might consider a more general switch for model B.

I guess the open question is, do we want that, and if so, what does that look like syntactically-speaking?

Start with the discussion linked in the issue and the line-box models illustrated on slide 52 of the referenced presentation. Clarify whether model B should be generalized and what syntax would express it; the issue is done when that design question has a resolved specification direction.