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

> 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.

GitHub Notification of comment by tabatkins
Please view or discuss this issue at using your GitHub account

Received on Friday, 28 July 2017 17:27:15 UTC