csswg-drafts 🚀 - [css-rhythm-1] Avoiding accidental double spacing

I understand the motivation, but I'm not a big fan of adding more automatic magic behaviors.

line-height: normal causing different layout by browsers/platforms are already widely known facts. Most recent reset.css has line-height: 1. Fixing it automatically only when line-height-step is set looks like we're recommending not to to set line-height. We're not, correct?

Also, the problem you state isn't limited to line-height. What if author forgot to set font-size? If the font-size is larger than a test device, it may result in two units, but we can't fix it, correct?

I have a mid preference to let authors to deal with their errors, and minimize the magic behaviors in the platform.

kojiishi on 23 Jan 2017

line-height:normal being a little different depending on the browser is not a major problem when step sizing is not involved, because the differences are subtle. In this case, the differences could be large (some browsers/os/fonts combinations getting double spaced, some other not), and the fix seems easy.

When the problems are obvious and the solutions hard, leaving things up to authors is fine. Here it's not the case.

frivoal on 25 Jan 2017

If we make behavior dependent on whether or not line-height-step is initial, the initial value needs to be none.

If we want font-based line heights to be possible to use with step-sizing, we need to add a normal keyword (that computes to its absolute length) to line-height step

fantasai on 25 Jan 2017

If we want font-based line heights to be possible to use with step-sizing, we need to add a normal keyword (that computes to its absolute length) to line-height step

Can you clarify how author can do:

line-height: normal;
line-height-step: 18px;

that was what I wanted to ask but probably failed, sorry about that.

kojiishi on 25 Jan 2017

If we make behavior dependent on whether or not line-height-step is initial, the initial value needs to be none.

I'm fine to add none if desired.

kojiishi on 25 Jan 2017

Added i18n label because this proposal will cause lines to overlap for some scripts.

kojiishi on 25 Jan 2017

Since I wasn't able to express my points very well in the weekly conf call, let me continue my points here by cc'ing people who spoke at the weekly on 25 Jan, from IRC log:
@astearns @stevezilles @tantek @tabatkins @dbaron @fantasai @dauwhe @litherum @FremyCompany
There were some points what I said didn't seem to be understood correctly, or I didn't understand even by reading IRC log, so appreciate to read through and comment here if any.

line-height: normal doesn't produce a robust layout as discussed, and I agree that a robust layout is one of important principle in CSS, and that line-height: normal is against that.

The purpose of line-height: normal is different; it is designed to avoid line overlaps as much as possible. Making any text readable without unexpected overlaps is also one of important principles in CSS. These two important principles conflict to each other. I think that is why line-height gives a choice to authors, and I think CSS chose the right default because overlapping is worse problem.

What I was trying to say at the weekly was that we need to give the choice to authors regardless rhythmic sizing is used or not, and IIUC this is also what @litherum was trying to say.

I made a multi-script sample text here (credits to @r12a and @aphillips, thank you!) For scripts in this example, I hope you see normal works perfectly in all browsers, but if we were to pick one fixed value, probably "1.8" is a good value. But I saw an example where "1.8" wasn't still tall enough before. Pick "2"? But it's too tall for some other scripts, such as Latin.

Or, maybe, I wonder, from @fantasai's comment above, this point was understood but cases where font metrics-based line height and rhythmic sizing used together was not understood?

If that's the case, I'm quite sure this case is common; author wants a constant rhythm, such as 18pt. The page has CGM that text can be in various scripts. Author wants to prioritize "lines not to overlap" over "possible additional space when falls back to bad fonts occurs," because font fallback is more predictable than CGM text content. In this case, the combination of normal and rhythmic sizing is what the author needs.

If the author uses line-height: normal, Latin lines will fit to one step unit, while Tibetan may fit to two or three step units, but still the rhythm is kept.

...or maybe concerns discussed there was different from either of above, appreciate if someone can explain more if so.

kojiishi on 26 Jan 2017

Talked with @tabatkins offline, he said he might try to come up with a new proposal, so I look forward to seeing it.

He also said it became clearer after we talked, so I guess I didn't do good job in conf call or comments above. Sorry about that, let me try to simplify the points.

I understand the interop problem with line-height: normal.
I understand there are cases where rhythmic sizing may make the issue (1) worse.
I believe this proposal sacrifices a CSS readability feature for tall scripts.
I think this proposal is net negative, given (3) looks more critical than (1) to me.
I mildly prefer solving the original issue (1) altogether, not only the worse one (2).

Happy to discuss more if anyone can come up with new proposals, or disagree with me on 3-5.

kojiishi on 4 Feb 2017

Blink is considering shipping line-height-step. Please let us know if there's a specific proposal here for changes which could cause a web compat problem in the future if we were to ship now. If approved, line-height-step support could make it to Chrome stable as early as June, so we'd still have a few months to safely make breaking changes or pull the feature if consensus can be reached.

RByers on 5 Apr 2017

Alright, I think I have a solution that lets line-height:normal fulfill its purpose and solves the double spacing problem we've been discussing.

Hypothesis:

line-height:normal needs to be left alone, for the reasons Koji said
When setting the line-heigh-step, you (almost?) never want to set it to something smaller than the line height of the element that establishes the rhythm.
When inheriting line-height-step, you do want it to be able to be smaller than the line height of the element it is inheriting into. That is what enables things like titles to be enlarged to a multiple of the step size.

Proposal:
line-height-step: none | [ <length> [ safe | unsafe ]? ]

none computes to (or behaves as, I don't care) 0 unsafe
if both safe and unsafe are omitted, it is the same as safe
<length> unsafe does the same as what the spec says now
<length> safe computes to max( 1lh, <length>) unsafe. Nb: lh resolves at computed value time to an absolute lenght, so the computed value of line-height-step, and therefore what we will inherit, will be an absolute length.

Let's walk through that:

<article>
<h1>Title!</h1>
Lorem Ipsum…
</article>

article {
  font-size: 16px;
  line-height: normal;
  line-height-step: 20px;
}
h1 { font-size: 1.5em; }

First, assume a font for which line-height: normal gives 1.2:

natural line height of article lines: 16px × 1.2 = 19.2px
natural line height of h1 lines: 16px × 1.5 × 1.2 = 28.8px
line-height-step on the article element: 20px safe ⇒ 19.2px < 20px ⇒ 20px unsafe
line-height-step on the h1 element: inherit ⇒ 20px unsafe
adjusted line height of article lines: 19.2px ≤ 20px ⇒ 20px
adjusted line height of article lines: 20px < 28.8px ≤ 2 × 20px ⇒ 2 × 20px = 40px

⇒ Same as now

Now, let's assume a font for which line-height: normal gives 1.3

natural line height of article lines: 16px × 1.3 = 20.8px
* This is accidental. The author did not anticipate that on some other OS which they do not test on, the default font is different and larger than the step size. With the current spec, this would result in double lines for every line of the article, which is not what the author intended.*
natural line height of h1 lines: 16px × 1.5 × 1.3 = 31.2px
line-height-step on the article element: 20px safe ⇒ 20.8px > 20px ⇒ 20.8px unsafe
line-height-step on the h1 element: inherit ⇒ 20.8px unsafe
adjusted line height of article lines: 20.8px ≤ 20.8px ⇒ 20.8px
adjusted line height of article lines: 20.8px < 31.2px ≤ 2 × 20.8px ⇒ 2 × 20.8px = 41.6px

⇒ The step size is a little larger than expected, allowing the rhythm to work without creating blank lines everywhere

frivoal on 7 Apr 2017

I don't understand what this means:

safe computes to max( 1lh, ) unsafe. Nb: lh resolves at computed value time to an absolute lenght, so the computed value of line-height-step, and therefore what we will inherit, will be an absolute length.

What is the computed value of max(1lh) when line-height: normal? I tried to learn what the lh spec says, but I can't read from it.

Could you write down in more plain English?

kojiishi on 7 Apr 2017

BTW, a discussion at mozilla.dev.platform clarified that the use cases (and thus desired behaviors) are different between mine and Latin. This has been gradually understood, if I think now, but I was unconscious. The discussion was so much helpful to clarify that.

So I added a section about East Asian Casual Vertical Rhythm to clarify different two (or three, not sure at this point) use cases, and which property and combination works good for which use cases.

I'm under impression that even for the strict vertical rhythm, Latin and East Asia are different enough that we're likely to end up with 3 different behaviors; 1) East Asian Casual, 2) East Asian Strict, and 3) Latin Strict, but maybe we can merge 2 and 3, or other writing systems have 4th or more use cases. That should be figured out sometime in future, but as I wrote there, I'm focusing on East Asian Casual first.

kojiishi on 7 Apr 2017

What is the computed value of max(1lh) when line-height: normal? I tried to learn what the lh spec says, but I can't read from it.

Could you write down in more plain English?

line-height:normal behaves the same as if a number was specified, except the author doesn't know what that number is, since it depends on the font (and on how the browser chooses to deal with it).
But once the browsers knows the font and the font size, it can know how many pixels tall a line is going to be when line-height is normal. That's 1lh. Of course the actual line might end up being taller if you change font size on inlines, or have inline images, or superscripts... But assuming a line with nothing special in it, you know how tall it would be.

So, if you have specify 20px safe, either:

that 20px is taller than what this natural line height would be, in which case, everything behaves exactly the same as you specified
or 20px is smaller, in which case it's rounded up to the whatever the size of the line would be, and then use & inherit that rounded up value.

I think that should cover 99% of the use cases (which is why I made "safe" the default), and if you actually want the unsafe behavior, you can ask for it.

frivoal on 10 Apr 2017

I believe line-height: normal is allowed to do things that are a function of the font -- which means it can be a function of font selection and the actual text that is in the element. (I'm not sure if any UAs treat it as a function of the text, or if they just use the first available font. There was definitely discussion in the WG that it ought to consider all fonts used in the text.)

If it's a length unit, it needs a definition of 'normal' that doesn't depend on text.

dbaron on 10 Apr 2017

I'm going after the CSS2.1 definition, which although phrased somewhat vaguely, does not seem to allow (by my reading) considering the actual content of the element:

normal
Tells user agents to set the used value to a "reasonable" value based on the font of the element. The value has the same meaning as . We recommend a used value for 'normal' between 1.0 to 1.2.

I'm sure we can find some wiggle room in that phrasing, but regardless, I would indeed favor a definition of 'normal' that doesn't depend on text. The alternative is just going to make everything more complicated.

frivoal on 10 Apr 2017

@frivoal, I'm so disappointed at my English skill, I still can't understand what the proposal is after tens of minutes of try. Could you try plainer English, or meta-code if possible?

When you said:

that 20px is taller than what this natural line height would be, in which case, everything behaves exactly the same as you specified

I interpreted:

20px is the specified value of 'line-height-step'.
"natural line height" is the used line height from the layout result before rounding is applied?
"as you specified" means the specified value of 'line-height'?

so this means, in meta-code:

if (computed-line-height-step > line-height-from-layout-result) {
  if (specified-line-height is not "normal")
    use specified-line-height;
  else
    use ???
}

This logic doesn't make sense, so I'm probably lost somewhere, but don't know what it is.

kojiishi on 10 Apr 2017

See 10.6.1 Inline, non-replaced elements

If more than one font is used (this could happen when glyphs are found in different fonts), the height of the content area is not defined by this specification. However, we suggest that the height is chosen such that the content area is just high enough for either (1) the em-boxes, or (2) the maximum ascenders and descenders, of all the fonts in the element. Note that this may be larger than any of the font sizes involved, depending on the baseline alignment of the fonts.

If UA chose to do (2), "all the fonts in the element" depends on text, and that's all 4 browsers do today when line-height: normal, as @dbaron pointed out.

kojiishi on 10 Apr 2017

The CSS Working Group just discussed Avoiding accidental double spacing.

The full IRC log of that discussion

<astearns> topic: Avoiding accidental double spacing
<astearns> github issue: https://github.com/w3c/csswg-drafts/issues/938
<astearns> github topic: https://github.com/w3c/csswg-drafts/issues/938
<rachelandrew> florian: this is about avoiding accidental double spacing, this might happen if an author sets line height step to 1.3 em, and the default font using line-height normal turns out bigger than 1.3 em
<rachelandrew> in another font the line-height might be calculated at double height
<rachelandrew> the previous proposal was to make the height deterministic
<rachelandrew> but koji pointed out that line-height normal is useful as it avoids overlap with long ascenders and descenders
<rachelandrew> florian: has a proposal for this
<rachelandrew> when you have something with a tall line-height you want it to be double, when it inherits this is a feature
<rachelandrew> when you set it, you never want to accidentally make the line-height step smaller than the natural line-eheight
<rachelandrew> soemtimes you want to do it on purpose
<rachelandrew> proposing to add a safe /unsafe keyword pair defaulting to safe
<rachelandrew> current behaviour is the unsafe one
<rachelandrew> dbaron: I understand but think it is a problem
<rachelandrew> the check is whether the line-height step is smaller than th eline-height and if so make the step bigger
<rachelandrew> the 2 pieces I am concerned about, 1 is that normal is a computed value of line-height
<rachelandrew> having that go back and influence line height step doesn't seem as if it will work
<rachelandrew> we do sometimes have font metrics influence computed values
<rachelandrew> florian: you need ot take th eline-height unit value as the lh unit depends on it
<rachelandrew> dbaron: so maybe that is ok, the other thing is that if you use text for more than one font we claim you end up creating a box of the size of the. line-height around both sets
<rachelandrew> creating a height that is larger than the line-height
<rachelandrew> fantasai: thats a general problem
<rachelandrew> dbaron: to the whiteboard
<rachelandrew> florian: does this change what line-height normal means
<fantasai>  dbaron draws a Chinese character and a Latin letter
<rachelandrew> dbaron: demonstrates lining up characters on the whiteboard
<fantasai> dbaron: suppose these come from different fonts
<fantasai> dbaron draws the ascent and descent on the chinese character
<fantasai> dbaron then draws the ascent and descent on the Latin letter, which is a little bit lower
<rachelandrew> florian: which is the primary font and which is the fallback
<rachelandrew> dbaron: it shouldn't matter as per the spec
<rachelandrew> fantasai: I think there is a conflict in the spec
<rachelandrew> dbaron: the number line-height is 1.26 font size 16px, so we want a 20 pixel box round each of these
<rachelandrew> dbaron demonstrates where the line-height boxes are around the two characters
<fantasai> (dbaron is using a numeric line height in place of normal, because normal could result in varying line heights; didn't want to deal with the complexity yet)
<rachelandrew> dbaron: end up with a line box height bigger than the line-height
<fantasai> dbaron notes that because the ascent plus descent plus half-leading of each adds up to 20px, but they are offset by 1px, the total line height is 21px
<fantasai> fantasai says the CSS2.1 spec says two contradictory things, one of which is that
<rachelandrew> florian: in this case if you started with a line-height step of 30 pixels you wouldn't get double spacing
<rachelandrew> dbaron: the designer might have fonts that have the same box and others have different boxes and get the double spacing
<fantasai> https://github.com/w3c/csswg-drafts/issues/391
<rachelandrew> florian: for it to fail that way you need multiple fonts falling back to each other
<rachelandrew> fantasai: I think this point is really important, it is a critical flaw in how it works
<rachelandrew> when you have boxes of the same height, the CSS2.1 spec says 2 different thinks
<rachelandrew> you get that result and also get 20 pixels out of that
<rachelandrew> so we need to fix that
<rachelandrew> in order for line-height-step to be at all robust and not flaky we need to fix it
<rachelandrew> myles: Gecko and spec agree with dbaron's example, WebKit would calculate the height and add spacing to either side to make it equal
<fantasai> (The spec says two contradictory things, and supports both Gecko and WebKit's interpretations depending on which sentence you read in the paragraph describing this)
<dbaron> I don't think that's actually what Gecko does
<dbaron> dbaron: oh, yeah, that is what the spec says -- add the half-leading after unioning the character heights
<rachelandrew> astearn: this is one crucial instance, but initially you were talking about making step sizing in the safe mode that would increase itself if it encountered a large line-height
<rachelandrew> florian: where you have set your step size accidentally smaller than the computed value of line-height
<rachelandrew> fantasai: can we resolve on fixing this?
<fantasai> https://github.com/w3c/csswg-drafts/issues/391
<rachelandrew> koji: how do you compute line-height normal to pixels
<rachelandrew> <general disagreement about the spec>
<rachelandrew> dbaron: it's more like a number than any other kind of value but it does a thing based on the font
<rachelandrew> myles_: it is based on the default font
<dbaron> Here's the thing I drew on the whiteboard: https://lists.w3.org/Archives/Public/www-archive/2017Apr/att-0006/IMG_20170420_102101.jpg
<dbaron> (although as myles__ pointed out, I was wrong)
<astearns> the point I wanted to make that you use step sizing to create vertical rhythm. Creating a 'safe' version that avoids double spacing and breaks the rhythm is counterproductive
<rachelandrew> florian: is there a definition for the used value of line-height, if you have normal and know the font
<rachelandrew> fantasai: at computed time the lh unit needs to map to an actual value
<dbaron> dbaron: I think you get it from the first available font
<rachelandrew> florian: the value of the line-height property does it change based on content on the line?
<rachelandrew> does that property vary per line?
<rachelandrew> myles_: no properties do not vary per line
<rachelandrew> florian: you can't change the primary font per line
<rachelandrew> dbaron: I think florian is talking about multiple lines splitting the same element
<rachelandrew> the computed value of line-height normal is normal
<rachelandrew> so if you are asking what lh does, when you have line-height normal use the first available font in the font list
<rachelandrew> florian: not only is the value normal, but the value of line-height 1.2 is 1.2
<rachelandrew> dbaron: let's file a spec issue
<rachelandrew> florian: what makes this impossible
<rachelandrew> dbaron: spec needs to say how to compute to an abs length, probably using the primary font
<rachelandrew> florian: do you need to do layout to figure out the pixel value of line-height?
<rachelandrew> dbaron: for the lh unit or for layout?
<rachelandrew> florian: not talking about the line box
<rachelandrew> what does the UA pick the number based on?
<rachelandrew> fantasai: I think you assume this gets computed by a number and used as that number for layout calcs, used as a length to figure out the leading
<rachelandrew> that conversion happens per font in the text
<rachelandrew> myles_: webkit does this
<rachelandrew> fantasai: if you don't have a value for the entire run, how can you work out the line-height for a single value
<dbaron> ok, filed https://github.com/w3c/csswg-drafts/issues/1253 on css-values-4
<rachelandrew> myles_: (answering q) we do a bunch of stuff for the width then we calculate heights and place vertically
<rachelandrew> fantasai: for each char you find ascent and descent, get a value, if it is not the line-height increase or decrease on both sides to get the line-height
<rachelandrew> dbaron: do you then use the normal?
<rachelandrew> dbaron: use line-height normal, a single element on the line, font fallback is happening in the line, fonts have different etrics for line-height normal and ascent and descent
<rachelandrew> ... you take the ascent and descent, where do you get the number for normal
<rachelandrew> myles_: we don't
<rachelandrew> dbaron: Gecko includes the external leading
<rachelandrew> florian: how is this not a violation of 2.1?
<rachelandrew> koji: this sentence contradicts other parts of the spec
<rachelandrew> dbaron: that sentence was written in the olden days
<fantasai> s/we don't/we don't; we take that value with no extra leading/
<rachelandrew> dbaron: it assumes defaulting to what the font says
<dbaron> https://drafts.csswg.org/css2/visudet.html#inline-non-replaced
<rachelandrew> koji: describes content box height
<rachelandrew> fantasai: the content box height has no effect on layout
<rachelandrew> dbaron: it matters re leading around it
<rachelandrew> fantasai: but this section is not related to line-height normal
<rachelandrew> dbaron: it can change the size of things, because the leading changes the content height, the middle of where the content height is does matter to layout
<rachelandrew> astearn: we're not really addressing the rhythm issue here, though we found bugs in other specs
<rachelandrew> florian: do we have an issue to define the line-height unit based on primary font
<rachelandrew> dbaron: pasted such an issue earlier
<rachelandrew> florian: the issue I proposed is to define the same way
<rachelandrew> koji: this is based on font metrics of the primary font in safe mode
<rachelandrew> florian: when it inherits, is specified. It doesn't depend on the font
<rachelandrew> astearns: you set your vertical rhythm for body text but the heading is bigger what happens
<rachelandrew> florian: the line step height will double to keep the rhythm
<rachelandrew> gets the unsafe value from the pixel
<rachelandrew> not magic, doing this based on a keyword, unsafe is current behaviour. safe will cause the bigger line-height behaviour
<rachelandrew> koji: does this change based on inheriting?
<rachelandrew> florian: no magic with inheriting
<dbaron> ok, filed https://github.com/w3c/csswg-drafts/issues/1254 on line-height:normal definition in CSS 2.1
<rachelandrew> florian: how well this works depends on how we fix 2.1, it doesn't make things worse
<rachelandrew> koji: I don't see it saves much, maybe some cases people think it is better
<rachelandrew> fantasai: keyword on line height setp to us line-height
<rachelandrew> astearns: that would make double spacing more likely
<rachelandrew> florian: you don't want to be exactly the line-height, needs to be just a bit more
<rachelandrew> astearns: step sizing could be a percentage of line-height
<rachelandrew> florian: either line-height is a number and works, or it isn't
<rachelandrew> if you want to set your step smaller than the line-height, set it explicitly with unsafe then it will not get adjusted up
<dbaron> Koji: on web, due to small screen real estate, people set grid to fraction (half) of the desired line height
<dbaron> astearns: that happens in print as well
<rachelandrew> koji: I understand some cases it helps, given complexity vs benefit
<rachelandrew> florian: it is very frustrating when people won't use a browser if it breaks, the outcome of not dealing with this could cause problems with different sized fonts, in one browser double heights might happen based on default sizing
<rachelandrew> fantasai: having a layout system that breaks badly when fonts get substtuted is bad
<rachelandrew> double spacing is bad
<rachelandrew> dbaron: authors should not have to write a number in their CSS that has to be right based on the font the user has
<rachelandrew> florian: the feature currently requires users pick a value
<rachelandrew> dbaron: the dev currently has to write line-height 3 or 20 pixels, Chrome might switch to double spacing based on one value, Firefox might pick another value, a subtle difference means you get double spacing in one browser and not another
<rachelandrew> dbaron: Gecko has had to reduce line-height they compute for webcompat issues
<rachelandrew> fantasai: we don't want more of these situations
<rachelandrew> astearns: should we come up with a way of making step sizing safer, we haven't come up with a resolution on that

css-meeting-bot on 20 Apr 2017

So here's an idea for avoiding accidental double-spacing, although it doesn't quite work (see below), but i figured it was worth noting down anyway:

Instead of a line-height-step: <length> property that is inherited, have something like line-height-step: <number> | auto | none which is not inherited, but that controls a step size (which is conceptually either none or a length) that is propagated from ancestors to descendants:
- the initial value is auto, which means the lines of this element use the same step size as the (containing block? / parent?), if any
- the none value means the lines of this element do not use a step size
- the <number> value means this element's step size (a length) is computed based on the element's properties. Values smaller than 1.0 are invalid (or changed to 1.0). The step size is computed by computing the height a line box would have if it contained glyphs from all fonts in the font-family list (given the other font properties), i.e., using the ascent and descent of each, and the line-height (which might be normal and thus lead to using external leading), and then multiplying that result by the <number> value.

(I'm not particularly happy with the names I've chosen here.)

So the problem with this as that it doesn't actually solve the font fallback problem, since font fallback often fails to find a glyph in the font-family and has to fall back to searching for other available fonts.

dbaron on 20 Apr 2017

So on further consideration, maybe font fallback isn't as much of a problem as I thought.

In particular, line-height-step isn't actually aligning baselines to even spacing; it's aligning the line boxes. Font fallback can cause the position of the baseline to vary within the line box, but maybe that just leads to slight baseline jitter rather than accidental double spacing. Maybe that's not so bad. (Although it's not great that it would defer having a solution for real baseline snapping.)

Then I think the remaining question is that we don't actually know what line-height: normal means (#1254), and which fonts' metrics it considers. If all of the font metrics that could ever be considered for line-height: normal are considered when evaluating the step length from line-height-step: <number> as I propose above, then I think things would be ok.

dbaron on 20 Apr 2017

I believe I understand how your proposal work. But I will need to think about it for a while to figure out if:

solves the problem ( I think it does)
solve the problem better than my thing (I don't know, that might depends on how line-height works)
Whether it will make sense to authors and let them express the thing they want in an understandable way (I do not know yet).

frivoal on 20 Apr 2017

I'd also note that in our discussion in the meeting yesterday morning, we misinterpreted what CSS2 says about how line-height works. It does add the half-leading separately per-glyph, rather than computing the half-leading based on the line-height and the already-unioned content-box bounds. In particular, §10.8.1 Leading and half-leading says:

Still for each glyph, determine the leading L to add, where L = 'line-height' - AD. Half the leading is added above A and the other half below D, giving the glyph and its leading a total height above the baseline of A' = A + L/2 and a total depth of D' = D + L/2.
The height of the inline box encloses all glyphs and their half-leading on each side and is thus exactly 'line-height'. Boxes of child elements do not influence this height.

I think this means font fallback remains a problem, i.e., I retract my retraction in https://github.com/w3c/csswg-drafts/issues/938#issuecomment-295747854.

dbaron on 21 Apr 2017

Apologies in advance I'm slow to understand. I hope I understand correctly with the help from @frivoal (he corrected my one misunderstanding, thx.)

I really wish the proposal solves the concern, a few questions for clarification:

It takes fonts from font-family of the element, but does not include fonts from system fallback, correct?
If descendants have different font-family, it can round up, though @frivoal and I wonder whether we'd want to call it "accidental" or "appropriate" is gray. Do you think such case appropriate?

Also note, I guess this is already clear to all of us but @fantasai and I tested a bit more last night that, when line-height is not normal, line height is consistent across fonts/platform/browser. Test here. normal is the only case it is not, for a good reason as stated above.

@fantasai had some idea, but need to bake a little more.

kojiishi on 21 Apr 2017

Even if line-height is consistent between browsers -- are the lines actually all spaced at the specified number? If so, then that means that either:

(a) browsers are interoperably not following the piece of spec that I quoted in https://github.com/w3c/csswg-drafts/issues/938#issuecomment-296073432, or
(b) the testcase isn't triggering font fallback to fonts with sufficiently different metrics.

dbaron on 21 Apr 2017

are the lines actually all spaced at the specified number?

Yes, we checked the box size in Inspector, divided by the number of lines and by the value of line-height, got the font size.

As far as I read CSS2, number is "multiplied by the element's font size" while normal is "based on the font of the element", so when I was reading Blink code, when number, the height affected only by font size, while when normal, affected by font metrics made sense to me. Do you see any errors?

kojiishi on 21 Apr 2017

Oh, wait, I see what missed...

kojiishi on 21 Apr 2017

are the lines actually all spaced at the specified number?

To answer to your question with correct understanding, exact positioning of baselines is not part of the goal for Level 1 of the line-height-step, because:

This isn't defined nor interoperable today with CSS2, nor CSS inline level 3 as of today.
Consistent height and baseline jitters can be solved separately.
While there're algorithms that can improve baseline jitters for some scripts, as in your proposal, East Asians are unlikely to get desired results until dominant-baseline is implemented. As some claimed, this level of the property is unlikely to be much useful for Latin.

When we've got enough infrastructure defined in CSS inline level 3 or in future levels, we can add features to solve baseline jitter problem.

kojiishi on 24 Apr 2017

From @dbaron's comment on Apr 21st, I think the baseline jitters is a problem we should look into in CSS Inline L3, so I'm opening a separate issue.

kojiishi on 1 May 2017

I'd like to propose that line-height-step is effective only when line-height is _not_ normal. The motivation is to respond to the feedback 1 below.

There was a feedback that different browsers/platforms/fonts to use different steps is the biggest problem we must solve.
The problem 1 above applies only when line-height is normal. Discussions so far has discovered that when line-height is not normal, the used line height is interoperably consistent across browsers/platforms/fonts.
There are multiple proposals on this issue, two from @frivoal in this thread, one from @dbaron above, and another from @fantasai not baked well yet. I admit I don't fully understand @frivoal's yet (sorry) but given the line-height: normal is designed to make used line height dependent on fonts, we can come up with a heuristics to mitigate but can never solve the problem 1.
Given the primary target of the feature is East Asians, fallback is highly possible. When system fallback happens, the used steps will vary by installed fonts. It'd be not easy to mitigate this case.
If in the future we changed our mind and wanted to apply line-height-step to line-height: normal, we could add a keyword, like the one in @frivoal's proposal.

kojiishi on 1 May 2017

The problem 1 above applies only when line-height is normal. Discussions so far has discovered that when line-height is not normal, the used line height is interoperably consistent across browsers/platforms/fonts.

Really? It doesn't seem to me so. IIRC, there is still inconsistency among browsers when there are inline boxes and font fallback involve.

upsuper on 2 May 2017

Oh, I was probably wrong. The used line height should be consistent when the computed value is not normal.

upsuper on 2 May 2017

I don't think we should try to make progress on this issue until https://github.com/w3c/csswg-drafts/issues/1254 & https://github.com/w3c/csswg-drafts/issues/1314 are resolved.

frivoal on 3 May 2017

Some general questions: Is CSS-Rhythm intended mainly for CJK text? And, if so, is font fallback a problem in CJK? (It may be the case that most fonts' characters lie within the same-sized em box)

litherum on 3 May 2017

Some general questions: Is CSS-Rhythm intended mainly for CJK text?

I think it is useful for CJK and we should make sure it works well there as well, but it is by no means exclusive to CJK, and should work any language/script.

frivoal on 3 May 2017

The CSS Working Group just discussed Avoiding accidental double spacing.

The full IRC log of that discussion

<dael> Topic: Avoiding accidental double spacing

<dael> Github topic: https://github.com/w3c/csswg-drafts/issues/938

<dael> Florian_: I think we shouldn't rehase that issue in github. I think we need to sort out another issue first. We had been talking about what line-height normal means at F2F and discovered we don't even know what line-height: number means.

<dael> koji: There are details to get out. As long...in terms of line-height consistancy, I think dbaron confirmed it's consistant.

<dael> Florian_: I don't think we concluded. WE said prob is, but we have 3 behaviors on the white board. We weren't sure.

<dael> koji: All on consistant for line-height

<dael> Florian_: No they're not.

<dael> koji: They were.

<dael> Florian_: 2 are, one isn't.

<dael> Florian_: The black behavior does not result in the same line-height as blue a nd red.

<dael> Florian_: We weren't sure which Edge did. We didn't have full answers.

<dbaron> Only one of the three is consistent for line-height if you have font fallback

<dael> Florian_: My prop on double s paces depending on line-height.

<fantasai> diagram: https://lists.w3.org/Archives/Public/www-archive/2017Apr/att-0008/IMG_20170421_173959.jpg

<dael> koji: I think I have tests on this already.

<dael> Florian_: If you have tests, when were they shared?

<dael> koji: In this issue.

<dael> koji: As far as I tested it's interop.

<Florian_> https://github.com/w3c/csswg-drafts/issues/1254

<dael> Florian_: When we discussed at F2F no one knew for sure. If you do know ^ is where we discussed that.

<dael> astearns: koji can you post a link to your test cases?

<koji> http://output.jsbin.com/xekuhu

<astearns> http://output.jsbin.com/xekuhu

<dael> astearns: Is it ^?

<dael> astearns: There we go.

<dael> Florian_: Okay.

<dael> astearns: koji can you desc what it's checking?

<dael> koji: This is a test case we discussed. 5 in the graph and line-height nromal. You can see the line-height is same. If you hae 5 line-height it's maybe different. 0,4 have 1.2, 1.5, 1.8

<dael> koji: You can see it's consistant height.

<dbaron> Does this testcase have font metrics that would trigger the issues we discussed?

<dael> Florian_: I can't figure out which browser is what color.

<dael> fantasai: You need a case with fallback in the line. Where you have difference scripts all on the sameline. Have that trigger different fonts with different ascent & decent metrics.

<dael> MaRakow: You need a font with crazy high and crazy low ascent/descent.

<MaRakow> s/MaRakow/???/

<myles_> s/MaRakow/myles_/

<dael> Florian_: I think this is a bit too tricky on the fly. Until we call agree what line-height: number and line-height: normal means it'll be hard to solve.

<dael> Florian_: If we agree enough that size is the same that could be enough to discuss. Doc about behavior isn't there.

<dael> koji: I thought [missed]

<dael> astearns: I think I heard you say browsers agree on line-height, but not glyph in line-box. Correct?

<dael> koji: Yeah. one this we agreed is to match existing impl. If they all agree on line-height: n umber I don't see problems.

<dael> Florian_: I don't think we established they agree.

<liam> s/not glyph in/not glyph-position in/

<dael> fantasai: We said impl will agree if they confirm to CSS2 because we agreed to change CSS2 to say that the black behavior is not allowed. So if immpl follows spec line0height will be that number. If impl don't follow they have to change.

<dael> dbaron: I don't htink that's what we agreed.

<dael> Florian_: I think that was a preliminary conclusion.

<dael> dbaron: I think what we agreed only produces it if there's a single element. It doesn't work with multiple when some have font-fallback.

<dael> astearns: Did I hear myles_ volunteer to make test fonts?

<dael> myles_: I can do that easily.

<dbaron> s/with multiple/if there are multiple elements on the line/

<dael> astearns: Thank you.

<Rossen_> https://lists.w3.org/Archives/Public/www-archive/2017May/0000.html

<myles_> please ACTION me

<myles_> bkardell_: there are many fonts named that 😇

<myles_> (test fonts)

<dael> astearns: I think we need to get past this Q about what CSS 2 will say about line height and if impl will be able to match. Then figure out cases where that's not enough for consistant line height.

<dael> astearns: Seems they're pre-requisite to figure out step height.

<dael> astearns: koji is it alright ot move on?

<dael> koji: Yeah. I'll re-read the discussion.

<dael> astearns: I wouldlike to see progress. I'll see what I can do to get that going. I think myles_ making the fonts will be a big help.

<Florian_> agreed

css-meeting-bot on 3 May 2017

Some general questions: Is CSS-Rhythm intended mainly for CJK text?

This is designed for CJK use case, and I heard several people saying Latin feels this is not useful, so we removed the Latin feature in January.

I don't have good info how other scripts than Latin/CJK would like it. As far as I tried to ping at i18n WG, I didn't hear back any, and word processors have similar features enabled only for CJK versions. From these, my assumption atm is this is CJK-only feature, but hard to deny scripts that we have not reached yet.

And, if so, is font fallback a problem in CJK? (It may be the case that most fonts' characters lie within the same-sized em box)

I don't have data how common it is, but it's not rare to have Latin font as primary:

font-family: Times, win-cjk-font, mac-cjk-font, serif;
font-size: 12px;
line-height: 1.8;

I think the primary case for CJK is about having consistent height across different font metrics (such as platform/version/user installed fonts differences), but fallback is also a case to cover.

kojiishi on 3 May 2017

Re-read the IRC log, appreciate your confirmation: @frivoal @dbaron

So the red and the blue from the F2F diagram provides consistent height, though baseline position may not.
The black one is not consistent height.
We confirmed Gecko and WebKit are red (though the diagram indicates Gecko is blue) and Blink is blue, though when I commented Blink and WebKit are more likely the same on this behavior, @litherum wasn't sure.
@atanassov wasn't sure whether Edge does red, blue, black, or something else in the F2F.
By running a test with system fallback of tall scripts @fantasai and I used to verify Blink/WebKit/Gecko behavior on the night before, Edge showed the consistent height, so @fantasai and I thought the black is not allowed, and disallowing black does not require anyone to change, but maybe we didn't share this, don't remember.
As long as we agreed on heights are consistent, editing CSS2 and CSS-Rhythm do not block each other, we can parallelize them.
@upsuper thinks it's consistent in the comment above.

Do you find where I misunderstood? Since we were talking about test fonts, is it just 5 was not shared, or we want more through tests than 5, or something else?

Some comments in IRC log:

Florian_: I can't figure out which browser is what color.

This test is meant to run in each browser and compare pixels. Sorry that explanation was missing.

dbaron> Does this testcase have font metrics that would trigger the issues we discussed?

It has Latin and tall scripts without font-family in a line. So it's not cascading fallback, but has system fallback.

dbaron: I think what we agreed only produces it if there's a single element. It doesn't work with multiple when some have font-fallback.

I guess I missed this was on topic, sorry about that. The spec defines line box height to be computed from inline boxes, so I'm not sure how multiple elements can differ. Is this about we don't have tests for this specific case, or do you know somewhere in the spec mention differences in multiple elements?

My assumption -- not really confirmed though -- was that CSS2 already has tests for multiple elements with different size/vertical align/baseline etc., and that if single element with fallback works as expected, multiple elements with fallback is covered by running both tests.

Can I understand your comment that you think a combination test is vital, or do I still misunderstand something?

kojiishi on 3 May 2017

A couple of more notes:

dbaron> Does this testcase have font metrics that would trigger the issues we discussed?

It has Latin and tall scripts without font-family in a line. So it's not cascading fallback, but has system fallback.

In case whether these system fonts have different metrics or not is still a question, lines with line-height: normal having different height is a proof of such system fallback fonts having different metrics.

Florian_: I can't figure out which browser is what color.

This test is meant to run in each browser and compare pixels. Sorry that explanation was missing.

I made a ref test from the test above.

kojiishi on 3 May 2017

I just created three fonts to test what the different browsers do.

tl;dr: All browsers agree about how line-height works (both the magical normal as well as <number>).

The test fonts are Ahem, Ahem with a super large ascent, and Ahem with a super large descent. I also selectively removed support for specific characters from each font such that every fallback situation could be tested.

"X" means "present in font"
"_" means "not present in font"
             A B C D E F G H
            ————————————————
AhemSparse | X _ X X _ X _ _
AhemTall   | X _ X _ X _ X _
AhemDeep   | X _ _ X X _ _ X

The HTML file has a few tests which set line-height normal and line-height on some text. I wanted to compare the case of font-family: AhemSparse, AhemTall and font-family: AhemTall, AhemDeep. All browsers agree on the rendering of all of these tests.

Therefore, we can say:
line-height: normal means: "For every line inependently: Union all the ascents. Then union all the descents. Add them together. This is your line-height for that specific line. Place the baseline at a distance down equal to the union of the ascents."
line-height: <number> means: "Ignore secondary fonts. Consider the primary font's ascent and its descent. Add these together, and subtract that from the computed value of line-height. This is the extra vertical space required. Place the baseline at a distance down of half this extra vertical space plus the ascent of the font. Now that you have the baseline position, place the rest of the glyphs on that same baseline."

EDITED: I'm not actually sure my previous analysis is correct. Give me some more time to investigate.

lineheight.zip

litherum on 4 May 2017

Thank you @litherum this is a great progress.

As I understood the F2F diagram, Gecko (the red) unions all font metrics, but takes center of the union to match to A+D of the first font, so the baseline position maybe different. If you see different baseline positions, it is #1314.

I look forward to further analysis.

kojiishi on 5 May 2017

I think I understand now why @dbaron was talking about baseline positions in this context; sorry for slow to understand.

If baseline position is different, and if multiple inline boxes are in a line, and if they are aligned at the baseline, there's a possibility to result in different line box height. Is this the concern, @dbaron?

With the @litherum's fonts, I think we can test it by:

<div id="target" style="font-size: 10px; line-height: 1; font-family: AhemSparse, AhemTall, AhemDeep">
<span>AE</span><span>AH</span>
</div>

and Gecko/Edge/Blink/WebKit all computed to 10px.

kojiishi on 5 May 2017

@litherum @kojiishi I made a similar test, using fonts from google fonts rather than specially crafted version of ahem. The idea is the same though: one has a tall ascent (and short descent), and the other is the other way around. I am testing a few more combinations, and also using multiple ways to visualize & measure the results.

Note that I am only testing what happens with a single element on the line, although I am using fallback fonts. Multiple elements on the line is a separate discussion.

TL;DR: There are more differences than you found with your earlier test. For line height calculations with line-height other than normal, everybody does the same. For line height calculations with line-height:normal, Chrome uses a different logic than everyone else (in some cases). For the position of the baseline within a line-height other than normal, Chrome uses a different logic than everyone else. For which font metrics to use, Firefox uses different data than everyone else (in some cases). For height of content box, there are 3 behaviors: Safari/Edge, Chrome, Firefox. Only in Firefox, the outline of a block may be larger than the block when line-height is not normal.

Here's the test: http://jsbin.com/dacokez

In it, I am testing 4 dimensions that relate to line height:

How lines stack (should be based on the height of the line box)
Where is the border of the block that contains the lines (should be based on the sum of the height of the line boxes), hopefully giving the same results as the previous point.
How big is the background on an inline (should be based on the height of the content box)
Where is the outline of the block that contains the lines (undefined what this should be based on, but possibly interesting)

I've run this in Safari, Firefox, Chrome and Edge.

Conclusions:

Safari and Edge (this is not a typo, I do not mean Safari and Chrome) behave identically in all observable aspects of this test (except font rasterization / hinting / anti-aliasing, but that's out of scope). Chrome is different on a number of things, and Firefox is differentl on different things.

In all browsers, measuring the height of the line box by line stacking of by the border on the div gives internally consistent results. (thankfully. I'd have gone nuts otherwise).
When line-height is a number or length:
- The height of the line box is always exactly the requested height in all browsers, even when there are fallbacks. i.e. Nobody does the black behavior in the f2f diagram
- In Safari/Edge and Firefox the position of the baseline within the line box only depends on the primary font, and does not change depending on whether a fallback font is specified or used. I.e. they do the blue behavior in the F2F diagram. (note: the results in the example above are not perfectly aligned in Safari/Edge vs Firefox, as Firefox seem to be using different metrics for the descent/ascent in the Revalia font, but the logic is the same)
- In Chrome the position of the baseline within the line box does not appear to depend either on the fonts specified nor on the fonts used. I.e. It neither does the blue nor the red behavior in the F2F diagram. I have no idea where it pulls the baseline position from.
When line-height is normal:
- Firefox and Safari/Edge size the line to go from the top of the tallest of the primary font (even if it is not used) and the fallback fonts actually used, to the bottom of the deepest of the primary font (even if it is not used) and the fallback fonts actually used. In otherwords, they take the strut into account. (note: the results in the example above are not perfectly aligned in Safari/Edge vs Firefox, as Firefox seem to be using different metrics for the descent/ascent in the Revalia font, but the logic is the same)
- Chrome size the line to go from the top of the tallest fonts actually used (not including the primary font if it is not used), to the bottom of the deepest of the fonts actually used (not including the primary font if it is not used). In otherwords, it does not take the strut into account.
- Chome and Safari/Edge use the same font metrics, so other than the case where the primary font is not used (see above), the lines have the same height.
Browsers disagree about the height of the content box (background on a span):
- In Chrome, it does not appear to depend on the fonts or on the line-height property at all.
- In Safari/Edge it depends on some metric of the primary font (regardless of whether it is used) and seems to depend also on whether line-height is normal or not, but seems to be the same height for all numeric values of line-height.
- In Firefox, it does not depend on the line-height property, but it does depend on some metric of the primary font (regardless of whether it is used), it is however a different metric than the one used by Safari/Edge for at least some fonts (different on Revalia in the example).
In all browsers except firefox, the outline also gives consistent results and lets us to measure the height of the line box. In Firefox, it takes into account some font-based measurement, and is often larger. It is sized based on all the fonts used, plus the primary font even if it was not used.

frivoal on 12 Jul 2017

❤1

Agenda+ F2F, now that we have more details over how various browsers handle line height calculations and related calculations, to see if we can try to converge on that.

frivoal on 12 Jul 2017

Thank you @frivoal for the investigations.

In Paris, I'd like to take a step back and ask opinions from more people, especially, from who haven't spoken much yet.

Here's my understanding of the history.

This issue originally starts from disabling a hard-coded value in UA, assuming it exists. At that point, I heard some members supported the idea, but IIUC not all spoke their opinions.
Then we learned that line-height: normal does font-dependent layout, and this issue was re-defined as "font-dependent layout and vertical rhythms should not work together".
@dbaron commented in mozilla.dev.platform that he's opposed because if vertical rhythms are applied to font-dependent layout, it can produce serious compatibility problem.

Since then, IIUC, in Tokyo and in comments above, we're trying to understand what "font-dependent layout" is in CSS, and try to find a way to disable either it or vertical rhythms when the other was enabled. @frivoal's detailed investigation above should help this discussion greatly.

Assuming my understanding so far is correct, I think we're missing a few pieces before diving into solutions.

The @dbaron's comment above was not shared with WG.
While we now understand what will happen when vertical rhythm is enabled in font-dependent layout document, we haven't discussed much about side effects if we disabled either one.
We heard opinions from several people at point 1 of the history, but not after 2.
Even at point 1, IIUC, we haven't heard opinions from other implemeters than Blink/Gecko.

In Tokyo, I was supportive to disable either one. But as I thought about its side effects and i18n impacts, I'm not sure if this is the right way to go, and I would like to hear opinions from more people.

So I'd like to ask, in Paris:

@dbaron, is it possible for you to explain your comments at mozilla.dev.platform, and up-to-date thoughts if there were any changes since then?
@FremyCompany (or someone at Edge team) could you mind to consider sharing your thoughts?
@litherum (or someone at WebKit team) could you mind to consider sharing your thoughts? I remember you were supportive in April 2016, but quite a long time has past. Also, this topic would require Line Grid to change the behavior, which WebKit ships today.

@dbaron, @FremyCompany, @litherum, could you mind to consider above? I can explain my position too (guess it's obvious but in case ;-) and with all opinions, I'd like to review our position to all vertical rhythm features.

I also hope @fantasai, @frivoal, @astearns, @dauwhe, and all other text people can share thoughts in Paris. I hope you don't mind I listed only implementers above, I just listed missing information atm from what I can understand.

kojiishi on 13 Jul 2017

@kojiishi

I think I disagree with one point of what you said above:

Then we learned that line-height: normal does font-dependent layout, and this issue was re-defined as "font-dependent layout and vertical rhythms should not work together".

At least from my side, the conclusion was not "should not work together", but we should find a way to make sure that font-dependent differences in layout and vertical rhythms should not interfere to create completely different results in different browsers / OS (for example, normal rhythm in one browser, double spacing everywhere in another). One way is to turn off vertical rhythm, another way would be to find a solution that avoid this bad result.

I was initially searching for the solution when we (or just me? maybe other people knew it already) realized that there were spec ambiguities and lack of interop.

With the investigation we've done now, I think we have confirmed that there were differences in the resulting layout, but that implementations were actually quite close. I think the number of things we need to agree on to have actual interop might not be all that bad.

I hope we can first resolve this, and make sure that we have actual interop on line-height calculations. Even if we do not get to full interop on how browser read font metrics (and we will not get interop on which fonts each browser actually uses), I think this will already be a good step forward.

I also think that even though I initially misunderstood how line-height: normal works, I think a simple variant my proposal to solve the instability problem of line-height:normal together with vertical rhythm may actually work. But before we discuss that, I want to try and close the line height calculations.

frivoal on 14 Jul 2017

I think I disagree with one point of what you said above:

That's how I understood @dbaron's comment in mozilla.dev.platform, which looks like stronger than yours, but I'm not sure if I understand correctly, so I'd like to hear his comment first.

Also, I'd like to hear who hasn't spoken much yet; specifically other two implementers. After 6 months this issue was created, we haven't even agreed on the problem yet.

Do you mind discussing this first?

kojiishi on 20 Jul 2017

@shans and I were discussing this, and Shane thinks he has a suggestion we haven't seen yet, which I think is reasonable.

Basically, line-height: normal is UA-defined. This is the source of our problem, but it might also be our solution - what if, when line-height: normal was "slightly larger" (according to some UA-defined threshold) to a multiple of line-height-step, we adjusted the value of normal to exactly the value of line-height-step? That would avoid the accidental double-spacing by default, which is what we want here. If people don't want their line-height to get adjusted, they just have to set it to an explicit value, which is also just fine.

We think this works intuitively for authors, and automatically handles the issue here. Thoughts?

tabatkins on 27 Jul 2017

@tabatkins This is maybe a good solution but, technically speaking, this just shifts the problem.

With this in place, if on Mac OSX the font cause a 13px line-height and line-step is 12px, but 13px is deemed close enough from 12px that you snap, then you don't get double-lining. Let's say that on Windows the font resolution is rounded up instead of rounded down and you get 14px, which is different enough from 12px that you don't snap back, then you double-space every line. If you author on a Mac WYSISYG you might never find out.

Now the question of course becomes whether you shifted the problem enough that it becomes so difficult to repro in practice that it would be considered a gross author mistake. I would be ok with that if the UA-defined threshold can be made big enough that font-variation alone could not explain the double-spacing (such the author must also have grossly miscomputed its line-step if double-spacing becomes possible).

(I think I'd also be also ok if all browsers agreed to cap line-height:normal to the line-step if line-height:<fallback-number> would not result in double-spacing but the UA's algorithm to compute line-height:normal would. So basically, line-height:normal still applies generally but only if line-height:1.1 and line-height:normal would result in the same amount of line steps being used.)

FremyCompany on 28 Jul 2017

Thank you @tabatkins, @shans, and @FremyCompany for great ideas! These should help discussion so much!!

I was neglecting to write down, sorry, but I've changed my position since April. In April, I was thinking in similar direction; limit or disable either line-height:normal or line-height-step in some ways, but I'm moving to a different position now.

I think this is an issue that we should not solve. The hardest part of this issue from my point of view is that, this issue is about conflicting requirements. I understand many WG members think, as in @tabatkins's comment above, line-height: normal is "the source of the problem". On the other hand, line-height: normal is a feature many other people rely on, or even require. It looks to me that solving either one would sacrifice the other request.

It looks like, as far as I understand (maybe wrong, Florian seemed to understood differently) @dbaron went to opposite direction even stronger, so I'd like to hear the explanation of his opinion to understand it better, and also what other implementers think.

I understand people supporting this issue are keen to interoperable layout. That's one key goal for us, but CSS also has been providing font- and content-dependent layout feature. In this mode, layout results are not pixel-interoperable, but impls interoperably provide readable content regardless of fonts, content, and scripts. This is another key goal for us, and in CSS, both height and line-height are font-/content-dependent by default.

I have several reasons to believe solving this issue is net-loss, we can discuss in Paris, but I'm writing down three of them.

First, the issue is when author sets line-height-step to unreasonable value, and when the author forgot to test multiple browsers/platforms. This is an error case safe guard. It's nice to have, but we already have features, if used inappropriately, would make layout terribly worse only in some browsers/platforms without any safe guards. The safe guard should be in place only if its side effect is reasonably small. In this case, the safe guard will limit other people's requests, and I don't see any good reasons to pick the safe guard and reject the other.

Second. line-height: normal maybe problematic to some scripts, but more important or required for other scripts. Limiting the combination means we don't provide equal opportunities to all scripts. This maybe ok for line-height-step, where many WG members confirmed it's not useful for Latin at all and focuses on East Asian use case only, but is more severe for other vertical rhythm features since I wish them to be global features. For any global features, I believe i18n fairness should not be traded off with safe guards.

Third. If we acknowledge this is an issue we must solve, IIUC, it'll hinder most vertical rhythm features. Example:

<style>div { font: 10px/1 serif; }</style>
<div>Bunch of English text, no span, no fallback, to make this simple</div>

Now we apply box-height-step: 5em to the <div>. Although we have line-height: 1, glyph widths vary by fonts/platforms/browsers, so the number of lines varies. It varies even by window width. The result could be 5em height, or doubled to 10em. Is this an _accidental_ jump, or is this an _intentional_ jump? As I understand how people defines _accidental_ in this issue, this is _accidental_. If author doesn't test other browsers, platforms, or fonts, the layout results differ by double. But again, I think this is _intentional_.

I can keep writing more, but I hope people gets some basic idea what I'd like to discuss. Hopefully these are from misunderstanding of mine, I'm still having trouble to understand what makes a step/snap _accidental_, and would like to understand @dbaron's comment better.

kojiishi on 28 Jul 2017

First, the issue is when author sets line-height-step to unreasonable value, and when the author forgot to test multiple browsers/platforms. This is an error case safe guard. It's nice to have, but we already have features, if used inappropriately, would make layout terribly worse only in some browsers/platforms without any safe guards. The safe guard should be in place only if its side effect is reasonably small. In this case, the safe guard will limit other people's requests, and I don't see any good reasons to pick the safe guard and reject the other.

I disagree extremely strongly with this. This is an "error case", but a very reasonable one that's pretty easy to fall into. It's not the author doing something unreasonable, it's the author not happening to test on whatever browsers have a slightly-larger-than-normal line-height: normal value. Since this value has never been problematic in the past, and in general has only a tiny visual effect, it's extremely surprising that they suddenly get a large visual difference when they start using line-height-step.

That's been the entire point this entire time. A nearly-invisible difference suddenly gets accidentally magnified into a very visible difference.

Second. line-height: normal maybe problematic to some scripts, but more important or required for other scripts. Limiting the combination means we don't provide equal opportunities to all scripts. This maybe ok for line-height-step, where many WG members confirmed it's not useful for Latin at all and focuses on East Asian use case only, but is more severe for other vertical rhythm features since I wish them to be global features. For any global features, I believe i18n fairness should not be traded off with safe guards.

This doesn't make sense to me. If the author is setting line-height-step: X and it gives single-spacing in their current browser, then that line-height is fine for the scripts in use. What scenario are you imagining where it's necessary for i18n for a script to render larger than the line-height-step in some browsers but not others?

The result could be 5em height, or doubled to 10em. Is this an accidental jump, or is this an intentional jump? As I understand how people defines accidental in this issue, this is accidental. If author doesn't test other browsers, platforms, or fonts, the layout results differ by double. But again, I think this is intentional.

Yes, line-breaking is definitely something authors are already reasonably familiar with; they know it's pretty uncertain. We still see a lot of authors incorrectly assuming something will break to exactly X lines, but it's at least a pretty general knowledge, and it's obvious what's happening when they look at it.

This is totally different from the situation we're worried about, where authors are not generally aware that line-height: normal varies between browsers and even in different situations on the same browser, and when it does cause double-spacing problems, it's not obvious why it's happening (because the line-height difference is probably only 1px or so, which is very difficult to see). Even a side-by-side comparison will be difficult, since the double-spacing will cause larger layout differences that'll obscure the tiny difference in line heights.

Further, a block-step getting tripped over the line affects that one block; much of the time, it'll mean that instead of the block being 10 steps tall, it'll be 11 or something; that's a relatively insignificant difference in most layouts. This line-height problem, on the other hand, doubles the height of every line, which'll double the height of text-containing elements; that's taking it from 10 steps to 20 steps. The only time the block-step is comparable is if you have a whole lot of blocks that are all expected to be one step tall, and they get doubled in some circumstances; I think you'll agree that'll be relatively rare.

There's really no comparison here. line-height: normal is a nearly-invisible menace that will bite a lot of authors who are just trying to use line-height-step in a reasonable, correct way, and screw up their page layout significantly. It's not comparable to box-height-step, and it's not reasonable to push it into the "corner case" box.

tabatkins on 28 Jul 2017

This is an "error case", but a very reasonable...whatever browsers have a slightly-larger-than-normal line-height: normal value.

I assume you're talking about Latin scenario, and in that case, the "whatever browsers have line-height: normal value" is at most 1.2, so the _accidental_ can happen only between 1 and 1.2, if I understand your definition of _accidental_ correctly. Using the value between 1 and 1.2 is not reasonable from typographic rules, and is against the philosophy of vertical rhythm. If you're talking about other values, can you define what your _accidental_ is?

This doesn't make sense to me. If the author is setting...

Sounds like we don't understand each other. Let's talk in Paris.

where authors are not generally aware that line-height: normal varies between browsers and even in different situations on the same browser

Ah, I found huge difference here. You might be right for Latin, I don't know, but for i18n, line-height: normal being different by browsers, fonts, and situations is a known feature, which we heavily appreciate and rely on. This might explain why we don't communicate well each other on this topic?

kojiishi on 29 Jul 2017

The CSS Working Group just discussed inline layout.

The full IRC log of that discussion

<jet> Topic: inline layout

<astearns> github: https://github.com/w3c/csswg-drafts/issues/938

<jet> Florian: from weaknesses of vertcal rythm

<jet> Florian: found lineheight issues from that investigation

<Florian> https://github.com/w3c/csswg-drafts/issues/938#issuecomment-314690847

<jet> Florian: I did a bunch of testing ^

<jet> Florian: shows how browsers differ

<jet> Florian: more interop than expected

<jet> Florian: Safari & Edge are the same

<jet> Florian: Chrome differs

<jet> Florian: Firefox differs

<jet> Florian: when lineheight is a number or length vs. normal

<jet> Florian: refers to diagram from Tokyo discussions

<jet> Florian: (see github issue for diagram)

<jet> Florian: can't figure out Chromium baseline alignment

<jet> Florian: why does chrome behave this way?

<jet> Florian: we should fork the issue for general lineheight

<jet> Florian: we need to define base behavior of lineheight

<jet> fantasai: because rhythm depends on lineheight

<fantasai> fantasai: because the trigger to round up for rhythm depends on the computation of line height

<fantasai> myles_: and you can double spacing in some UAs not others if those computations differ

<fantasai> fantasai: right

<jet> Florian: goal is general interop on lineheight

<jet> astearns: discuss divergence on lineheight:normal

<jet> Florian: can isolate individual bugs

<jet> ACTION: Florian to file bugs with each case

<trackbot> Error creating an ACTION: could not connect to Tracker. Please mail <[email protected]> with details about what happened.

<jet> fantasai: we don't have a spec for these issues

<fantasai> astearns: but we have interop except for chrome

<fantasai> astearns: so Chrome should figure out whether there's a reason to diverge, or whether they will fix it

<fantasai> astearns: and then we can spec the result of that discussion

<jet> Florian: for lineheight:normal Chrome differs by using the top of the tallest used fonts

<jet> Florian: will file a bug on that one

<jet> koji: we need to see the test

<jet> Florian: we'll debug later

<jet> Florian: I had to find fonts with tall ascenders and long descenders

<jet> Florian: Firefox font metrics differ

<jet> Florian: not sure why

<fantasai> myles_: If a browser changes the metrics they read from a font, every web page will look different. At least for us, that would be almost certainly unlikely to happen.

<jet> myles: if a browser changes metrics per font, every web page will render differently

<jet> Florian: in some cases Firefox is the same

<jet> dbaron: platform API's differ for metrics

<jet> koji: everyone has 3 font metrics

<jet> Florian: Chrome & Safari same on Mac

<jet> Florian: Chome & Edge same on WIndows

<jet> myles: some fonts are just weird

<fantasai> myles_: For at least font on at leats one platform, at least one of the metrics of the font returned by the system API doesn't appear anywhere in the font

<jet> Florian: the tests aren't clear re: metrics, but does show the divergence

<jet> Florian: I checked the content box for inlines--also no interop

<jet> Florian: on Chrome, doesnt depend on font metrics or lineheight

<jet> fantasai: spec says content box can't depend on lineheight

<jet> Florian: Firefox depends on font metrics and not lineheight

<jet> Florian: notes Chrome bugs

<jet> fantasai: is it 1 em?

<jet> fantasai: 1 em is at least predictable

<jet> Florian: not 1 em

<dbaron> FWIW, Gecko has 4 platform-specific font backends: (1) FreeType (used on Linux and Android), (2) Mac (3) GDI (Windows) and (4) DirectWrite (also Windows)

<jet> Florian: more testing needed

<jet> Bert: CSS2 recommends 1em or height of the ascender to descender

<Bert> ". The height of the content area should be based on the font, but this specification does not specify how. A UA may, e.g., use the em-box or the maximum ascender and descender of the font. "

<myles_> dbaron: macOS has CoreText and CoreGraphics and they may disagree

<Bert> (This is from CSS2)

<Bert> https://www.w3.org/TR/CSS2/visudet.html#inline-non-replaced

<dbaron> myles_, I think we're using CoreText

<jet> astearns: it differs depending on the platform font subsystem

<myles_> dbaron: 💯

<dbaron> myles_, er, wait, there's a pointer to both objects :-P

<myles_> dbaron: 💯💯✅

<jet> Florian: Firefox differs with Outlines

<dbaron> myles_, InitMetrics seems to use mostly CG* APIs

<jet> Florian: outline allows a lot of leeway

<jet> Florian: and Firefox diverges most

<jet> Florian: please review the tests

<jet> astearns: file the bugs and have the browser engineers challenge

<jet> fantasai: we want interop and sane behavior so file spec bugs not browser bugs

<jet> fantasai: resolve on content box height?

<dbaron> myles_, I think we use Core Text only for fonts with color bitmap glyphs

<fantasai> Florian: we have 3 behaviors, Chrome I can't figure out at all. Doesn't seem to depend on line height or font metrics

<fantasai> Florian: Firefox ....

<jet> astearns: if we file a Chrome bug, we can get interop

<jet> astearns: despite no spec

<jet> fantasai: we should specify what the TTML folks can use

<dbaron> I think there are probably much larger audiences than the TTML folks who care about this.

<jet> Florian: using ascender/descender lengths is unpredictable

<fantasai> dbaron, not sure who that is, but pretty sure they'd agree on having something controllable and predictable

<jet> dbaron: may be concerns re: e.g., accent marks

<jet> dbaron: and script-specific issues

<dbaron> s/accent marks/accent marks not hanging out of the background/

<dbaron> s/script-specific issues/that might be more important for Vietnamese than for English/

<jet> Florian: content box depending on font metrics is very unpredictable

<jet> Florian: we can resolve on Safari/Edge behavior re: lineheight:normal being a bug

<jet> Florian: lineheight != normal returns different sizes

<jet> astearns: curently not a spec violation

<astearns> but we should probably make it one

<jet> fremy: we can't resolve if we don't know what to spec

<dbaron> I think it is a violation of https://drafts.csswg.org/css2/visudet.html#inline-non-replaced

<jet> fremy: please file more specific issues

<jet> Florian: we'll split the topic

<astearns> dbaron: fair - "The 'height' property does not apply <to the content area>" does seem to be relevant

<jet> fantasai: file issues against CSS inline and CSS2

<jet> Florian: I tested 2 ways: line stacking and with border. same results

<dbaron> I guess it's violating the "should" that it's based on the font

<jet> fremy: spec proposes 2 solutions

<jet> fremy: not sure how we choose either

<jet> fremy: I need to check Edge code

<fremy> fremy: but maybe we consider line-height to be intent from authors they want control

<jet> Florian: interop is fixable

css-meeting-bot on 4 Aug 2017

The CSS Working Group just discussed CSS Rhythm.

The full IRC log of that discussion

<jet> Topic: CSS Rhythm

<astearns> https://groups.google.com/forum/#!msg/mozilla.dev.platform/cnEN_sccXJY/1ddo5XifAwAJ

<fantasai> ScribeNick: fantasai

<fantasai> koji: I'd like dbaron to explain his opinion

<fantasai> dbaron: Current approaches are going to lead to things that are fragile wrt behavior between browsers, or even same browser on different platforms

<fantasai> dbaron: where you get double-spacing of line sin unpredictable situations

<fantasai> dbaron: There are alternative approaches which would not lead to this problem

<fantasai> dbaron: But I'm not interested in focusing on this right now

<fantasai> dauwhe: ?

<fantasai> dbaron: Right now not looking at anything

<fantasai> dbaron: I'm discouraging ppl from implementing this feature because I don't think it's something that should be implemented

<fantasai> dbaron: Same issue as [?]

<astearns> s/[?]/double-spacing/

<fantasai> dbaron: Some of the ways to solve it might be to use an entirely differnet design, whereas github issue is trying to keep the same design and trying to find small fixes for double-spacing

<astearns> s/dbaron: Same/koji: Same/

<fantasai> koji: Your concern is different font metrics causing different ? is the problem?

<fantasai> s/ ? / result /

<dauwhe> s/dauwhe: ?/dauwhe: are you concerned about just the inline step sizing, or all of css rhythm?

<fantasai> koji: Original issue was line-height normal causing problems

<fantasai> Florian: There's a general problem and a specific case of that problem

<fantasai> Florian: general problem is when different font metrics or different ways to implement line height or things of that nature cause the layout to work just fine in one browser

<fantasai> Florian: and to be entirely double-spaced or randomly double-spaced in another browser

<fantasai> Florian: That's the general worry

<dbaron> or different font availability

<fantasai> Florian: within that space, this github issue identifies one case where this happens

<fantasai> Florian: if this is the only case where this happens, maybe dbaron's worry goes away

<fantasai> Florian: If there are more instances of similar worries, we'll need lots of patches

<fantasai> dbaron: Another major case is font availability, where you have a font available on one platform and not on others

<fantasai> koji: I heard one example

<fantasai> koji: but dbaron's concern seems to be a different case

<fantasai> Florian: it's the same

<fantasai> Florian: if line-height-step is a user-defined specific value

<fantasai> Florian: and line-height is a different user-defined value

<fantasai> Florian: then this is generally predictable

<myles_> q+

<fantasai> Florian: if line-height is smaller than line-height-step generally okay

<fantasai> Florian: If there's one line that has a superscript and double spaced that line it's kindof okay

<fantasai> Florian: but double-spacing entire the page is a problem

<fantasai> Florian: If you set [various combinations, varous results]

<fantasai> Florian: Different fonts, different ways to read metrics from the font, different implementations of what 'line-height: normal'

<fantasai> Florian: cause differences

<myles_> q-

<fantasai> dbaron: I'm not sure that even line-height: <number> is predictable, requires testing mix of elements

<dbaron> ... where some have font fallback

<dbaron> fantasai: another case that could cause problems is different line wrapping,e.g., if superscript and subscript end up on the same line

<fantasai> Florian: Point of feature is normalization of line heights so a few lines double-spaced probably okay, but all lines not good

<fantasai> Florian: primary font doesn't have CJK and other font does, then many lines with mix of fonts

<fantasai> Florian: line-height to specific number, it's okay

<fantasai> Florian: but if you have spans in the middle of that, you might trigger problem often

<dbaron> fantasai: it's broken if the author sets something precisely expecting no gaps in the general case; they'll be upset if they see gaps

<dbaron> fantasai: you won't have a case that's extremely painful for the user

<Rossen> fantasai: it's definitely broken if the author didn't expect any gaps but there were some. If there are few gaps there shouldn't be that much of a confusion

<fantasai> astearns: author shouldn't use this if they don't want double spacing

<fantasai> jet: on dev.platform, was a question of whether authors really want this feature

<fantasai> q+

<astearns> s/don't want/can't stand occasional/

<fantasai> jet: Haven't heard demand from authors outside Koji here in this room

<fantasai> jet: Do people want that

<fantasai> Florian: People do want vertical rhythm, absolutely

<myles_> jet++

<fantasai> jet: Chromium has it behind a flag, have people been building websites with it and saying "yes I absolutely want this", haven't really seen that

<astearns> ack fantasai

<jet> fantasai: people want vertical rhythm, but is this the feature that will solve it?

<jet> fantasai: we want this spec to be robust and integrate with the rest of CSS elegantly

<jet> fantasai: I don't think this feature fits that description

<myles_> fantasai++

<tantek> fantasai++

<dauwhe> fantasai+^+^+

<fantasai> fantasai: Our goal for features we design here in the CSSWG is to be flexible, robust, poweful, easy-to-use, and understandable

<fantasai> fantasai: We intend for them to fit within, integrate with, and enhance the CSS system

<fantasai> fantasai: Not be a hacky workaround to some particular issue

<fantasai> fantasai: I don't believe this feature fits that design requirement.

<fantasai> fantasai: Additionally, I don't think it does a good job of addressing the use cases

<fantasai> fantasai: Absolutely, people want control over vertical rhythm

<fantasai> fantasai: But their problems aren't largely about lines within a long wrapped paragaph of text being slightly off-kilter

<fantasai> fantasai: The breaks in rhythm are largely introduced by block-level interjections in the flow of text

<fantasai> fantasai: Things like headings, figures, tables, and block-quotes

<fantasai> fantasai: This feature does not address these use cases

<dauwhe> q+

<fantasai> fantasai: It at best allows a hack of turning these block-level elements into inline-blocks in order to use this feature to control rhythm.

<fantasai> fantasai: I don't believe this feature is well-designed.

<Florian> q+

<fantasai> astearns: I absolutely agree that block-level interjections are also a problem, but I don't agree that they're worse than line box stepping

<dbaron> fantasai: much of the jitter in line boxes is due to...

<tantek> q?

<astearns> ack dauwhe

<fantasai> koji: I thought kobayashi-sensei explanation in Tokyo was more understood

<fantasai> koji: discussion wasn't

<fantasai> koji: what he said was what Alan said

<fantasai> koji: not sure about Latin, but for Japan

<Rossen> q+

<fantasai> koji: what he said was when block-level interjection is big enough he wants other factors wins over getting back to original rhythm

<fantasai> astearns: my impression was that his opinion was that it was acceptable but still not enough

<fantasai> koji: I talked with ppl who attended, ppl agreed with me

<fantasai> koji: maybe translation problem

<fantasai> koji: What he explained was vertical wrhythm when objects intervene

<fantasai> koji: Should be done like justification, so that each text block and image and blockquote are like characters in the "line box" of the page

<fantasai> koji: each space to have equal lenght is more important than returning to the rhythm

<fantasai> koji: line grid can do it, or maybe other features, but then have to adjust grid after intervening objects

<Rossen> q-

<fantasai> koji: but line-height-step or block-height-step doesn't have this problem

<fantasai> koji: What sensei didn't say, is making block height to step

<fantasai> dauwhe: A couple things, one is that I would love to see some East Asian examples of how this feature fixes problems of East Asian typography

<fantasai> dauwhe: examples have been in Latin, so hard for us to see the goal of this feature as designed

<fantasai> dauwhe: Also want to say that wrt Latin typesetting in general, I agree with fantasai

<fantasai> dauwhe: Last thing we want to change is line height of the blocks. This is the worst result, lowest priority. Prefer to adjust spacing around blocks

<astearns> ack Florian

<fantasai> dauwhe: So I would like to see more targeted use cases for the case of East Asian, since in Latin this is not as appropriate

<fantasai> Florian: In Latin text, you have ascenders and descenders so the visual edges of the line is irregular

<fantasai> Florian: Whereas in CJK if the spacing is irregular, it is very obvious

<Rossen> q?

<fantasai> Florian: So a small superscript that sticks out and slightly shifts the line is really bad

<fantasai> dauwhe: it's pretty bad in Latin, too

<Rossen> q+

<fantasai> Florian: So that is one part

<fantasai> Florian: Another response is to fantasai

<fantasai> Florian: wrt her design goals of CSS

<fantasai> Florian: Early incarnations of this feature were very much not robust

<fantasai> Florian: We have made changes to decrease its powerfulness to increase its robustness

<fantasai> Florian: I don't think it's robust enough yet

<fantasai> Florian: When I'm done with fixing interop on line height, then will look at robustness of this feature

<fantasai> Florian: I'm not sure we can make this feature robust enough, but either way this depends on how we fix interop of line height calculations

<fantasai> koji: We seem to be discussing two topics, one is fundamental design and the other is this problem of oduble spacing

<fantasai> Florian: The design of this feature makes it easy to use in some cases and very broken in others. If we can't fix this, we can't use this feature

<fantasai> koji: Fundamental to vetical rhythm that some authors want to take as much step as font metrics says

<fantasai> koji: if font is taller, want to take more steps, as much as needed to fit font

<fantasai> koji: whereas in some cases we consider accidental

<fantasai> koji: and that happens in line grid, too

<Rossen> q?

<fantasai> astearns: Same concern about accidental double spacing of everything is a problem both for rhythm and for line grid

<fantasai> astearns: and we can't take either of the proposals if accidental double spacing of everything is prevalent enough to be a problem

<fantasai> astearns: Accidental double spacing is prime example of the design flaw

<fantasai> astearns: still talking about double spacing

<fantasai> koji: what if double spacing happens in line grid, too?

<fantasai> myles_: I don't think anyone has made the argument that line grid should ship instead of this

<fantasai> myles_: people are simply objecting to this feature on its own merits

<astearns> ack Rossen

<fantasai> (or lack thereof)

<fantasai> Rossen: First comment about jet's comments

<fantasai> Rossen: What jet mentioned earlier about lack of examples / requests, we've had a lot of requests internally

<fantasai> Rossen: mostly ppl building multicol based layouts

<fantasai> Rossen: fairly impossible to make things align in terms of line breaks

<fantasai> Rossen: To that point, what fantasai said earlier whas right on the money

<fantasai> Rossen: Most of the problems aren't due to lines, they're mostly due to headings and other blocks that are not multiples of line height

<astearns> headings are not lines?

<fantasai> astearns, no, but I can't explain and minute...

<fantasai> :/

<astearns> (I know they're blocks)

<dbaron> Florian: his comment was looking for evidence that this particular solution addresses the use case, not evidence that the use case was important

<dbaron> s/his/jet's/

<fantasai> Rossen: I was hoping to know, it's been already 1.5-2yrs that we've been working on this

<tantek> q

<tantek> q?

<fantasai> Rossen: It's certainly the case that in CJK the use cases seem to be predominatnly based on just lines and line sof text without that much blocks or other things int he flow that contribute to irregularity

<fantasai> Rossen: in those coases perhaps line grid makes sense, maybe that's the best thing to do there

<fantasai> Rossen: at the same time, most of the objections I hear constantly against it

<tantek> q+ to ask how long has Chrome been shipping it behind a flag? and shouldn't we see at least experimental sites using that in the wild by now?

<fantasai> Rossen: are based on the other sets of requirements

<fantasai> Rossen: which are for multicol block-level stuff we were talking about

<fantasai> fantasai: No, there's two sets of objections one is the block-level concerns the other is the robustness concerns

<TabAtkins> ScribeNick: TabAtkins

<TabAtkins> fantasai: part of the robustness concerns is all this non-interop stuff for line-height in general is part of it

<TabAtkins> fantasai: Other thing is that the way we do line-height calcs in general creates jitter.

<TabAtkins> fantasai: So even if we have line boxes with same height, that doesn't the jitter case that CJK needs us to solve.

<TabAtkins> fantasai: So even without browser variance, even with a strict vertical rhythm, within the linebox the line moves, and line-height-step doesn't fix that.

<myles_> Rossen: Many of the requests that we (Microsoft) has had for this style of feature are caused by interjecting blocks in between many flowing lines of text. [myles: therefore those aren't solved by this particular solution]

<TabAtkins> fantasai: So if your concern is within a paragraph keeping a rhythm, we need to fix interop and maintain the baseline-to-baseline height.

<Florian> q+

<TabAtkins> fantasai: Beacuse of the way we center content in the linebox, if the content is slightly larger but doens't spill out of th elinebox, it'll center.

<fantasai> s/center/jitter/

<TabAtkins> koji: If you solve that, even when you do, if the font-size is differnet, you'll still need line-height step.

<TabAtkins> koji: So it doesn't seem to be a reason not to do line-height-step.

<TabAtkins> fantasai: The only case you need l-h-s is if, in the middle of a paragraph, you want to double-size a particular line because it includes larger content.

<fantasai> q+

<astearns> ack tantek

<Zakim> tantek, you wanted to ask how long has Chrome been shipping it behind a flag? and shouldn't we see at least experimental sites using that in the wild by now?

<dbaron> I could bring back line-box-contain with stepping extensions that I think would be more robust, at least for some values of line-box-contain.

<TabAtkins> tantek: How long has Chrome been shipping this behidn a flag?

<TabAtkins> koji: a year or so

<TabAtkins> tantek: For a feature we all agree conceptually there's demand for, we should have seen at least a handful of experimental demo sites using them.

<TabAtkins> tantek: We haven't seen that, or if we have, please provide the urls.

<TabAtkins> tantek: Second is, I'm increasingly concerned with shipping features that almost work, but are fragile and easily break.

<TabAtkins> tantek: Having witnessed all the float/columns confusion, having it break easily, that makes people distrust CSS as a whole.

<TabAtkins> tantek: Would be unfortunate to have the whole concept damaged as a result.

<TabAtkins> tantek: So that's why providing the block-level solutions might make it just dependenable enough to make it usable in production.

<TabAtkins> tantek: It won't be perfect, but can it be reliable enough.

<fantasai> astearns, the reason I'm saying that headings aren't lines isn't that they aren't made up of lines, of course they are. But generally the problem isn't havng each individual line snap to a multiple of the base line height, it's having the heading as a whole snap to that multiple.

<fantasai> astearns, because for headings you don't want to have large line heights or gaps between the lines

<astearns> fantasai: let's talk about this after

<TabAtkins> koji: I tried to talk to some webdevs; my feeling so far is that the experimental flag buidling sites works in US, but not in intl, where pops are smaller and people are less willing to spend effort helping standardization.

<fantasai> astearns, you usually want them quite tightly spaced, in fact, because they are a larger font size

<TabAtkins> koji: So they generally say "we'll try when it ships, but can't spend much time before that".

<fantasai> astearns, but you want space around them, and you want the total space taken up by the heading -- like the total space taken up by a figure or table or blockquote -- to fit into the rhythm

<TabAtkins> koji: For robustness, as far as I understand, your "robustness" is different from fantasai's concept.

<TabAtkins> tantek: Could be.

<TabAtkins> koji: I think you're more about accidental jumping.

<TabAtkins> koji: I think earlier we were talkinga bout, when we get the future stack thing - if it gets off the grid, it accumulates.

<TabAtkins> koji: That part is design - Japanese vertical rhythm is different from Latin's.

<astearns> ack Florian

<TabAtkins> Florian: Earlier fantasai was saying that this feature isn't quite good enough; while it solves locally the size of the line, it doesn't do the position.

<TabAtkins> Florian: Earlier feature did address that, but made it more fragile.

<TabAtkins> astearns: It solved that using the baseline ratio.

<TabAtkins> Florian: So that's a bit of the difficulty with this feature.

<TabAtkins> Florian: I haven't given up hope, but I don't know if at the end of the process it'll still be useful.

<TabAtkins> Florian: Currently kinda useful and kinda fragile; was earlier more usefula nd more fragile; will it be useful at all?

<TabAtkins> Florian: So we have a feature that's either too fragil eand not useful enough, or one that's too difficult to figure out.

<TabAtkins> Florian: Otoh, there's a simple and useful feature that solves the block side of the problem, which we most agree isn't quite enough.

<TabAtkins> Florian: But I don't think anybody thinks the block feature is insufficiently robust, or not useful.

<TabAtkins> Florian: So I recommend people start on that, rather than being stuck.

<TabAtkins> Florian: As to whether this is still useful when it's robust, dunno.

<TabAtkins> Florian: IN parallel, I think it would be nice to try and make line-grid simpler in terms of impl.

<TabAtkins> Florian: Nobody's been willing to bite the bullet yet.

<TabAtkins> Florian: If someone can find a magic solution, prizes!

<TabAtkins> fantasai: I don't think that finding the third solution is as impossible as you think.

<dbaron> q+

<TabAtkins> fantasai: First, we need to solve the jitter problem.

<TabAtkins> fantasai: We're wasting our time if we don't solve that.

<TabAtkins> fantasai: Requirement for any solution, and it's not specific to l-h-s or line-grid

<TabAtkins> fantasai: We just need to fix line layout.

<TabAtkins> fantasai: We need to continue and prioritize the work that florian has been doing, to fix line layout.

<TabAtkins> fantasai: Second, we need examples of where this specific feature is a solution to a problem.

<astearns> ack fantasai

<TabAtkins> fantasai: I think this is solving a problem of fixing line-heights within a wrapped paragraph, by doubling the spacing of that line, and I dont' think anyone wants taht in general.

<astearns> ack dbaron

<TabAtkins> dbaron: I think one thing we should look at to address this is having whatever the solution is be a bit more of a mode switch than what we're looking at.

<TabAtkins> dbaron: To some degree line-grid is such a mode switch.

<TabAtkins> dbaron: 14 years ago I had a proposal for line-box-contain, in the ED for linebox for a decade, shipping in Safari for a bit...

<TabAtkins> dbaron: That tried to add all the detail for how to consider what should affect the linebox.

<TabAtkins> dbaron: But to a good extent there's only three values that are important.

<TabAtkins> dbaron: One is what we do in quirks mode, one is what the specs say, one is what devs actually want.

<TabAtkins> dbaron: it's a little complicated, but it's in the spec, hard to find.

<TabAtkins> astearns: So in addition to box-sizing, we should have line-sizing?

<TabAtkins> dbaron: Not where I was going.

<TabAtkins> dbaron: One of the things is that you have a property that says "i want a line grid at a certain size". Whether it's a full-fledged grid or a slightly weaker thing.

<TabAtkins> dbaron: I suggest that, once that grid is established and for all the blocks that use it (presuming you can turn it off for some descendants), we switch line layout to another mode.

<TabAtkins> dbaron: WE stop stupid things, like honoring line-height on inlines.

<fantasai> dbaron+++++++++++++++++++++++++++++++++++++

<TabAtkins> myles_: +++++

<dauwhe> tell it, brother!

<TabAtkins> dbaron: Only honor line-height on boxes. Honor border or margin-box size on inlines, so if they actually overflow the line, they make it bigger.

<TabAtkins> dbaron: But if you're at line-height:1.25, you don't get the 1.25 buffer on them.

<TabAtkins> dbaron: And from there we can figure out baseline alignment to the grid.

<TabAtkins> dbaron: So I think having a non-inherited proeprty that establishes a line grid or step-sizing space, is better than an inherited mode switch, like line-box-contain was, because it serves another purpose as wlel.

<TabAtkins> dbaron: While it has some mode-switching purposes, mode-switches aren't that great. Doesn't cascade well.

<gsnedders> dbaron++++++++

<TabAtkins> dbaron: Has some of the effects of a mode switch, but not all of them.

<TabAtkins> iank_: A new inline layout...

<TabAtkins> dbaron: Not that different. Still doing inline layout.

<TabAtkins> dbaron: line-box-contain had a bunch of values that were like "block", "inline", "replaced", "text", "ruby", "glyphs"...

<TabAtkins> dbaron: When you did your linebox height calc, you looked at the list and only considered those.

<TabAtkins> dbaron: The standard behavior is "block inline repalced" i think

<Bert> https://www.w3.org/Style/Group/css3-src/css3-linebox/#LineStacking

<TabAtkins> dbaron: Quirks mode is more like "text replaced" or something

<TabAtkins> dbaron: But people don't really want inlines considered at all, you just don't want glyphs to overlap by default.

<TabAtkins> dbaron: The principle isn't complicated, it's just a new step in line layout that controls what you consider.

<TabAtkins> dbaron: The mode switch would be about changing what you consider in that step.

<TabAtkins> myles_: I think it's still in WK prefixed...

<TabAtkins> iank_: It's removed from Blink.

<TabAtkins> astearns: See if it helps enough for this use-case?

<TabAtkins> myles_: Which? ^_^

<Florian> q+

<fantasai> s/Which/Which use case/

<TabAtkins> Florian: Having discussed a variant of this for several times, I think coming back in a few months with the same discsussion isn't helpful.

<TabAtkins> Florian: I think it's clear that koji and fantasai disagree on whether robustness is important/etc.

<TabAtkins> Florian: I think it's important if koji could show sites using this feature in ways that trigger double-spacing, and say "yes, this is what the author wants".

<TabAtkins> fantasai: No, you want sites using the feature that show why this is good, and the other alternatives aren't necessary.

<TabAtkins> astearns: We want to evaluate the shipping solution, to see if it addresses the use-case.

<TabAtkins> astearns: We have a shipping solution, we should have evidence that it's enough for some set of people.

<TabAtkins> Florian: And specifically, I want to see these examples hit the conrer cases, without authors getting bad results.

<TabAtkins> astearns: Whether the extant examples hit the corners or not, we can use them to push them into the corners.

<fantasai> s/aren't necessary/can't solve it/

<TabAtkins> Florian: Other than that, I don't think it'll be useful to have elika tell koji it's not useful, and koji saying it is...

<TabAtkins> koji: I'm saying tha trobustness is different between Latin and CJK.

<TabAtkins> Florian: Sure, I'm not trying to rephrase; it's just that rehashing the same discussion without new info isn't useful.

<TabAtkins> Florian: In the meantime there are concrete things we can work on, like improving lineboxes. Maybe dbaron's stuff

<TabAtkins> Florian: In the meantime just rehashing is harmful, it blocks us from doing similar things.

<TabAtkins> tantek: I think this conversation has brought up some new stuff.

<TabAtkins> fantasai: My and dbaron's points were brought up in Tokyo.

<Bert> (A public link: https://www.w3.org/TR/2001/WD-css3-box-20010726/#the-line-box-contain )

<gregwhitworth> Decent amount of vertical rhythm libs in CSS & JS: http://kyleshevlin.github.io/shevy/

<TabAtkins> tantek: I think some new stuff, like eamples that use it

<TabAtkins> astearns: And I think line-box-contain is new.

<TabAtkins> tantek: So I think it's not fair to say it's a complete rehash.

<TabAtkins> astearns: But I agree we need examples, "this community won't turn on a flag" isn't a good enough response.

<TabAtkins> koji: Why doesn't printed material show this?

<TabAtkins> astearns: We need examples of this particular solution trying to solve things.

<TabAtkins> Florian: Looking at print doesn't help here; it illustrates there is a problem to solve, but not that this solution in particular solves the problem.

<TabAtkins> koji: Word isn't print - if you look at a word doc with different installed fonts, you get a similar problem.

<TabAtkins> Florian: Usually that happens because of switching between Word and OpenOffice, and people hate it.

<TabAtkins> Florian: I'm saying that showing examples of other things doesn't help us see if your solution solves stuff.

<TabAtkins> koji: If you require that of every i18n feature, we'll never get it done...

<TabAtkins> Florian: We're not asking for everything, just for controversial things.

<TabAtkins> myles_: And there's another possible solution - dbaron's l-b-c.

<TabAtkins> astearns: Even without another, this particular solution has enough controversy that we want to see successful use of it in the wild.

<myles_> I meant line-grid in addition do dbaron's idea

<TabAtkins> astearns: Anything else to go into?

<gregwhitworth> worth noting -webkit-line-grid is on chromestatus

<gregwhitworth> none of the rhythmic sizing props are

<TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/938

<gregwhitworth> ^not sure if chromestatus shows experimental flag items or not

<TabAtkins> koji: Yeah. There are mutliple issues in here.

<TabAtkins> koji: ONe issue has a proposed solution, shane and tab came up with.

<TabAtkins> koji: It's about avoiding accidental jumps.

<TabAtkins> koji: I undersatand it doesn't solve all, but I want people to udnerstand the proposal and see if it solves part of the problem.

<fantasai> TabAtkins: So the ultimate problem is that when line-height is normal, it's unpredictable

<fantasai> TabAtkins: So if you set a line-height-step anywhere near the normal value, might look good on your screen not on others'

<fantasai> TabAtkins: proposal is that if lineh-height is normal and result of that would give you a light-height stlightly over your normal line-height

<fantasai> TabAtkins: based on some UA threshold of fuzziness

<fantasai> TabAtkins: Instead of doubling spacing, reduce to line-height-step

<fantasai> TabAtkins: It should hopefully correct any accidental slight overlap that you run into

<fantasai> astearns: why UA-defined squishiness

<fantasai> TabAtkins: figure out the right value later

<fantasai> TabAtkins: if we can agree on one later, great, but otherwise don't want to sink the proposal by arguing over value right now

<fantasai> Florian: I believe I understand the proposal but don't understand why it helps

<fantasai> Florian: If one browser normal is slightly smaller than step, and in toher browser slightly larger, then it helps

<fantasai> Florian: But if in your browser it's slightly larger than normal, but in other browser it's even more larger than normal

<fantasai> Florian: then you get single spacing in yours and double sizing in the other

<fantasai> Florian: So it changes the numbers that trigger the problem, but it doesn't make the problem go away

<fantasai> TabAtkins: Think set of cases that get fixed are goingto be more common than set of things that get broken

<fantasai> TabAtkins: In order tog et broken as you say, you need to set line-height-step smaller than your line-height

<fantasai> fantasai: Line height normal is unpredictable though

<fantasai> Florian: Line height: normal isnt' between 1-1.2, it comes form the font. It might be 2.7

<myles_> q+

<fantasai> Florian: within i18n contexts it varies a lot, even though you don't see it that much in Latin (aside from fantasy fonts)

<koji> q+

<fantasai> TabAtkins: Ignoring fantasy fonts and Zapfino

<astearns> ack Florian

<fantasai> fantasai: i18n

<fantasai> TabAtkins: You said there's larger variation in the consequences of the line box size due to non-Latin character set default fonts

<fantasai> Florian: I believe so, and I think Koji claimed that before I did

<astearns> ack myles_

<fantasai> fantasai: I suspect you're more likely ot get that variation in Tibetan and Thai and other fonts that have lots of diacritics

<fantasai> myles_: I agree that fuzzy matching is a good way to solve language problem

<fantasai> myles_: Implementation knows exactly where all the lines go, so implementation has all the information it needs

<fantasai> myles_: rather more than the author even, cuz author doesn't have font metrics

<fantasai> myles_: so reasonable to have implementation make lines fit well

<fantasai> myles_: previous conversation needs to be resolved before we take this though

<astearns> ack koji

<fantasai> TabAtkins: might want to evaluate solution with this in mind tho

<fantasai> koji: I agree with myles that the accidental jump issue has needs to deal with some heuristics

<fantasai> koji: because in some cases we want to squash really tall fonts

<fantasai> koji: implementation can experiment and maybe a few years later we find very good values and want to standardize it but at this point better to experiment and get feedback

<fantasai> astearns: your experimental implementation, if you can get people to use you can get data on utility of squishiness

<fantasai> koji: Does that solve previous concerns?

<fantasai> astearns: Would anyone object to objecting with this?

<fantasai> astearns: 2nd, would squishiness as described make anyone more interested in this feature?

<fantasai> myles_: not for us

<astearns> s/objecting/experimenting/

<fantasai> astearns: So this squishiness doesn't help other implementers be interested in line-height-step, but seem to be no objections to Google experimenting with it

<fantasai> Florian: No objection to experimentation, less certain about adding it to the spec

<fantasai> koji: If not in the spec, we can't ship it

<fantasai> Florian: I don't want to ship this without a flag unless we have strong evidence that it is less dangerous than people have expressed worries about

<fantasai> Florian: changes to the spec discussed so far don't make me convinced

<fantasai> koji: Why can't you at least suspect it helps?

<fantasai> Florian: I suspect it does not

<fantasai> Florian: I expect it breaks some fixes some and it's a wash

<fantasai> Florian: If it fixes lots and breaks few, pls demonstrate

<fantasai> myles_: Do we need a resolution for Chrome to experiment behind a flag?

<fantasai> Florian: No, they want it in the spec so they can ship it without a flag

<fantasai> astearns: They don't need our permission to experiment, would need permission to add it to the spec even though the consensus of the group is not that the feature is at a point that is OK to ship without a flag

<fantasai> koji: Issue was browsers hard-coded differences in line height calculations triggering different steps, we're trying to solve that, so Chrome doing it doesn't help

<fantasai> astearns: you didn't convince Florian, but myles seems to agree it might help

<fantasai> myles_: please ignore me

<myles_> s/please ignore me//

<fantasai> s/myles_: please ignore me//

<fantasai> dbaron: I agree with Florian's concern that it seems to mostly be moving the threshold and not actually fixing the bug

<fantasai> Florian: I didn't mean that in the long run Chrome should have it and others shouldn't add it, I'm suggesting that the only implementation we have experiment

<fantasai> myles_: 100% of implementations will experiment

<fantasai> Florian: Add squishiness, come back and tell us if it improves the situation

<fantasai> fantasai: Koji's pointing out that we want to find out if there's a problem with interop. Chrome can't find a problem with interop by itself

<fantasai> TabAtkins: To simulate differences in how normal gets interpreted, swap around the font list.

<fantasai> fremy: Or switch from Mac to Windows

<fantasai> astearns: OK, think we're done with rhythm

<fantasai> Meeting closed.

<gsnedders> RRSAgent: stop logging

<RRSAgent> I'm logging. I don't understand 'stop logging', gsnedders. Try /msg RRSAgent help

<gsnedders> RRSAgent: stop

css-meeting-bot on 4 Aug 2017

What about discussing Line Grid first? We have WebKit implementation, so this makes us easier to look at examples.

If you open this jsbin in WebKit:

The 1st box is normal flow without Line Grid. I use Arabic and Myanmar to simulate fallback to taller fonts.
The 2nd box is a copy of the 1st box except it has Line Grid applied. In this box, all lines of Arabic and Myanmar consume double units.
@dbaron mentioned the line-box-contain property in Paris, and fortunately WebKit implements it too, so I applied line-box-contain: block to the 3rd box.

line-grid-double-result

The 2nd box looks perfectly normal and expected result to me, except that author's choice of the rhythm isn't appropriate, but IIUC this issue thinks this result is unexpected and accidental, correct?

The 3rd box is a "fixed pitch layout", not a "vertical rhythm", unless I misunderstand how to use the line-box-contain property. I can see, however, in the 3rd box, some may consider Arabic lines are "improved" for this combination of the unit size, font metrics, and internal leadings (non-ink spaces within the font metrics) of this specific font. Is this specific case this issue is talking about?

If we want this behavior automatically, we need to rely on heuristics, as @shans and @tabatkins proposed, because there's no clear method to distinguish Arabic in this case from Myanmar. Heuristics isn't perfect, it won't work if 1px taller than the heuristic value as @frivoal pointed out in Paris, but I think that's the nature of heuristics. If that happens often, we can adjust the heuristics.

So a couple of questions:

Is this Arabic case this issue is talking about?
If so, do you agree this is a heuristic problem that we need to rely on heuristic solution?

kojiishi on 19 Sep 2017

👍1

agenda+, I'd like to confirm what this issue is about. I thought I understood but lost the confidence in Paris.

IIUC, this issue expects the 3rd (right) box for Arabic, and the 2nd (center) box for others, no?

kojiishi on 25 Sep 2017

I agree that in your example the double-spacing of the Myanmar and large capital text in the second box is largely intentional, and not relevant to this issue.

The Arabic case might be relevant. I think that if there were browser differences in dealing with how the Arabic line height interacted with a line grid such that one browser double-spaced the lines and another did not, that's the case that this issue is worried about. But it looks to me like this example should be fairly clear-cut - the Arabic line-height is several pixels larger than the grid spacing. The third box doesn't look like an improvement to me, because it's tightening the specified line-height too much to squash the lines into the grid.

So I think the example would have to be a closer call for this issue to come into play. The line-height needs to be closer to (and smaller than) the grid spacing, such that there's clear authorial intent to not get double-spaced lines. This issue is then relevant if there are enough differences in text rendering between browsers and platforms that accidental double-spacing occurs.

astearns on 26 Sep 2017

Thank you for the confirmation, that is really helpful.

I agree that in your example the double-spacing of the Myanmar and large capital text in the second box is largely intentional, and not relevant to this issue.

This is great, this is I was most worried about. Having your thoughts helped me a lot, thank you.

The Arabic case might be relevant. I think that if there were browser differences in dealing with how the Arabic line height interacted with a line grid such that one browser double-spaced the lines and another did not, that's the case that this issue is worried about.

Great again, thank you. Yeah, there will be differences by browsers/platforms, both in Line Grid and Rhythmic Sizing, because font metrics of the same font name varies by platform or even by versions of the same OS, and as we figured out, how browsers compute the height of line-height: normal vary.

What I don't understand is, how we could solve this when things are working exactly as intended by font designers but does not match to authors intention. I'm feeling we need to rely on heuristics, but I'm not confident of this part of my understanding yet.

But it looks to me like this example should be fairly clear-cut - the Arabic line-height is several pixels larger than the grid spacing. The third box doesn't look like an improvement to me, because it's tightening the specified line-height too much to squash the lines into the grid.

Great, so you think Arabic should do the 2nd box, do I understand correctly? I agree, and I was afraid people prefer the 3rd box. If a browser with the hard-coded minimum of line-height implements Line Grid, it will produce the 3rd box. Is this difference what we want to solve in this issue?

So I think the example would have to be a closer call for this issue to come into play. The line-height needs to be closer to (and smaller than) the grid spacing, such that there's clear authorial intent to not get double-spaced lines. This issue is then relevant if there are enough differences in text rendering between browsers and platforms that accidental double-spacing occurs.

I don't understand this paragraph...are you suggesting to change the example?

kojiishi on 26 Sep 2017

I am suggesting the example needs changes. As it is, it does not seem relevant to this issue to me.

astearns on 26 Sep 2017

Google Translate helped me for the first sentence, then understood the rest. Did you write "smaller" when you want "slightly larger"? If the used line-height is smaller than grid, there will be no double spacing.

To adjust the used line-height in details, I need to look into font metrics value in the debugger, but I don't have WebKit build right now. I'll try to get one, but it looks like my understanding of the problem is correct. My next question is do people agree this is a heuristic problem, but let's discuss in the call.

kojiishi on 27 Sep 2017

The Working Group just discussed Avoiding accidental double spacing.

The full IRC log of that discussion

<dael> Topic: Avoiding accidental double spacing

<tantek> is it just a button? I thought this was the first draft on the new system?

<dael> github: https://github.com/w3c/csswg-drafts/issues/938

<tantek> thanks astearns, noting here FTR: https://drafts.csswg.org/css-multicol/#changes

<koji> https://github.com/w3c/csswg-drafts/issues/938#issuecomment-330561882

<dael> koji: The biggest problem for me isI'm failing to understand definition. I made this example ^

<dael> koji: astearns gave me feedback that...the left most in the e xample is normal. Second I applied line-grid. I applied line-box contain to third.

<dael> koji: Second block has some double spacing but astearns says they're all intentional. Is that common understanding within this group?

<dael> myles: I think you're asking me?

<dael> florian: Everyone.

<dael> koji: Yeah. We need to distinguish intentional and accidental double spacing and there isn't a clear definition.

<dael> koji: The second box is [missed] it happens accidental when font metric is only slightly larger. is that correct?

<dael> astearns: one thing I missed when I commented is that in your example you are not chaning line height. it's all the same, but there are some fallback fonts making some lines taller.

<dael> koji: Correct. it started with line-height normal and it does double step.

<dael> astearns: Right. With that new understanding I believe you are correct that this is an example of the problem stated by the issue. 2nd is accidental line spacing because the author had line height normal and the grid set to something without double spacing.

<rachelandrew> someone will need to point me to how to publish the WD, me being a newbie.

<dael> astearns: IN my mind this is an intentional result of the feature. You use rhythm to get consistant spacing, but the content is such that you don't get it, so the spacing is forced by the grid so the result is what authors should expect.

<dael> koji: Okay.

<dael> koji: Are you saying this is intentional or acicdedntal?

<dael> astearns: Accidental in that if the author didn't know what content would go into their grid, they didn't have control over the fonts used, the person settin gup line grid might not have expected it. But they chose a rhythm, chose a grid, so we're fitting author intent of using a grid.

<dael> astearns: I think this is an example o f the issue as stated. I personally don't think the issue is terrifically important because author said they wanted to use a grid or rhythm.

<dael> koji: Thank you, that is exactly my understanding. florian do you have different opinion?

<dael> florian: I'm struggling with how to say my opinion in 10 minutes when in last F2F we tried to discuss and didn't conclude in 2 horus.

<dael> florian: I think when you have a case of line-height normal and then step to a value and large fallback the feature works as intended. Similar case, technically, is line-height: normal line-height-step to a specific value, and the main font on the engine happens to be a little too big and everything is double spaced. That' snot what authros want and I don't know how to fix that.

<dael> florian: First problem happens with line-grid but the second one you don't have the same problem becuase line-grid falls out of main font size.

<dael> koji: but if you go to single grid in that case lines overlap. Grid is fixed height, line-height is normal, and main font is lager.

<dael> florian: Line-grid you don't set it. That's the point.

<dael> koji: what you're saying is line unit is fixed size and line-height: normal and the primary font is taller then spec. unit. Is that the case?

<dael> florian: I think yes, I didn't hear you clearly.

<dael> koji: If you compress the font to a single unit they overlap. You said the font is taller then the unit, right?

<dael> florian: What unit?/

<dael> koji: Let me confirm. You said unit is fixed size.

<dael> florian: I said line-step-height is fixed, line-height is normal. That font on that system gives a line-height taller then step you set for primmary font.

<dael> koji: If the font is taller and you try and fit in a single step you overlap, right?

<dael> florian: Line-height is normal. They're larger then your step so you double space everything.

<dael> koji: Yousaid that's a problem?

<dael> florian: Yes.

<dael> florian: Double space everything is a problem if the rhythm works in general and some fallback is taller that's working as intended. If everything is double spaced that's not working as intended.

<dael> florian: Primary font...I can't do this in 5 minutes.

<fantasai> florian: I tried for hours and failed.

<dael> koji: [missed] We mostly discussed which features people break and htat's not related.

<dael> Rossen_: For the sake of furthering this, I think in summary I've heard that florian's main objection is in case of fallback font being slightly lrge then primary you will have double spacing when fallback font is used.

<dael> florian: That is how it works and ingeneral not a problem.

<dael> Rossen_: And because of this you expect everything will have double spacing?

<dael> florian: No, what I'm saying is when the autho sets a value for line-step-height they don't know what the result of line height calculation will be so they cannot set it in a reliable way. So there is a possibility that things will look right on one browser and not in the other because different font metrics. That's not what hte author wants and a limmitation. The double space everywhere on every brwoser is what's wanted.

<dael> koji: I think I understand your point much better. I'll prepare another test to see if my understanding is correct.

<dael> Rossen_: Sounds great. How about we try and wrap here. Seems like there's more clarity for koji in test cases you need to look at. Why don't you create the test cases and bring them back.

<dael> Rossen_: We'll take time during F2F on this, but if we can resolve before even better.

<dael> Rossen_: Okay for both of you?

<dael> koji: Okay for me.

<dael> florian: I have no obj to koji trying things out. I don't think it'll change what I think of this feature.

<dael> Rossen_: That's the top of the hour. Have a great day/night and we'll talk next week.

<tantek> next week is different time right?

css-meeting-bot on 27 Sep 2017

I agree with the point Florian made in the minutes above. The problematic case isn't one where there are some fallback fonts that cause things to be double-spaced. The real problem is if there's a fallback that causes everything to be double-spaced.

The simplest example I can think of is one where you have two fonts that the author specifies - FontA and FontB. FontA is present on the developer's machine, but they know it isn't present on some other platform so they list FontB as a backup. All of their content can be rendered in FontA or FontB. Unfortunately the developer does not know that FontB has metrics that make the default line-height slightly larger.

As currently defined, with line-height-step the author has to choose a value, and they will choose one that works with FontA. If the value they choose is too small, all of their content will be double-spaced on the FontB platform.

As currently defined, with line-grid the author does not choose a value. By default the line grid will be established by the font metrics of FontA on the developer's machine, and by the font metrics of FontB on its platform (since it's the first available font). So content will not be double-spaced with line-grid in this case.

Is this a fair restatement of the issue, @frivoal?

astearns on 27 Sep 2017

Is this a fair restatement of the issue?

Yes, this is excatly what I meant.

In addition, I'll also note that similar things can happen even if the author only specifies "FontA", in several different scenario:

Similarly to what you said above, FontA is available on one system but not the other. On the other, instead of FontB, you get some default system font. Otherwise the logic is the same.
"FontA" is a webfont defined through an @font-face, and there's some network connectivity issue of some sort, and FontA doesn't get downloaded, so you get some default system font instead, and get the double spacing vs not double spacing problem without even having to change browser.
The font metrics of "FontA" are computed differently by different browsers. For an example, see this font I was using in line-height tests: https://github.com/frivoal/web-platform-tests/blob/line-height-experiments/css/css-line-height/support/Revalia.woff Chrome gives this font a significantly taller line-height than firefox does. So for this font, if an author developped the page on firefox and picked a size that worked fine there, you could get double spacing everywhere in Chrome despite using the same font.

frivoal on 29 Sep 2017

Thank you for your replies, it gave me a new understanding of the problem.

Is this issue suggesting to add e.g., auto to compute the step unit from the used line height? If that's the case, I'm ok with it, it's just not in any use cases and no one made such requests ever.

With Line Grid, as far as I talk to web developers, they normally want different line height from grid, so their usual CSS looks like:

.line-grid {
  line-height: 1.4;
  -webkit-line-grid: create;
  -webkit-line-snap: contain;
}
.line-grid > * {
  line-height: 1.2 or normal or some other values;
}

If author uses normal to make the design i18n-friendly, here is the modified example jsbin (again for Safari to view). As you can see it, if the content uses taller fonts, there's a fallback that causes everything to be double-spaced.

2017-10-03 4 07 35

So I don't see much differences, but I understand our assumption on how authors use Line Grid is different, and if auto can save some English cases, I'm fine to add it.

kojiishi on 2 Oct 2017

👍1

Is this issue suggesting to add e.g., auto to compute the step unit from the used line height? If that's the case, I'm ok with it.

I don't think that is what was being suggested, but I suppose it would make things better.

As I said in https://github.com/w3c/csswg-drafts/issues/938#issuecomment-292444751:

When setting the line-heigh-step, you (almost?) never want to set it to something smaller than the line height of the element that establishes the rhythm.
When inheriting line-height-step, you do want it to be able to be smaller than the line height of the element it is inheriting into. That is what enables things like titles to be enlarged to a multiple of the step size.

This means that if we go with an auto value, we probably needs to reuse a logic similar to the one I suggested in https://github.com/w3c/csswg-drafts/issues/938#issuecomment-292444751, where auto computes to the height of the line in px. That way, when you set something to auto, it gets the right height, but it keeps that same height when inheriting on descendants, preserving the rhythm.

So that would give us something like this:
line-height-step: none | auto | <length>:

none computes to (or behaves as, I don't care) 0
<length> does the same as what the spec says now
auto computes the height in px the line would have if it only contained the strut.

And this should come with a large warning telling authors to use auto rather than <length> to avoid interop problems.

Or maybe a slightly more expressive vairiant (based on what I suggested back then):
line-height-step: none | auto | [ <length> [ safe | unsafe ]? ]

none computes to (or behaves as, I don't care) 0 unsafe
auto computes the height the line would have if it only contained the strut, in px, unsafe
if both safe and unsafe are omitted, it is the same as safe
<length> unsafe does the same as what the spec says now
<length> safe computes to max( auto, <length>)

I like that a better because:
1) It is a little more expressive
2) it forces authors to type "unsafe" to get the behavior that has interop risks, and hopefully this will have enough of a deterrent effect that things will be alright.

So I don't see much differences, but I understand our assumption on how authors use Line Grid is different, and if auto can save some English cases, I'm fine to add it.

I do not think this has anything to do with English vs Japanese. The example @astearns gave in https://github.com/w3c/csswg-drafts/issues/938#issuecomment-332631897 and the ones I gave in https://github.com/w3c/csswg-drafts/issues/938#issuecomment-332999350 are equaly likely to happen in any language.

frivoal on 4 Oct 2017

Great, we're getting to the consensus.

When setting the line-heigh-step, you (almost?) never want to set it to something smaller than the line height of the element that establishes the rhythm.

People wants half-rhythm. This doesn't align lines across columns, but still gives a good rhythm, and consumes less spaces, and that this is suitable for mobile scenario. For this use case, safe/unsafe doesn't express its intention very well.

none was discussed before, but fantasai didn't like having two ways to turn it off, and we can't eliminate accepting 0, so it was removed.

So, shall we start with auto | <length> and see what it happens?

Also are you ok to add <length> to Line Grid as well? This is the largest feedback I've got so far in terms of numbers.

kojiishi on 4 Oct 2017

If you're getting feedback that line grid needs a <length> somewhere, please open a separate issue so that we can discuss the use cases. I haven't been convinced it's necessary.

astearns on 4 Oct 2017

please open a separate issue so that we can discuss the use cases. I haven't been convinced it's necessary.

Ok, thanks, will do so.

kojiishi on 4 Oct 2017

Alan's suggestion above gave me a hint for another idea.

What do you think about

line-height-step: none | auto

?

kojiishi on 5 Oct 2017

agenda+

Proposals

line-height-step: none | auto | [ <length> [ safe | unsafe ]? ]
line-height-step: match-parent | none | auto

Background

As I understood last week, @frivoal is not trying to solve the problem itself but wants to solve by making it harder for authors. I, and IIUC @tabatkins / @shans / @dbaron as well, were all trying to solve, with heuristics or with side effects, so none sounded to him. I didn't understand his proposal because it didn't seem to solve, until I understand he's trying to solve by making harder.

Proposal 1 makes this specific case harder to appear unless author adds unsafe keyword.

Proposal 2 does so unless author adds line-height property twice, once to set to a fixed value and then to set to normal.

I prefer proposal 2, for the simplicity for authors. Also it makes compatible with Line Grid that we can discuss if/how to support <length> for both features together.

EDIT: originally, none|auto but it doesn't work, so match-parent was added.

kojiishi on 8 Oct 2017

The worry I have with going with none | auto to start, then introducing <length> later is that we still run into all the problems described above when you re-introduce <length>. Since auto is not the default it just becomes one of the options, and when the author opts into a <length> the differences between this length and the specified and used line-height all come back into play.

astearns on 8 Oct 2017

@koji, please do not characterize another working group member's efforts as "not trying to solve the problem." Let's continue the discussion here and come to a better understanding of both @frivoal's proposal and @dbaron's new writeup https://github.com/dbaron/css-line-spacing/blob/master/explainer.md before we come back to this on the call.

astearns on 8 Oct 2017

@astearns sorry for my vocabulary, I can't find good words to express "we would like the problem to persist if author added a unsafe keyword." That's what I understood, but great if I were wrong.

Also note that given Mozilla's feedback in Paris, Japanese companies started creating sites. I hope they can use new syntax if we were changing.

kojiishi on 8 Oct 2017

I guess I understood what you mean better now, better way to say it is "solve it by making it harder for authors". Sorry about that, I'll edit.

kojiishi on 8 Oct 2017

For your first comment, I'm thinking we can live without <length>. Hopefully that resolves your concern?

kojiishi on 8 Oct 2017

One more thing; @fantasai tried to solve this issue 6 years ago for Line Grid, but we chose not to solve it. Maybe we can learn from her? (disclaimer; sorry, no offence, "not to solve" is a good word in my culture but it looks like I'm wrong, haven't learned better way to express this.)

kojiishi on 9 Oct 2017

@kojiishi, my proposal had length and unsafe and safe and all that stuff because as far as I could tell, you insisted on having length, and I was trying to make that safer without removing length. As you know say you can live without it, things get much simpler, and we don't need all that stuff anymore.

So, between the current spec and

Proposals

line-height-step: none | auto | [ [ safe | unsafe ]? ]

line-height-step: match-parent | none | auto

I prefer proposal 2, without much hesitation.

On the other hand, I will need a bit more time to think carefully between this vs dbaron's proposal, vs current line-grid, to understand if they are complementary proposals, or if one makes the other unneeded, and if so, which one.

frivoal on 10 Oct 2017

@kojiishi @frivoal While this does seem to be an improvement in addressing some of the concerns, I think it is improper for us to move forward with this feature without any sort of concrete, realistic use case to justify it and to ensure that our design is fullfilling it. I believe @kojiishi had an outstanding action item to provide some, and I think I'd prefer to have those use cases to discuss first so that we actually understand what we're trying to solve before we decide how we want to solve it.

fantasai on 11 Oct 2017

👍1

@fantasai can you open a new issue, or request discussion by e-mail? It's a great feedback, but not related with this issue.

It's a great feedback that it means the Tokyo session was a failure -- it was one of the biggest objectives to get understanding. I think this is hard because both sides discuss based on their common sense, but the common sense is different, and neither side understand how. I'm getting better understanding how Latin vertical rhythm is different, so I think I can do that better next time.

kojiishi on 16 Oct 2017

Another idea from a Japanese feedback is similar to Shane's heuristic idea, but apply the heuristics to the rhythm unit rather than line height. This makes sense to me, because as it was pointed out in earlier comments in this issue, this happens when the rhythm unit is between 1.0 and 1.2. When above 1.2 and if double spacing occurs, it's very likely to be intentional than accidental.

I'll try to summarize proposals so far.

kojiishi on 16 Oct 2017

Summary of proposals so far:

Make it harder for authors
1.1. line-height-step: none | auto | [ [ safe | unsafe ]? ] (@frivoal)
1.2. line-height-step: match-parent | none | auto
Heuristic
2.1. Adjust slightly larger normal height to the unit (@shans @tabatkins, @fantasai's effort looks similar to this)
2.2. Adjust rhythm unit between 1.0 and 1.2 to 1.2
Non-heuristic
3.1. Item 4 of Better spacing of lines in CSS, an explainer (@dbaron)
3.2. line-box-contain: block glyphs, similar to 3.1 but opt-in (Hyatt, 6 years ago.)

Category 1 is not needed for Line Grid, but category 2/3 are probably needed for Line Grid as well.

EDIT: Note, in the comment above, @frivoal said the original intention of this issue is about making it harder, but it looks like Alan and dbaron's proposal extended the coverage of this issue, so this summary includes both. I'm open to discuss these two together, or separately.

kojiishi on 16 Oct 2017

I'd like to check what our current thinking about this issue.

Blink doesn't implement this in LayoutNG, and that all tests are failing in all browsers. If we're clear about what we want here, I'd like to remove the wpt tests to reduce the number of test failures.

Proposal A: Avoid accidental double spacing at all costs

Define that accidental double spacing is a blocker, and should be avoided at all costs.

Technically speaking, accidental double spacing is not avoidable for any kind of vertical rhythms. Taking this policy means that CSS will not support any kind of vertical rhythms. We can then take actions:

Remove all relevant wpt tests. They're just noises today.
Remove the Rhythmic Sizing spec and the Line Grid spec, or put a big warning saying "don't implement until WG changes the policy".

Proposal B: Allow UA heuristic to mitigate accidental double spacing

Define that accidental double spacing is not avoidable and we accept that it may happen in some cases, but allow UAs to add heuristics to mitigate the problem.

IIRC @fantasai raised the concern on Line Grid 7-8 years ago. We discussed and WebKit shipped without heuristics built-in, assuming it can be added if the problem arises.

Proposal C: Accept and should mitigate accidental double spacing, but don't know how yet

The similar policy as the Proposal B; we accept accidental double spacing may happen in some cases, and want to mitigate it, but prefer other methods than heuristics.

I don't know if there were any other methods, so this means that we keep this issue pending, until someone can come up with new ideas.

If we take this option, it is likely to take long until we resolve this issue. I prefer removing wpt tests until then but not strong if anyone think otherwise.

kojiishi on 17 Jan 2020

@kojiishi I think I'm fine to put warning on 'line-height-step' feature and the Line Grid module entirely and remove the tests from the WPT system (as long as we put a note somewhere that we remember where they are in case they become useful to reference in the future). I don't think the block-step feature needs such a warning, though, so I wouldn't put it on the whole css-rhythm spec.

fantasai on 21 Jan 2020

The CSS Working Group just discussed Line grid and tests.

The full IRC log of that discussion

<fantasai> Topic: Line grid and tests

<TabAtkins> ScribeNick: TabAtkins

<fantasai> github: https://github.com/w3c/csswg-drafts/issues/938#issuecomment-575499518

<TabAtkins> koji: we discussed quite a bit on issues for rhythm sizing last time two years ago

<TabAtkins> koji: as far as i understand, this issue was the most blocking for the feature

<TabAtkins> koji: Since then, Blink shipped LayoutNG. I didn't reimplement this in LayoutNG yet.

<TabAtkins> koji: Currently this test fails in all browsers.

<TabAtkins> koji: I don't see a way to solve this properly

<TabAtkins> florian: We talked about multiple solution for the double-sizing. What is the test assuming?

<TabAtkins> koji: We just have tests for rhythm-sizing in general.

<TabAtkins> florian: We have a spec, and tests; you fail because you don't ipmlement. That's normal, right?

<heycam> fantasai: what are the tests for? there's block step sizing and line step sizing

<TabAtkins> fantasai: Were the tests for block step sizing, or line step sizing?

<TabAtkins> koji: line step sizing

<TabAtkins> koji: Question isn't about that, tho. I have to admit that I've got not great confidence on how I understand this accidental double-spacing issue.

<rego> are these the tests? https://wpt.fyi/results/css/css-rhythm?label=experimental&label=master&aligned

<TabAtkins> koji: But if I understand correctly, florian and astearns consider this a critical blocking issue.

<TabAtkins> koji: From my perspective, any solution can't avoid accidental double-spacing in some cases.

<astearns> q+

<TabAtkins> koji: So if we say accidental double-spacing fundamentally breaks the feature, we're basically saying CSS won't have this feature. Is that correct?

<TabAtkins> florian: Problem here is we want a vertical rhythm where the lines are the same size, and what to do when you can't have that.

<TabAtkins> florian: So either you break the rhythm and let some lines get bigger, or you double size the line to keep the rhythm.

<TabAtkins> florian: Can't avoid one or the other. What you can avoid is double-size when you don't need them to be.

<TabAtkins> florian: So if we have a mode where we double-size some of the time, making sure it doesn't happen gratuitiously, or in a brittle UA-dependent way, is the essential issue.

<TabAtkins> florian: So it's not "we can never have double sizing", it's "we have to be careful and make double-sizing happen consistently and predictably"

<tantek> rather than "that would be bad", can you state the desired fallback behavior?

<TabAtkins> hober: Isn't there a third option?

<TabAtkins> hober: Enforce the rhythm, and let the line overlap slightly.

<TabAtkins> florian: I think it's a bad one, but yes.

<TabAtkins> hober: I think some would prefer that.

<TabAtkins> florian: Circling back to koji's question, we ahve multiple specs addressing this problem.

<TabAtkins> florian: My feeling is that the most realistic part of this story is block-step-sizing; easiest and least brittle.

<fantasai> TabAtkins: Not going to break your layout if all your blocks are slightly larger in one browser than another

<fantasai> TabAtkins: but very broken if every line is double-spaced

<fantasai> faceless2: This only applies when line-height is normal?

<TabAtkins> faceless2: This only applies when line-height is normal, correct?

<TabAtkins> florian: Different concepts here. block-step-sizing ahs the problem without line-height.

<TabAtkins> florian: So they overlap to varying degrees.

<TabAtkins> fantasai: I think neither of these specs should be actively tested or implemented yet; I don't think we have great consensus on this as the correct solution yet.

<TabAtkins> fantasai: block-step-sizing doesn't have this sensitivity to inline layout or font rendering.

<TabAtkins> fantasai: So I think we could point to a wpt revision that had those tests, but I don't think we shoudl highlight failures before we have agreement on the concept at all.

<astearns> q?

<TabAtkins> fantasai: I think we need to handle font fallback in a more robust way. I think there's a lot of work to do to solve rhythmic sizing well, and a lot of that is solving inline layout problem generally.

<TabAtkins> koji: We could just set line-height and it works, tho.

<TabAtkins> fantasai: Right, but baseline-to-baseline spacing is still inconsistent.

<TabAtkins> fantasai: So because we have this discrepancy, almost all the time we trigger the double-spacing.

<TabAtkins> fantasai: So we want to clear this up, make the lines naturally rhythmic, so then when we need to interrupt the rhythm with something significantly different we can invoke rhythmic sizing.

<TabAtkins> koji: True for Latin, I don't think it's true for CJK.

<faceless2> q+

<TabAtkins> koji: Really just want to know if we should even be thinking about imlementing right now.

<TabAtkins> fantasai: I don't think so, no. If you remove those tests, drop a link to the last revision with them into the spec.

<TabAtkins> koji: Ok. But even block sizing has these problems too.

<TabAtkins> fantasai: I don't think so, no. rhythmic sizing will increase the size of blocks sometimes.

<TabAtkins> koji: We will have the same problems as text tho.

<TabAtkins> florian: How?

<TabAtkins> TabAtkins: If we have rendering differences in line heights, and the block height is based on text content, we'll have the same UA-dependent differences!

<TabAtkins> florian: If you size with lh unit, then...

<TabAtkins> florian: Really my issue is just about line-step-height. I don't think it's about block-step-height, but if you think there is, go ahead and open an issue about that.

<Rossen__> ack astearns

<TabAtkins> astearns: Elika went over a bit of my comment, but if th efeature isn't in active dev, I think it's perfectly fine to remove tests from WPT. I just approved a PR to remove all the Regions tests for this reason.

<TabAtkins> astearns: I'd prefer if there was active development - I don't think this issue is a blocker to doing work at all.

<TabAtkins> koji: So I hear consensus to remove the tests, and add warning to line-height-step and line-grid; block-step is fine.

<Rossen__> ack faceless2

<TabAtkins> faceless2: RealObjects have implemented this; I can't speak for how well.

<Rossen__> ack fantasai

<Rossen__> ack faceless

<TabAtkins> faceless2: AH have an implementation as well.

<TabAtkins> faceless2: We've got it too.

<TabAtkins> faceless2: I think this is all about the differences in what line-height:normal means between impls.

<Rossen__> q?

<TabAtkins> TabAtkins: I'll note that the ".tentative" substring in the filename is designed for this - tests that shouldn't be considered normative yet, but are in development.

<TabAtkins> Rossen__: So current proposal is to remove tests, add warnings to line-height-step and line-grid.

<TabAtkins> myles: What will the warning say?

<TabAtkins> florian: In line-height-step it can link to this issue.

<TabAtkins> florian: For line-grid, there are concerns, but no issue yet.

<TabAtkins> astearns: I can add the warning.

<TabAtkins> astearns: "We haven't figured everything out yet, but don't try to ipmlement blind assuming it's stable. Please give feedback if you're okay with working on bleeding edge."

<fantasai> <br>

css-meeting-bot on 23 Jan 2020

Csswg-drafts: [css-rhythm-1] Avoiding accidental double spacing

All 83 comments

Related issues