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

@emilio:
> Is Blink willing to try changing this @kojiishi?

Created a [test@jsbin](https://jsbin.com/bisopel/edit?html,output), it looks like `normal` is the only case we differ. I can try, but it means all other browsers also need to change. We should probably not try to change behaviors where all browsers are interoperable today. Does this sound reasonable?

@MatsPalmgren:
> I'd prefer that Chrome implement the spec instead.

We can try it out, but because no one implements the spec (used value) today, for Blink doing so will create another new interop problem to all of us. I would rather prefer to change the spec to allow Gecko and WebKit behaviors, and to try to change Blink to match to WebKit.

To recap, for `normal`, Edge and Blink return `normal`. Gecko and WebKit return an estimated value from font metrics (and some other info in Gecko), but the logic differ by large.

@litherum is concerned about the breakage, which is understandable. We know a lot of pages already detect browsers and run different code, so Blink and Edge returning `normal` today does not prove it's safe to change. With @joonghunpark motivated to work on this (thanks!), Blink can try to return an estimated value if WG is happy to change the spec.

IIUC @frivoal's point is that, since the returned length are not reliable nor interoperable, he prefers not to return any length. It has a point, and I'm fine with it too.

I'm also fine to allow both as I've not seen complaints from authors yet, but I guess we prefer not to do it.

-- 
GitHub Notification of comment by kojiishi
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3749#issuecomment-477848814 using your GitHub account

Received on Friday, 29 March 2019 03:03:36 UTC