- From: Liam Quin via GitHub <sysbot+gh@w3.org>
- Date: Thu, 19 Jan 2017 18:16:19 +0000
- To: public-css-archive@w3.org
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 -- GitHub Notification of comment by liamquin Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/941#issuecomment-273854346 using your GitHub account
Received on Thursday, 19 January 2017 18:16:26 UTC