[css-align] Special case for inline-block+scroll-container elements needs to cover inline blocks that **contain** scroll containers #3611
Comments
…crolled content (unless their display value is block-inside). r=mats Before this patch, we made scrollable frames derive their baseline from their margin-box, because that's what the spec requires for scrollable inline-block boxes. However, the spec now singles out inline-block as a special case, and other sorts of scrollable inline-level containers are supposed to derive their baseline from the scrolled content. So, this patch makes us do that, with an exception for scrollable inline-block boxes. For more info about the block-inside special case, see the end of the "block containers" chunk here: https://drafts.csswg.org/css-align/#baseline-export (Though that spec text may be a bit too specific, per my spec issue at w3c/csswg-drafts#3611 -- that's why this patch checks for block-inside rather than inline-block.) Differential Revision: https://phabricator.services.mozilla.com/D18481 --HG-- extra : moz-landing-system : lando
…ent (unless their display value is block-inside). Before this patch, we made scrollable frames derive their baseline from their margin-box, because that's what the spec requires for scrollable inline-block boxes. However, the spec now singles out inline-block as a special case, and other sorts of scrollable inline-level containers are supposed to derive their baseline from the scrolled content. So, this patch makes us do that, with an exception for scrollable inline-block boxes. For more info about the block-inside special case, see the end of the "block containers" chunk here: https://drafts.csswg.org/css-align/#baseline-export (Though that spec text may be a bit too specific, per my spec issue at w3c/csswg-drafts#3611 -- that's why this patch checks for block-inside rather than inline-block.) Differential Revision: https://phabricator.services.mozilla.com/D18481 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=969874 gecko-commit: 21b74260c8a9fcc8c35ffafc2f98254753fe8d7a gecko-integration-branch: central gecko-reviewers: mats
…ent (unless their display value is block-inside). Before this patch, we made scrollable frames derive their baseline from their margin-box, because that's what the spec requires for scrollable inline-block boxes. However, the spec now singles out inline-block as a special case, and other sorts of scrollable inline-level containers are supposed to derive their baseline from the scrolled content. So, this patch makes us do that, with an exception for scrollable inline-block boxes. For more info about the block-inside special case, see the end of the "block containers" chunk here: https://drafts.csswg.org/css-align/#baseline-export (Though that spec text may be a bit too specific, per my spec issue at w3c/csswg-drafts#3611 -- that's why this patch checks for block-inside rather than inline-block.) Differential Revision: https://phabricator.services.mozilla.com/D18481 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=969874 gecko-commit: 21b74260c8a9fcc8c35ffafc2f98254753fe8d7a gecko-integration-branch: central gecko-reviewers: mats
…crolled content (unless their display value is block-inside). r=mats Before this patch, we made scrollable frames derive their baseline from their margin-box, because that's what the spec requires for scrollable inline-block boxes. However, the spec now singles out inline-block as a special case, and other sorts of scrollable inline-level containers are supposed to derive their baseline from the scrolled content. So, this patch makes us do that, with an exception for scrollable inline-block boxes. For more info about the block-inside special case, see the end of the "block containers" chunk here: https://drafts.csswg.org/css-align/#baseline-export (Though that spec text may be a bit too specific, per my spec issue at w3c/csswg-drafts#3611 -- that's why this patch checks for block-inside rather than inline-block.) Differential Revision: https://phabricator.services.mozilla.com/D18481 UltraBlame original commit: 21b74260c8a9fcc8c35ffafc2f98254753fe8d7a
…crolled content (unless their display value is block-inside). r=mats Before this patch, we made scrollable frames derive their baseline from their margin-box, because that's what the spec requires for scrollable inline-block boxes. However, the spec now singles out inline-block as a special case, and other sorts of scrollable inline-level containers are supposed to derive their baseline from the scrolled content. So, this patch makes us do that, with an exception for scrollable inline-block boxes. For more info about the block-inside special case, see the end of the "block containers" chunk here: https://drafts.csswg.org/css-align/#baseline-export (Though that spec text may be a bit too specific, per my spec issue at w3c/csswg-drafts#3611 -- that's why this patch checks for block-inside rather than inline-block.) Differential Revision: https://phabricator.services.mozilla.com/D18481 UltraBlame original commit: 21b74260c8a9fcc8c35ffafc2f98254753fe8d7a
…crolled content (unless their display value is block-inside). r=mats Before this patch, we made scrollable frames derive their baseline from their margin-box, because that's what the spec requires for scrollable inline-block boxes. However, the spec now singles out inline-block as a special case, and other sorts of scrollable inline-level containers are supposed to derive their baseline from the scrolled content. So, this patch makes us do that, with an exception for scrollable inline-block boxes. For more info about the block-inside special case, see the end of the "block containers" chunk here: https://drafts.csswg.org/css-align/#baseline-export (Though that spec text may be a bit too specific, per my spec issue at w3c/csswg-drafts#3611 -- that's why this patch checks for block-inside rather than inline-block.) Differential Revision: https://phabricator.services.mozilla.com/D18481 UltraBlame original commit: 21b74260c8a9fcc8c35ffafc2f98254753fe8d7a
|
You're right that the first condition isn't sufficient, but some testing by me and @fantasai seems to show that it should be broadened in a different way. If the inline-block contains a scrollable flexbox, it still gets baseline-aligned per its content: <!DOCTYPE html>
<style>
.inline-block { display: inline-block; }
.test {
background-color: lightgrey;
overflow: hidden;
}
.border { border: solid blue; border-width: 1px 3px 5px 7px; }
.padding { padding: 10px; }
.margin { margin: 1px 3px 5px 7px; }
</style>
The boxes should align vertically:
<div class="inline-block">
<div>
<div class="test border padding margin" style="display:flex">X</div>
</div>
</div>
<div class="test inline-block margin border padding">X</div>So it looks like the condition, rather than "inline-blocks that are scroll containers", should be "block containers that are scroll containers". That covers the original condition, and makes your testcase valid per spec, as the inline-block tries to determine its baselines from its content, sees only a scrollable block container, and concludes that it has no baselines. (And then, per Inline, it synthesizes baselines from its own margin box.) Does this sound correct? Aside: Form controls are fun here, as semi-replaced elements. |
|
I think that sounds correct, yeah. Thanks! |
|
|
|
The CSS Working Group just discussed The full IRC log of that discussion<heycam> Topic: Special case for inline-block+scroll-container elements needs to cover inline blocks that **contain** scroll containers<heycam> github: https://github.com//issues/3611 <heycam> TabAtkins: not sure if this needs discussion, dholbert agreed <heycam> ScribeNick: heycam <heycam> TabAtkins: questions from dholbert was about baselines for inline-blocks in certain cases <heycam> ... the baseline export section, block containers, it says for legacy reasons [ ... ] the baseline is synthesized from the margin box <heycam> ... dholbert found this doesn't cover what browsers do today <heycam> ... there are some cases where it does look inside to elements for a baseline <heycam> ... we found a fix <heycam> ... rather than testing for inline block being a scroll container, change it to if it has a child that is a scroll container <heycam> iank_: should be any descendant <heycam> astearns: that's not what's in the issue though <fantasai> here's the change https://github.com/w3c/csswg-drafts/commit/91af157d21c3323d031ce2537d8dfba632b099ca <heycam> TabAtkins: if the ineline block is a scroll container, it works properly <fantasai> sorry, wrong changeset <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 <heycam> ... we discovered that the condition is different -- some scrollable blocks still do influence the baseline <iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=7695 <heycam> fantasai: it should be the first in-flow item [...] <heycam> dbaron: only if the scroll container is block level <heycam> TabAtkins: scrollable flex boxes that are child of an inline block still give their baseline info <heycam> ... it's just block containers that hide themselves <heycam> ... inline blocks and blocks <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 <heycam> ... so I think there may be an easier way to define this <heycam> ... the scroll box synthesizing the baseline from the margin box, not by looking inside <heycam> dbaron: is your proposal the thing in the "13 days ago" comment <heycam> TabAtkins: yes <heycam> dbaron: my understanding is that this fixes it because it's fixing the recursive invocation of the same alg <heycam> ... think this makes sense <heycam> iank_: still applies for any arbitrary child? <heycam> iank_: I think this special scroll behavior is only executed in the inline block behavior <heycam> ... looking at the last baseline <heycam> TabAtkins: if anyone has any possible complications, please comment on the issue <fantasai> https://drafts.csswg.org/css-align-3/#baseline-export <heycam> fantasai: I think the change we're planning to make would be in this section <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." <heycam> fantasai: we'd say it has no baseline set <heycam> ... and that would trigger the appropriate behavior <heycam> iank_: if you have multiple children <heycam> ... two children, one scrollable container, then some text, you'd pick up the baseline from the text? <heycam> ... if it didn't have a baseline set? <heycam> fantasai: we're requesting the baseline of a box. if it says it doesn't have one, it'll synthesize <heycam> iank_: there's a subtle difference between synthesizing a baseline for a box vs something like providing a baseline <heycam> ... some things like tables inside of an atomic inline context, they don't synthesize a baseline and they get skipped for this calculation <heycam> ... but scrollable containers don't get skipped <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 <heycam> ... but for block containers, it'll look at the first baseline, skipping tables etc., the next element that's there and ask it <heycam> iank_: the scrollable container the baseline is exports out is the block-end offset <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" <heycam> ... and that triggers this special behavior <heycam> ... it propagates through block level block containers <heycam> fantasai: going forward we'll have an option to choose first or last baseline <heycam> iank_: that's fine <heycam> fantasai: I'll make a PR with some proposed text and we can go over it later <heycam> astearns: since this is a spec change should help match reality, can it come with tests? <heycam> TabAtkins: yes |
|
If scrollable overflow only happens in either the inline or block axis, would that afford baseline alignment in different ways? |
|
Minutes from January https://lists.w3.org/Archives/Public/www-style/2020Feb/0008.html |
|
Okay, edits were made in 7a66d53 (paired with 3bd261f to clarify exactly when baselines are synthesized). After puzzling over Elika's testcase a bit (now captured in the repo at https://drafts.csswg.org/css-align-3/baseline-align-test), we realized the actual behavior here is weird but interoperable:
|
|
Thanks for that explanation! I think your bullet-points there make sense and seem to mesh with my observations from fantasai's testcase. RE the spec edits: they make sense if I don't think about writing-modes at all. :) But if I take writing-mode into consideration, then 7a66d53 doesn't quite make sense -- in a vertical writing-mode, I don't think it's right (or meaningful) to say that we derive the last baseline set from the margin-bottom edge... Perhaps that means to say that we derive it from the "block-end margin edge"? That seems to be what Chrome uses for cases "B" and "I" if I load https://drafts.csswg.org/css-align-3/baseline-align-test with (CC @jfkthame & @MatsPalmgren who may have thoughts on this, too) |
|
Oh phew, yes, definitely a writing-mode-aware edge, sorry about that. Question, tho: line-under, or block-end? @fantasai, you know the appropriateness of line-under usage better than me. |
|
@tabatkins block-end of the scroll container, because we're compensating for the fact the line we would be aligning to is scrolled off-screen, potentially (or at least, I think that's the "logic" being applied here)? @dholbert Firefox's handling of baselines in vertical writing modes is extremely broken in general. Not really useful as a reference implementation. :/ |
fantasai
added
Commenter Satisfied
This is about the special case described at the end of the "block" section, here:
https://drafts.csswg.org/css-align/#baseline-export
which was added in #2902.
Right now, that spec text says:
It appears we need to broaden the first part of that condition.
Right now, the special case specifically covers scenarios where the
inline-blockis a scroll container. But it doesn't cover the case where theinline-blockcontains a scroll container (and nothing else). Browsers render that scenario the same way, but the spec doesn't say they should, AFAICT.i.e. Browsers render these two divs the same (using their margin-bottom edge for baseline alignment):
Here's a real-world testcase demonstrating that browsers do in fact align them the same (using the margin-bottom for both): https://hg.mozilla.org/mozilla-central/raw-file/2064e7c799d2/layout/reftests/inline/inline-block-baseline.html
CC @tabatkins @fantasai
The text was updated successfully, but these errors were encountered: