Open frivoal opened 7 years ago
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?
The CSS Working Group just discussed inline layout
.
The CSS Working Group just discussed CSS Rhythm
.
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:
line-box-contain
property in Paris, and fortunately WebKit implements it too, so I applied line-box-contain: block
to the 3rd box.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:
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?
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.
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?
I am suggesting the example needs changes. As it is, it does not seem relevant to this issue to me.
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.
The Working Group just discussed Avoiding accidental double spacing
.
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?
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.
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.
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.
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:
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 nowauto
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
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.
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.
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.
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.
Alan's suggestion above gave me a hint for another idea.
What do you think about
line-height-step: none | auto
?
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.
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.
@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 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.
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.
For your first comment, I'm thinking we can live without <length>
. Hopefully that resolves your concern?
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, 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.
@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 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.
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.
Summary of proposals so far:
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.
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:
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 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.
The CSS Working Group just discussed Line grid and tests
.
The spec for https://drafts.csswg.org/css-rhythm/#line-height-step says that
The initial value of line-height is
normal
which is defined like this:Actual implementations are know to vary, and in practice the actual numerical value of
line-height: normal
is unpredictable. Ideally authors will not rely on it and manually set theline-height
when they want to useline-height-step
, but we should try to be robust when they don't.If
normal
in a particular browser on a particular os with a particular font is equivalent to1.15
, and on a different browser/os/font combination, it is equal to1.25
, and an author leavesline-height
at the default value, and setsline-height-step
to1.2em
, things will look fine in one browser and not in the other, and the author may not know if they do not test in that particular browser/os/font combination.I think it is quite important to reduce or eliminate this kind of situation, so we should do something.
How about this:
When line
line-height-step
is not0
, thenline-height: normal
is treated asline-height: 1
when computing the used value. This would usually be appropriate (and in the odd case where it is not, it is always possible to set a manual value), and would eliminate variation between browsers, making naïve use ofline-height-step
more robust.