search

w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.36k stars 641 forks source link

[css-overflow-4] When does the blockification of -webkit-box occur? #10435

Open bfgeek opened 1 month ago

bfgeek commented 1 month ago

Does it happen within style-adjustment or when building the box-tree?

andreubotella commented 4 weeks ago

In Blink, if the specified value of display is -webkit-box or -webkit-inline-box, that is also its computed value. Then, when building the box tree, if an element would have display: -webkit(-inline)-box, -webkit-box-orient: vertical and a value of -webkit-line-clamp (or line-clamp in our WIP implementation of continue: collapse) other than none, then a block box is created. (If any of those conditions does not hold, display: -webkit(-inline)-box creates a flex box.) Then, during block layout, those conditions are checked again to know whether -webkit-line-clamp would have any effect.

In Gecko, if those conditions hold, the computed value of display is flow-root (for -webkit-box) or inline (for -webkit-inline-box). None of the other properties are changed during style adjustment. But because of that, the check of whether -webkit-line-clamp applies during block layout needs to check the specified value of display, rather than the computed value.

frivoal commented 4 weeks ago

In Gecko, if those conditions hold, the computed value of display is […] inline (for -webkit-inline-box)

Did you mean inline-block rather than inline?

In any case, I lean towards the approach followed by Blink. Since we need to refer to the display property again to check if it is -webkit-box before deciding if -webkit-line-clamp has an effect, keeping that as the computed value seems preferable.

That said, I don't care strongly either way, and if implementers prefer to align on the Gecko behavior instead, I have no objection.

andreubotella commented 3 weeks ago

Did you mean inline-block rather than inline?

Indeed, it is display: inline-block.