Re: [csswg-drafts] [css-align] Special case for inline-block+scroll-container elements needs to cover inline blocks that **contain** scroll containers (#3611)

The CSS Working Group just discussed `Special case for inline-block+scroll-container elements needs to cover inline blocks that **contain** scroll containers`.

<details><summary>The full IRC log of that discussion</summary>
&lt;heycam> Topic: Special case for inline-block+scroll-container elements needs to cover inline blocks that **contain** scroll containers<br>
&lt;heycam> github: https://github.com/w3c/csswg-drafts/issues/3611<br>
&lt;heycam> TabAtkins: not sure if this needs discussion, dholbert agreed<br>
&lt;heycam> ScribeNick: heycam<br>
&lt;heycam> TabAtkins: questions from dholbert was about baselines for inline-blocks in certain cases<br>
&lt;heycam> ... the baseline export section, block containers, it says for legacy reasons [ ... ] the baseline is synthesized from the margin box<br>
&lt;heycam> ... dholbert found this doesn't cover what browsers do today<br>
&lt;heycam> ... there are some cases where it does look inside to elements for a baseline<br>
&lt;heycam> ... we found a fix<br>
&lt;heycam> ... rather than testing for inline block being a scroll container, change it to if it has a child that is a scroll container<br>
&lt;heycam> iank_: should be any descendant<br>
&lt;heycam> astearns: that's not what's in the issue though<br>
&lt;fantasai> here's the change https://github.com/w3c/csswg-drafts/commit/91af157d21c3323d031ce2537d8dfba632b099ca<br>
&lt;heycam> TabAtkins: if the ineline block is a scroll container, it works properly<br>
&lt;fantasai> sorry, wrong changeset<br>
&lt;heycam> ... but dholbert found if it contains a scroll container and nothing else, the only child, you still shouldn't look at that child for baseline info, just synthesize<br>
&lt;heycam> ... we discovered that the condition is different -- some scrollable blocks still do influence the baseline<br>
&lt;iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=7695<br>
&lt;heycam> fantasai: it should be the first in-flow item [...]<br>
&lt;heycam> dbaron: only if the scroll container is block level<br>
&lt;heycam> TabAtkins: scrollable flex boxes that are child of an inline block still give their baseline info<br>
&lt;heycam> ... it's just block containers that hide themselves<br>
&lt;heycam> ... inline blocks and blocks<br>
&lt;heycam> emilio: in Gecko, the baseline of a scrolling box is synthesized from the margin box if the scrolled thing is block level, or you have contain layout<br>
&lt;heycam> ... so I think there may be an easier way to define this<br>
&lt;heycam> ... the scroll box synthesizing the baseline from the margin box, not by looking inside<br>
&lt;heycam> dbaron: is your proposal the thing in the "13 days ago" comment<br>
&lt;heycam> TabAtkins: yes<br>
&lt;heycam> dbaron: my understanding is that this fixes it because it's fixing the recursive invocation of the same alg<br>
&lt;heycam> ... think this makes sense<br>
&lt;heycam> iank_: still applies for any arbitrary child?<br>
&lt;heycam> iank_: I think this special scroll behavior is only executed in the inline block behavior<br>
&lt;heycam> ... looking at the last baseline<br>
&lt;heycam> TabAtkins: if anyone has any possible complications, please comment on the issue<br>
&lt;fantasai> https://drafts.csswg.org/css-align-3/#baseline-export<br>
&lt;heycam> fantasai: I think the change we're planning to make would be in this section<br>
&lt;fantasai> "However, for legacy reasons, if an inline-block is a scroll container or contains no in-flow line boxes, its first and last baseline sets are synthesized from its margin box."<br>
&lt;heycam> fantasai: we'd say it has no baseline set<br>
&lt;heycam> ... and that would trigger the appropriate behavior<br>
&lt;heycam> iank_: if you have multiple children<br>
&lt;heycam> ... two children, one scrollable container, then some text, you'd pick up the baseline from the text?<br>
&lt;heycam> ... if it didn't have a baseline set?<br>
&lt;heycam> fantasai: we're requesting the baseline of a box.  if it says it doesn't have one, it'll synthesize<br>
&lt;heycam> iank_: there's a subtle difference between synthesizing a baseline for a box vs something like providing a baseline<br>
&lt;heycam> ... some things like tables inside of an atomic inline context, they don't synthesize a baseline and they get skipped for this calculation<br>
&lt;heycam> ... but scrollable containers don't get skipped<br>
&lt;heycam> fantasai: each formatting context says "this is how I find my baseline to export it out", and table will say my exported baseline is the first row or whatever<br>
&lt;heycam> ... but for block containers, it'll look at the first baseline, skipping tables etc., the next element that's there and ask it<br>
&lt;heycam> iank_: the scrollable container the baseline is exports out is the block-end offset<br>
&lt;heycam> iank_: when we enter into an atomic inline block, we set a bit on input saying "I need the last baseline since I'm in an atomic inline block"<br>
&lt;heycam> ... and that triggers this special behavior<br>
&lt;heycam> ... it propagates through block level block containers<br>
&lt;heycam> fantasai: going forward we'll have an option to choose first or last baseline<br>
&lt;heycam> iank_: that's fine<br>
&lt;heycam> fantasai: I'll make a PR with some proposed text and we can go over it later<br>
&lt;heycam> astearns: since this is a spec change should help match reality, can it come with tests?<br>
&lt;heycam> TabAtkins: yes<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3611#issuecomment-577204179 using your GitHub account

Received on Wednesday, 22 January 2020 14:23:06 UTC