W3C home > Mailing lists > Public > public-css-archive@w3.org > January 2017

[csswg-drafts] [css-line-grid][css-rhythm] solve the leading adjustement problem of the line-grid

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Mon, 16 Jan 2017 10:05:49 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-200976488-1484561148-sysbot+gh@w3.org>
frivoal has just created a new issue for 
https://github.com/w3c/csswg-drafts:

== [css-line-grid][css-rhythm] solve the leading adjustement problem 
of the line-grid ==
Line grid has an problem, alluded to in the [Leading 
adjustments](https://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.

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`](https://drafts.csswg.org/css-rhythm/#line-height-step)
 with the line grid may be a way to solve that.

Reusing the terminology I proposed in 
https://github.com/w3c/csswg-drafts/issues/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` (#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 (#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`).

Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/941 using your GitHub 
account
Received on Monday, 16 January 2017 10:05:59 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:26:37 UTC