Open fantasai opened 4 years ago
I went back and looked at the case of an ordinary superscript in text. Even with text-edge: text
or text-edge: cap
it seems like the sup
box intrudes into the half-leading of the previous line. I think you'd have to set text-edge: ex
to get the effect in the illustration?
Yellow = ascent/descent bounds for superscript Green = top/bottom half-leading for superscript Blue = top/bottom half-leading for regular text Ascent and cap height metrics for superscript are in red (data is from Adobe Caslon Pro)
Cap height and ex height are shown in red in the diagram (info is from Adobe Caslon Pro).
The CSS Working Group just discussed tight vs loose fit into a line box
.
I was playing around to figure out which properties on the superscript element could currently be used to allow a superscript/subscript to extend outside the line box. Negative margin-top
doesn't seem to work, but line-height: 0
does (or some fraction less than one that cancels out the overlap region).
Just in case anyone is looking for a workaround until we come up with a proper solution…
dauwhe: I'd be willing to take the risk of some ink overlap to preserve the regularity of my line spacing ... in the case shown here I wouldn't have many problems unless stuff goes over the font descent ... if you know the font you're using then it seems worth the risk
...
fantasai: I'm fine with collisions as long as authors are explicit, and the new line layout model allows that via negative margin
We've had a go at implementing text-edge
as it's currently specified and I'm not sure that negative margin is going to solve this.
I've put an example at https://jsbin.com/lecudab/edit?html,output. The way this renders with text-edge: ex
is:
I chose ex
as it makes the least contribution to the linebox of all the values currently specified, but even this value pushes the linebox out to the text-bottom edge. The vertical rhythm is still going to be broken with a subscript.
As suggested, I then put a negative margin on the super/subscript - it feels a little awkward as I must also set text-edge
to something other than the default of leading
to make it apply, even though it's not the "ex" baseline I'm aiming for:
sub {
text-edge: ex;
margin-bottom: -1em
}
This made no difference: the margin is applied to the sub
but not the replaced content within it, which still contributes to the line-height (although I'm prepared for the reply "you're misinterpreting https://drafts.csswg.org/css-inline-3/#inline-height" on this point).
Even assuming it does apply, I'd chosen an arbitrary "-1em" to try and ensure the margin disappears above the main alphabetic baseline, but with text-edge: ex
this pushes the layout bounds under-edge above the over-edge for the subscripted text. The best I can do here istext-edge: ex alphabetic; margin-bottom: -1ex
to set the under and over edge of the subscripted text to the "ex" baseline.
But where even the "ex" baseline is outside the default bounds of the line-box (say for very large baseline-shifts, or nested super/subscripts) I'd have to further adjust both the top and bottom margins to ensure they're still within the default bounds of the line box and prevent them from changing the rhythm. It's starting to get very complicated at this point and not at all intuitive.
If all I want is to preserve line rhythm at all costs and in all cases, a value like text-edge: none
which means "do not contribute at all to the line height" for this would be a lot simpler.
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:
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?