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

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

From: Liam Quin via GitHub <sysbot+gh@w3.org>
Date: Thu, 19 Jan 2017 18:16:19 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-273854346-1484849778-sysbot+gh@w3.org>
On Mon, 2017-01-16 at 02:05 -0800, Florian Rivoal wrote:
> Line grid has an problem, alluded to in the [Leading 
> 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 

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 
of "zalgo"-like effects, if superscripts are for references to
footnotes and subscripts are very infrequent, (2) is often the best

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 
superscripts, or lists of names where a glyph might be substituted 
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 
> 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 
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.


GitHub Notification of comment by liamquin
Please view or discuss this issue at 
using your GitHub account
Received on Thursday, 19 January 2017 18:16:26 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:07 UTC