[css-line-grid][css-rhythm] solve the leading adjustment problem of the line-grid

[frivoal]

Line grid has an problem, alluded to in the Leading adjustments section.

If mixed fonts are used either explicitly or through fallbacks and some of the fonts are larger that then default font on the element, or are no larger but have a different baseline position, lines will be double spaced, even if visually it looks like there is plenty of room. The same problem may occur when if <sub> or <sup> are used.

If there was an allowed margin of error by which things are allowed to stick out before causing the line box to be shifted down, we could avoid this problem, but it isn't clear what that margin should be. I think that combining line-height-step with the line grid may be a way to solve that.

Reusing the terminology I proposed in #940, the difference between the natural line box and the adjusted line box could be this margin of error.

Here are a handful of proposals about how this might work:

1. "Independent but complementary"

• Define line-grid:create to make a line grid based on the size of the line-box as adjusted by line-height-step ([css-rhythm][css-line-grid] Work out the interaction between line-height-step and line-grid #939)
• Change the definition of line-height-step so that when it is used with line-snap, the position of the baseline in the adjusted line box is set just right to avoid creating gaps ([css-rhythm][css-line-grid] Work out the interaction between line-height-step and line-snap #940)

2. The short-hand approach
   Same as (1), plus make line-height-step a longhand of line-grid and redefine line-grid as
   create <line-height-step>? | match-parent

3. The auto approach
   Same as (1), plus redefine line-grid to
   create <length>? | match-parent
   and line-height-step to auto | <length>, with line-height-step:auto getting its value from the <length> param of line-grid.

4. The "just the line grid" approach
   redefine line-grid to
   create <length>? | match-parent
   and use the extra parameter to give some breathing room to the line box, without invoking step-sizing.

1, 2 and 3 are sort of the same, but they cascade differently (and 2&3 should be identical if the author doesn't specify the line-height-step property). It is not entirely obvious to me if the fact that (unlike line-grid) line-height-step is inherited was a useful thing or a footgun. It case it is not a useful thing, solution 4 deals with the line-grid problem without getting the potential footgun.

Yet an other alternative is to make line-height-step non inherited, in which case 2/3/4 become much more similar to eachother (i.e. identical if the author doesn't specify the line-height-step property).

[liamquin]

On Mon, 2017-01-16 at 02:05 -0800, Florian Rivoal wrote: Line grid has an problem, alluded to in the [Leading adjustments](htt ps://drafts.csswg.org/css-line-grid/#leading-adjustments) section. If mixed fonts are used either explicitly or through fallbacks and some of the fonts are larger that then default font on the element, or are no larger but have a different baseline position, lines will be double spaced, even if visually it looks like there is plenty of room. The same problem may occur when if `<sub>` or `<sup>` are used.

Traditionally there are three approaches to this issue. (1) leave one or more blank lines when necessary (2) allow superscripts and subscripts to intrude (and possibly overlap     unreadably, depending on how smart the formatter is) (3) break the grid Which of these to use depends on the subject mater and context. Although overlapping super/subscripts is almost never dseirable outside of "zalgo"-like effects, if superscripts are for references to footnotes and subscripts are very infrequent, (2) is often the best compromise. The dangers of leaving blank lines are (a) that readers get confused thinking it's the start of a new paragraph or section (mitigation: use indenting and/or initial capitals at the start of paragraphs and sections where there's no heading), and (b) that readers think there's a line of data missing, e.g. in a table of numbers with very infrequent superscripts, or lists of names where a glyph might be substituted from a different font for an accented upper-case letter, say. So, ...

If there was an allowed margin of error by which things are allowed to stick out before causing the line box to be shifted down, we could avoid this problem, but it isn't clear what that margin should be.

Yes, this is the case (2) approach. There's nothing you can do to prevent an inline box from being greater than the line height in general (e.g. an image, an inline table, a superscript to a superscript to a superscript...) so you still have to cope with the case where the "margin of error" is exceeded - (1) leave a gap, or (3) break the grid and set a line on a non-grid baseline, or both. Usually (3) produces the most even colour to the page and is the best compromise in those cases. So there's two values - (1) maximum protrusion allowed, and (2) what to do when it's exceeded. Note that if the previous formatted line has no descenders or superscripts, there's more room available for stickupness, but this information may or may not be available to a formatter. Liam

[frivoal]

Traditionally there are three approaches to this issue. (1) leave one or more blank lines when necessary (2) allow superscripts and subscripts to intrude (and possibly overlap unreadably, depending on how smart the formatter is) (3) break the grid
[...]
So there's two values - (1) maximum protrusion allowed, and (2) what to do when it's exceeded.

Correct. As things are currently defined, if you want to break the grid, you should use line-height-step alone, and if you want to leave one or more blank lines you use line-grid + css-line-snap. line-height-step comes with a way of defining the maximum protrusion allowed, but line grid does not. I am proposing that it could gain this capability through integration with line-height-step (proposals 1 to 3 in my original comment), or failing that, that it should independently gain the ability to manually specify that maximum protrusion allowed (proposal 4).

[kojiishi]

Can you elaborate what the problem is? I read the "Leading adjustments" section but I don't understand what cases it is talking about, and it says "details to follow".

When fonts are larger, or sup/sub are used, and its result exceeds one grid, I do want line grid to double the space. It reads to me that you want to suppress that in some cases?