- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Jun 2019 15:40:23 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `resolved value of line-height`. <details><summary>The full IRC log of that discussion</summary> <emilio> Topic: resolved value of line-height<br> <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/3749<br> <emilio> github: https://github.com/w3c/csswg-drafts/issues/3749<br> <emilio> AmeliaBR: what's the question to be resolved?<br> <emilio> florian: this is about the resolved value of `line-height: normal`<br> <emilio> koji: right now Blink behaves differently from Gecko / WebKit<br> <heycam> koji: one of our contributors is willing to try to change Blink<br> <heycam> koji: seems smoother for Blink to change, want to confirm that with WG<br> <fantasai> ScribeNick: fantasai<br> <fantasai> scribenick: heycam<br> <heycam> emilio: Gecko and WebKit already have this behavior since CSS 2<br> <heycam> ... CSS2 defines the used value of line-height as something based on the primary font of the element<br> <heycam> ... I did try to switch Gecko to return normal, and it's probably not impossible, but it's a bunch of work<br> <heycam> ... also mats disagreed with it<br> <heycam> florian: what CSS 2 has to say is fuzzy<br> <heycam> ... different editions<br> <heycam> ... all browsers are interoperable about what line-height:normal does, to an approximation<br> <heycam> ... that is different from what CSS 2.1 says<br> <heycam> ... 2.1 claims normal is equivalent ot a number<br> <heycam> ... that's not what everyone does<br> <heycam> ... therefore it would make sense that for resolved value, you return the word "normal"<br> <heycam> emilio: there is<br> <heycam> florian: there isn't<br> <heycam> ... there is only if the element is empty<br> <heycam> dbaron: part of the problem is we had a long discussion at Tokyo F2F about line height<br> <heycam> ... and there's nothing written down that reflects the results of that<br> <heycam> ... in a readable format<br> <heycam> ... some edits made to CSS 2 and reverted<br> <heycam> ... there's no usable reference for the results of that discussion, therefore some people involved here inlc emilio and mats, who don't know what's discussed there<br> <heycam> florian: I'm frustrated about these edits being reverted<br> <heycam> ... I'll take those edits and put them into css-inline<br> <heycam> ... skipping oer the detalis, the behavior of line-height:normal is not euivalnet to a number<br> <heycam> emilio: you copmute a number at the start of the element (and the element itself), but once you get that number, which is what Gekco and WK return from gCS, it's the same as if you use that px value ...<br> <heycam> dbaron: it's not<br> <heycam> ... there are 2 ways it's different at least<br> <heycam> koji: I think dbaron and florian are talking about how line-height:normal is laid out<br> <heycam> ... emilio is talking about how line-height is computed<br> <heycam> ... and that is interop between Gecko and WK<br> <heycam> dbaron: what florian and I are saying is that there does not exist a number or a px value that is equivalent to normal<br> <heycam> ... because depending on the text you have in the element, adn what font fallbcak occurs, you'll get different results<br> <heycam> koji: that's for layout<br> <heycam> florian: the computed value is normal as a keyword<br> <heycam> dbaron: I don't think the point you're making is relevant here, I think florian's argument is that we're looking at situations where the computed value is normal, from a style perspective<br> <heycam> ... and we're asking what resolved value to report there<br> <heycam> ... florian's point is that in most cases when we have a reoslved value, putting that resolved value back in the computed value is basically euqivalent<br> <heycam> ... so there are cases where the computed value is a % and resolved value is px<br> <heycam> ... but if you take the resolved value and put it back in computed value, you would get the same result (at least for that element, not necessarily for inheritance etc.)<br> <heycam> ... florian's point is that in this case, there is not a single number that leads to that result, because what normal does around say font fallback, looking at metrics of possibly one possibly multiple fonts, is different from what any particulra number does<br> <heycam> ... that's the stuff that is not well documented because the CSS 2.1 edits were reverted<br> <heycam> florian: the right value to return from gCS would be normal<br> <heycam> ... but if there's broad interop everywhere but Chrome, to return what that number would be if the element is empty, then that's unfortuate but not unfortunate enough to object to that<br> <heycam> emilio: I was going through the Gecko code, we have various bits of if line-height is normal, update the line<br> <tantek> reverting the 2.1 edits (there were a bunch more) was the right thing to do because none of it was based in minuted discussions nor even test cases, and that kind of editing for a stable document like 2.1 is irresponsible<br> <heycam> dbaron: there are a bunch of things in Gecko code based on line-height normal, a bunch are wrong<br> <heycam> ... some were discussed at that previous meeting,<br> <heycam> dbaron: a bunch of the conditions in the gecko code are in the wrong place<br> <heycam> ... there's a bunch of design decisions important for interactions with other features, due to hte lack of interop, we probaly still have the freedom to make<br> <heycam> emilio: after seeing our usage of line-height:normal in our layout engine, I agree that given normal is more special, the right thing to do would be to return normal<br> <heycam> ... I can try again to change Gecko, and if I can't I can report back<br> <heycam> florian: getting interop would be nice<br> <Rossen_> q?<br> <heycam> ... if the only way for that is to return a number, that's OK, otherwise let's try normal<br> <tantek> from my recollection, line-height normal was a way used (by implementation) to capture the legacy Netscape behavior of inline line layout, as opposed to what Håkon & Bert wanted line-height to do<br> <heycam> myles_: philosophically returning normal would be great<br> <heycam> ... might break the web<br> <heycam> florian: chrome has been returning normal for a long time, so maybe wouldn't?<br> <heycam> ... maybe there is UA sniffing that would maek it break<br> <heycam> emilio: given this conversation I can try to convince mats<br> <heycam> florian: I will try to take the CSS 2.1 fixes and put them in Level 3<br> <heycam> emilio: notes in the spec about how that not only affects resolved value, but other stuff, would be great<br> <heycam> koji: dbaron's explanation I finally understand why we want normal, it makes sense<br> <heycam> ... but I also want interop. is WK willing to change?<br> <heycam> myles_: I don't think I would chane this before Gecko does<br> <heycam> ... if Gecko succeeds we'd probably be willing to do it<br> <heycam> dbaron: my memory of the discussions we had in Tokyo, I'm not 100% sure we all agreed that we want to stick to a behavior that normal cannot be mapped to a number<br> <heycam> ... that number might depend on something in the first available font, it almost certianly would, but I'm not sure we agreed that we do not want hte behavior that you could'nt convert normal to an equivalent number based on available font metrics<br> <heycam> ... that is using font metrics but not particular character availability<br> <heycam> florian: how about we reopen that issue as necessary, based on the Tokyo text, which describes ~reality<br> <heycam> ... and do that based on the text<br> <heycam> myles_: are you suggesting you want to change hte behavior to make normal not magic? or numbers be more magic?<br> <heycam> dbaron: change normal so that its magic is a bit different<br> <heycam> ... e.g. how font fallback interacts with line rhythm<br> <heycam> ... one piece there is that maybe it is better if the box that normal gives you is only a function of hte first available font, and not hte fallback fonts<br> <heycam> ... then when you have multiple lines/elements, some of which trigger fallbcak, you don't get unstable line rhythm<br> <heycam> ... I'm not sure we sorted that out fully<br> <heycam> myles_: I have opinions on this but maybe that's a different topic<br> <heycam> dbaron: the reason I'm bringing it up, is it relates to the conclusion that there does not exist an equivalent number<br> <heycam> ... but that's a full day long discussion<br> <heycam> florian: I agree there's room for discussion<br> <heycam> ... I propose we first get back the text, and go from there<br> <heycam> dbaron: sure<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3749#issuecomment-499138167 using your GitHub account
Received on Wednesday, 5 June 2019 15:40:24 UTC