Re: [csswg-drafts] [css-inline] A question for the procedure to compute the resolved value of "line-height" (#3749)

The CSS Working Group just discussed `A question for the procedure to compute the resolved value of "line-height"`, and agreed to the following:

* `RESOLVED: return 'normal' for line-height`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: A question for the procedure to compute the resolved value of "line-height"<br>
&lt;myles> by the way, everyone should remember to re-join the newly rechartered SVG WG<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/3749<br>
&lt;dael> florian: Bit of discussion in GH was first a suggestion maybe line-height isn't special b/c many types of boxes that can frag and we always return first. Two buts, we're talking contiguous runs of text which is poorly defined to say first. This is not what Gecko or WK return, both return more theoretical rather than actual layout<br>
&lt;dael> florian: But it is similar.<br>
&lt;myles> q+<br>
&lt;dael> florian: I maintain given that we're not providing a post layout usable value we may as well preserve as keyword as Chrome does. BUt alternative isn't hard to spec so if people feel strongly, why not. I'm not sure there's a use case for it.<br>
&lt;dael> florian: If we want to drill down to font metrics it's more houdini space.<br>
&lt;astearns> ack myles<br>
&lt;dael> myles: I was reading convo from last week and I think I didn't make something clear. Philosophically I think you're right. There is no px value that will always be correct. My concern was web compat. If we do keyword and not number and line of JS tries to parse it could cause exceptions<br>
&lt;dael> myles: I brought up we should do analysis. Did investigate this week into how we can do.<br>
&lt;dael> florian: Queston on compat concern. Anything we change from any engine could break amount of web. The fact that Chrome ships other behavior tends to make me think it's prob okay. DO you have a specific reason to worry about this one or is it a general case of changing might break<br>
&lt;dael> myles: Why this might be different is line-height and gCS have been around forever. CHanging behavior that's been consistent in engine for decades is scary<br>
&lt;dael> fantasai: If we want interop someone needs to change. Either Chrome to return px or other engines return 'normal'<br>
&lt;dael> fantasai: Is that not correct?<br>
&lt;dael> TabAtkins: myles , given we have real life compat data that Chrome returns keyword, what information do you want obtained.<br>
&lt;dael> myles: A blunt tool is how many times gCS called where result is 'normal'<br>
&lt;dael> TabAtkins: Potentially obtainable, but a fairly invasive use counter<br>
&lt;dael> florian: Would that data from Chrome help? We know Chrome is fine. If there's a problem it's b/c websites are build differently perhaps on mobile where Chrome has less market share. So would it help?<br>
&lt;Rossen_> https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/line-height/<br>
&lt;emilio> q+<br>
&lt;Rossen_> in case this helps a bit ^<br>
&lt;astearns> ack emilio<br>
&lt;nigel> q+ to suggest that although resolved value is not always the same as computed value, we should bias in favour of making resolved value closer to the computed value as a tie-breaker<br>
&lt;fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0Ax%0A%3Cscript%3E%0Aw(window.getComputedStyle(document.body).lineHeight)%3B%0A%3C%2Fscript%3E<br>
&lt;dael> emilio: I'm somewhat concerned...result of gCS on form controls have particularly weird computation. WK and Blink mangle line-height to give computed line-height. I suspect there are cases where if you have a select element if this change impl in Gecko it could return keywork and Blink returns pixel. I recall something where like if the height is fixed it becomes a fixed height value.<br>
&lt;astearns> ack nigel<br>
&lt;Zakim> nigel, you wanted to suggest that although resolved value is not always the same as computed value, we should bias in favour of making resolved value closer to the computed value<br>
&lt;dael> emilio: Willing to try and change, but that's my concern<br>
&lt;Zakim> ... as a tie-breaker<br>
&lt;dael> nigel: Observing this seems a bit of a tie here. Current behavior is return 'normal' and that'scloser to computed. Resolved isn't always computed, but being as close as possible seems a reasonable rule to use to break the tie.<br>
&lt;dael> fantasai: I think if Gecko is willing to try that should resolve web compat concerns. I agree that's prob direction to try and go in.<br>
&lt;dael> myles: If Gecko makes this change and there's no prob that's sufficient. I agree with fantasai . Don't need a use counter in that case<br>
&lt;dael> astearns: Way forward is spec we return 'normal' have Gecko try it out and hope for the best<br>
&lt;dael> fantasai: And if problem open issue<br>
&lt;dael> astearns: Obj to return 'normal' for line-height ?<br>
&lt;dael> RESOLVED: return 'normal' for line-height<br>
&lt;dael> astearns: Thanks emilio for being the guenia pig<br>
&lt;dael> emilio: I'll add a use counter and not blindly change, but happy to give a shot<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-477241555 using your GitHub account

Received on Wednesday, 27 March 2019 16:33:02 UTC