- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Thu, 21 Mar 2019 06:57:59 +0000
- To: public-css-archive@w3.org
> I don't really understand why the line-height property is singled out. Pretty much all of the properties where the resolved value = used value in this list may have different used values on each fragment * We're not talking about fragments here, but about text runs, or even parts of text runs. This may be considered sorta similar if you want to, but no fragmentation (either in the multicol/pagination sense, or in the line break sense) needs to occur here; we just need font fallback to happen. We may want to deal with these chunks the same way we deal with Fragments. Or not. I'd lean towards not, because I don't think it is specified anywhere if and how we're supposed to slice text runs into multiple chunks based on font fallback (and/or other things?), so it's hard to talk about the height of the first one until we agree on what's supposed to be in the first one. * Assuming I understand it correctly the cold snippet that was shared for webkit without looking up the functions it calls, and assuming it was described correctly, the behavior described as the webkit behavior does not give the height of the not the first chunk: If gives the height of a hypothetical chunk with text from the first available font. You may not have one of these, and even if you do, it may not be the first one. Let's say your font stack is `"times new roman", "hiragino mincho", serif`, that both `times new roman` and `hiragino mincho` are available, and that all the text in the element is in Japanese. The actual line height (of all text runs / fragments / chunks) will be based on `hiragino mincho`, but the getComputedStyle as described above would return the height of `times new roman` alone. I think we could do a number of variants: 1. return `normal` as a keyword. 2. return the theoretical height based on the first available font, regardless of whether it is actually used. Possible nuance: the [latest version of the spec text](https://github.com/w3c/csswg-drafts/pull/1993/files#diff-63ba98ee4330d917b726501a4e17046aL1473) includes (based I believe on @dbaron saying that this was needed): > User Agents may use different sets of font metrics when determining <var>A</var> and <var>D</var> > depending on whether the <span class="propinst-line-heigh">'line-height'</span> property > is 'normal' or some other value, > for instance taking external leading metrics into account > only in the 'normal' case. Since we're not returning something based on actual layout, which of the possible font metrics are we using? presumably the one that gets used for the `normal` case, but given that the code snippet in the first comment talks about "the metrics" of "the font" when there are multiple fonts each having multiple metrics, I am not sure this nuance is taken into account, so maybe not. 3. return the actual height of the first inline box (i.e. from the beginning until a line break, or the start of a different inline, whichever comes sooner), enclosing all glyphs actually used, going from the tallest ascender to the deepest descender, including the [strut](https://drafts.csswg.org/css2/visudet.html#strut). Variants: 1. if the element starts with an atomic/replaced inline, count the height of the first inline box after that 2. if the element starts with an atomic/replaced inline, return the height of the [strut](https://drafts.csswg.org/css2/visudet.html#strut), i.e. the theoretical height based on the first available font. Further nuances: * If the anchor point of a float or an abspos comes in the middle of that box, does that count a cutting that box in two or not? * If we have some other formatting changes, within the line (say, a color change), does that count as splitting the box or not? If we have `<p>aあ<span style=color:red>अ</span>`, and we're asking for the line height of the `<p>`, we we work with the union of the Latin and Japanese fonts only, or do we include the Devanagari one as well? How about if the span is unstyled? * If the element starts with a block level descendent, do we look at the first inline box after that, or to we go pretend there's an empty inline at the start, and therefore return the height of the [strut](https://drafts.csswg.org/css2/visudet.html#strut)? 4. return the actual height of the first non empty inline box chunk: based on the height of first glyph actually used (or equivalently, on the height of the first run of glyphs that all come form the same font). (1) is what Blink does now. (2) Is what I believe webkit does now. If Firefox does something based "on the first fragment", I suppose it does one of the other variants, but I'm not sure which, or maybe it does (2) as well. Doing anything other than (1) needs us to dig into the details of the various variants. Given that no use case has been brought up so far, and that Chrome shipping variant (1) is fairly strong evidence that this behavior is web compatible, I'd rather do that. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3749#issuecomment-475128795 using your GitHub account
Received on Thursday, 21 March 2019 06:58:00 UTC