[css21][css-inline] Meta bug for line height

[frivoal]

This is the meta bug to track a series of issues based on the findings of #938 (comment).

The general premise is: css21 is partly ambiguous, partly self-contradictory about how height measurements of non replaced inline level boxes are supposed to happen. Implementations are not fully interoperable. The goal here is to find what is interoperable, to agree on what to do for things that are not, and to fix the specs accordingly.

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

[frivoal]

Things all implementations agree about (in suggested reading order):

• [css21][css-inline] height of inline box with line-height not normal #1797
• [css21][css-inline] Position of the baseline inline-level boxes with non normal line-height #1801
• [css21][css-inline] Height of an inline-level box with line-height:normal using primary and fallback fonts #1802
• [css21][css-inline] height of inline box with line-height:normal and primary font not used #1800
• [css21][css-inline] height of the content area of inline level boxes #1804

Disagreements:

• [css21][css-inline] behavior differences when the primary font does not contain U+0020 #1798

TL;DR: We have interoperability in the general case both for the height of inline boxes, the position of the baseline therein, and for the height of the content area of inline boxes. Specs should be updated accordingly. The remaining cases where interop is lacking are odd corner cases, which we should harmonize and specify.

[frivoal]

@astearns @atanassov How do you want to manage/chair this? I am reasonably confident in my conclusions, but this should get meaningful review from others before we amend 2.1. I can write Pull Requests for spec changes and for tests to go with it, and these should get close scrutiny, but presumably we want (at least) some high level discussions prior to that.

I can try to present this during a teleconf, and see if we can get a resolution. If we don't, I'll whiteboard this at TPAC. If we do, I write the PRs, ask for review, and we revisit during TPAC, hopefully to resolve to merge them.

Pinging a few people who should probably review this sooner or later: @atanassov @FremyCompany @fantasai @dbaron @smfr @tabatkins @litherum

[kojiishi]

This is the one we talked about in Paris, correct? Can you point which one Blink behaves differently from other engines?

[frivoal]

@kojiishi Yes, it's that one. The difference is actually limited to a more narrow case than I had thought at first, but it is there. Details in #1798.

[kojiishi]

Ok, thanks, I'll take a look at #1798. Please let me know if there were other issues I should look at to see what Blink does.

[css-meeting-bot]

The Working Group just discussed Meta bug for line height.

The full IRC log of that discussion

<dael> Topic: Meta bug for line height
<astearns> https://github.com//issues/1796#issuecomment-328713658
<dael> github: https://github.com//issues/1796#issuecomment-328713658
<dael> astearns: I wanted to introduce this work because I think it needs more review. I'd like dbaron and others to look at this nest so we can have useful discussion and start resolving things to make line height more interop
<dael> florian: I think the result of my testing is we're more interop then I thought. Spec is wrong. I think there's 2 places we're not. One is how browsers fetch font metrics, there are differences and I didn't try and understand them.
<Chris> q+
<astearns> ack Chris
<dael> florian: One other exception is what happens with the first available font when the space character is excluded from unicode. WE did resolve there recently, but I think we went a bit too fast. I made test cases for every assertion, so please go review. If you agree with me I'll make PR for the spec. If you don't I'll look
<dael> Chris: There's a commonly used trick where you use unicode and rely on a second font after the swishy first font.
<dael> florian: I think your trick only works in chrome
<dael> Chris: Generally in FF too.
<dael> florian: Please look at my test cases and tell me where it's wrong. In FF it goes with random stuff and speed of load changes what you get. I have a test case.
<dael> Chris: Okay, I'll go review.
<dael> florian: Please everyone go reivew and based on that we can have a spec that matches impl and impl that match each other.
<Chris> s/unicode/unicode to get a swash ampersand/
<dael> astearns: Anyone else have something on this topic?
<dael> astearns: Thanks florian for doing this.

[css-meeting-bot]

The Working Group just discussed Meta bug for line height.

The full IRC log of that discussion

<dael> Topic: Meta bug for line height
<dael> github: https://github.com//issues/1796
<dael> florian: I still want people to review. There hasn't been review in github. Repeating subject:
<dael> florian: I wrote a bunch of test cases to figure out if we're interop on various aspects of line-height. First, please confirm tests are right. Area I found we're not interop is a bit deeper on something discussed where first available font doesn't include the space charater.
<dael> florian: THat's and the font file for font metrics are only places with changes. Please, please review my work. This is intriciate.
<dael> Rossen_: Anyone have reviewed? If not, we can consider this a CTA to give feedback.
<dael> Rossen_: Okay. Please give feedback to florian.

[frivoal]

All sub issues have been closed, closing this one as well.