Ian Kilpatrick

cc/ @zcorpan

Yeah - that's the same logic I followed as well - as such I believe that: ``` ``` https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12662 Should be aligned (ignoring the issue of **how** to synthesize baselines...

> It seems most intuitive to me that line-clamp applies after the line-breaks for a block have been determined FWIW we (Blink) previously had this behaviour - but after web-developers...

> I'm curious if people considered the implications of this for dynamically-varying line-clamp, or looked only at static examples? From examples I've seen - most folks have a non-dynamic line-clamp...

Note I think we (try) and follow the definition here: https://drafts.csswg.org/css-tables-3/#table-row-baseline

+1 to keeping them - can also use .optional instead of .tentative if needed.

For things like this we often see compat issues with mobile specific sites. Also FWIW Firefox actually does support this, e.g. https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=7544 :P This is obviously due to the engine...

But you agree that as far as the web-developer is concerned, the layout result of calc(x% + y px) should behave the same way irregardless of the the values of...

I'm pretty convinced this more explainable/sane to web-developers than what is currently spec'd given above, but can dub this "shortest path to interop" if you like :).

@emilio Firefox isn't consistent with itself wrt. heights here - for example: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=7546 https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=7547 @zcorpan Implementing this non-quirk quirk is surprisingly(!) difficult in our new (LayoutNG) implementation. There are now...