- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Jan 2020 14:23:05 +0000
- To: public-css-archive@w3.org
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> <heycam> Topic: Special case for inline-block+scroll-container elements needs to cover inline blocks that **contain** scroll containers<br> <heycam> github: https://github.com/w3c/csswg-drafts/issues/3611<br> <heycam> TabAtkins: not sure if this needs discussion, dholbert agreed<br> <heycam> ScribeNick: heycam<br> <heycam> TabAtkins: questions from dholbert was about baselines for inline-blocks in certain cases<br> <heycam> ... the baseline export section, block containers, it says for legacy reasons [ ... ] the baseline is synthesized from the margin box<br> <heycam> ... dholbert found this doesn't cover what browsers do today<br> <heycam> ... there are some cases where it does look inside to elements for a baseline<br> <heycam> ... we found a fix<br> <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> <heycam> iank_: should be any descendant<br> <heycam> astearns: that's not what's in the issue though<br> <fantasai> here's the change https://github.com/w3c/csswg-drafts/commit/91af157d21c3323d031ce2537d8dfba632b099ca<br> <heycam> TabAtkins: if the ineline block is a scroll container, it works properly<br> <fantasai> sorry, wrong changeset<br> <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> <heycam> ... we discovered that the condition is different -- some scrollable blocks still do influence the baseline<br> <iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=7695<br> <heycam> fantasai: it should be the first in-flow item [...]<br> <heycam> dbaron: only if the scroll container is block level<br> <heycam> TabAtkins: scrollable flex boxes that are child of an inline block still give their baseline info<br> <heycam> ... it's just block containers that hide themselves<br> <heycam> ... inline blocks and blocks<br> <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> <heycam> ... so I think there may be an easier way to define this<br> <heycam> ... the scroll box synthesizing the baseline from the margin box, not by looking inside<br> <heycam> dbaron: is your proposal the thing in the "13 days ago" comment<br> <heycam> TabAtkins: yes<br> <heycam> dbaron: my understanding is that this fixes it because it's fixing the recursive invocation of the same alg<br> <heycam> ... think this makes sense<br> <heycam> iank_: still applies for any arbitrary child?<br> <heycam> iank_: I think this special scroll behavior is only executed in the inline block behavior<br> <heycam> ... looking at the last baseline<br> <heycam> TabAtkins: if anyone has any possible complications, please comment on the issue<br> <fantasai> https://drafts.csswg.org/css-align-3/#baseline-export<br> <heycam> fantasai: I think the change we're planning to make would be in this section<br> <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> <heycam> fantasai: we'd say it has no baseline set<br> <heycam> ... and that would trigger the appropriate behavior<br> <heycam> iank_: if you have multiple children<br> <heycam> ... two children, one scrollable container, then some text, you'd pick up the baseline from the text?<br> <heycam> ... if it didn't have a baseline set?<br> <heycam> fantasai: we're requesting the baseline of a box. if it says it doesn't have one, it'll synthesize<br> <heycam> iank_: there's a subtle difference between synthesizing a baseline for a box vs something like providing a baseline<br> <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> <heycam> ... but scrollable containers don't get skipped<br> <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> <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> <heycam> iank_: the scrollable container the baseline is exports out is the block-end offset<br> <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> <heycam> ... and that triggers this special behavior<br> <heycam> ... it propagates through block level block containers<br> <heycam> fantasai: going forward we'll have an option to choose first or last baseline<br> <heycam> iank_: that's fine<br> <heycam> fantasai: I'll make a PR with some proposed text and we can go over it later<br> <heycam> astearns: since this is a spec change should help match reality, can it come with tests?<br> <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