[css2][css-align] Last Baseline Alignment of Scrollable Boxes

[fantasai]

CSS Align had this sentence, which has been sitting around for awhile:

For the purposes of finding the first (last) baselines of a box, it and all its in-flow descendants with a scrolling mechanism (see the 'overflow' property) must be considered as if scrolled to their origin (final) position.

CSS2.1 had this sentence:

The baseline of an 'inline-block' is the baseline of its last line box in the normal flow, unless it has either no in-flow line boxes or if its 'overflow' property has a computed value other than 'visible', in which case the baseline is the bottom margin edge.

Myles raised an issue against CSS2.1 https://lists.w3.org/Archives/Public/www-style/2015Mar/0342.html requesting a change to make overflow have a less dramatic effect baseline alignment. which the CSSWG later accepted https://lists.w3.org/Archives/Public/www-style/2015Apr/0144.html

I'm reraising this issue because I think the wording in CSS Box Alignment seems to solve Myles' issue in a somewhat more useful way, and perhaps we should reconsider how last-baseline alignment works in the presence of overflow.

[atanassov]

We discussed this during Feb 8 CSSWG telcon and decided to continue working on the issue here. Removing the Agenda+ label for now.

[fantasai]

The concerns from the call were wrt Web compat vs use cases: no browsers implement the css-align wording above, but the CSS2.1 erratum (which is also not interoperably implemented) does not allow useful handling of last-baseline alignment in situations that have overflow.

[tabatkins]

In other words, when the content doesn't overflow, Myles' text and Align's text give the same results; when the content does overflow, they give slightly different results, but Align's makes more sense (actually aligns to text).

[css-meeting-bot]

The CSS Working Group just discussed last baseline alignment of scrollable boxes.

The full IRC log of that discussion

<dbaron> Topic: last baseline alignment of scrollable boxes
<dbaron> Github topic: https://github.com/w3c/csswg-drafts/issues/766
<shane> ScribeNick: shane
<shane> if you have a scrollable box with content
<shane> fantasai: if you have a scrollable box with content
<shane> ... last baseline, once content is higher than box
<shane> ... most recent resolution was that if last baseline is above the fold then use that, if below the fold then floor at bottom margin edge
<shane> ... previously just used bottom margin edge regardless
<shane> ... tab and I want to suggest that once scrolling offscreen, scroll whole box to the bottom and pick last baseline at final scroll position.
<shane> myles: in order to know where baseline is then you need to do a scroll, look at baseline, unscroll?
<shane> fantasai: just need to figure out bottom scroll position then find last baseline's position then subtract bottom scroll position from it
<shane> dbaron: what if there's a bunch of whitespace and when you scroll to the bottom your last baseline is way up?
<shane> smfr: does this apply to overflow: hidden as well as overflow: scroll?
<shane> ... an alternative is to align to the baseline of the last visible line (i.e. the one you can see)
<shane> dbaron: that's weird because different font metrics could make it pop differently
<shane> smfr: won't you get popping with this too?
<shane> iank_: can we just consider this an edge case?
<shane> Florian: what's the use case?
<shane> Rossen: DIY form controls
<shane> iank_: if you've got a eula at the bottom of a form, e.g.
<shane> Rossen: in the non-overflowing case it makes sense to align to the bottom line, I think we all agree to that much
<shane> dbaron: I agree it's abstractly sensible. But we have interop on the opposite right now.
<shane> fantasai: WebKit implements the proposed behavior and has for many years. So no interop.
<shane> Rossen: which means nobody cares?
<shane> tantek: so we have interop except for WebKit
<shane> fantasai: yes, WebKit's behavior is higher quality than the specced behavior
<shane> Florian: and this means there isn't evidence that there's dependence on either behavior
<shane> myles: So are there other use cases than a select box?
<shane> flackr: proposed behavior is has discontinuity - if baseline falls below margin then it might suddenly jump upward
<shane> fantasai: no
<shane> Rossen: do you have the problem of baselines above box today?
<shane> myles: we just take the ???
<shane> dbaron: people often put a page of blank text below scrollable areas
<fantasai> s/blank text/blank space/
<shane> myles: ???
<shane> Rossen: which is less than optimal for when there's no overflow
<shane> myles: resolution was 3 years ago, hasn't been any movement so far
<shane> fantasai: it is in CSS Box alignment module which is about to hit CR
<shane> Rossen: when you changed this were there use case motivations?
<shane> myles: from what I remember it wasn't use case based. I was working on some site compatibility problem
<shane> ... something like a row of icons and we were shifting them vertically
<shane> Rossen: which was dbaron's concern - that we might start breaking such content
<shane> ... I share that
<shane> iank_: reiterating: currently 3 impls just do the end margin edge. Current resolution is to do last baseline if no overflow, otherwise end margin edge.
<shane> myles: logic was that if text shorter than block, putting overflow: hidden on should have no effect.
<shane> iank_: that's different to no overflow though, right?
<shane> myles: nope, *draws*
<shane> iank_: but if you have a massive box with no text and it triggers overflow, then last baseline would go to end margin edge?
<shane> smfr: I posted a codepen with examples
<shane> ... (https://codepen.io/anon/pen/Wjreqe)
<shane> fantasai: that's not clear.
<shane> ... if the last baseline is above the bottom edge and there's no overflow, why would you jump if there was overflow?
<shane> ... baseline should be the bottom edge only if it would otherwise be below
<shane> myles: that describes what we currently do
<shane> iank_: OK so if there's overflow you still look at the last baseline of the text
<shane> fantasai: seems weird we're clamping to the margin edge rather than something where the text stops being visible like border box
<shane> Rossen: OK so back to myles' comment, is anyone actually going to change this?
<shane> smfr: I can't see any difference between browsers in this codepen. I think I've captured the behavior.
<shane> [divers alarum]
<shane> smfr: OK I've updated the codepen and the 3rd box now has a different baseline in browsers
<shane> ... Safari differs from everyone esle
<shane> s/esle/else
<shane> fantasai: and Safari's behavior is what we resolved on
<shane> Rossen: so this is what's defined in the alignment spec?
<shane> fantasai: yup
<shane> Rossen: do we need to resolve anything further?
<shane> fantasai: only if we want to change it, e.g. what we proposed or change margin-box to padding-box
<shane> Rossen: border?!
<shane> fantasai: padding!?
<shane> Rossen: don't need to decide on border vs. padding right now
<shane> fantasai: trying to take spec to CR, need to close off the issues. Could maybe decide after lunch though?
<shane> <br type="lunch">

[css-meeting-bot]

The CSS Working Group just discussed Last Baseline Alignment of Scrollable Boxes, and agreed to the following resolutions:

RESOLVED: change bottom margin edge to bottom border edge

The full IRC log of that discussion

<astearns> topic: Last Baseline Alignment of Scrollable Boxes
<astearns> github topic: https://github.com/w3c/csswg-drafts/issues/766
<myles> fantasai: the last thing I heard: suggestion: floor it at the bottom border edge
<myles> Rossen: <deliberately nods>
<myles> fantasai: 3 options: 1. leave it as is. 2. Change from bottom margin edge to bottom border edge. 3. Scroll to the final position, take the last baseline.
<myles> fantasai: suggestion is #2
<fantasai> s/suggestion/aforementioned suggestion/
<myles> Rossen: what does "leave as is" mean?
<myles> fantasai: what the spec says now
<myles> Rossen: then there's no reason to do #1
<dbaron> I'm happy with either #1 or #2; I think #3 has some issues that would need to be sorted through.
<myles> astearns: objections to #2?
<fantasai> dbaron, do you want to see those investigated?
<myles> RESOLVED: change bottom margin edge to bottom border edge
<dbaron> fantasai, no need if we're just going to do #2
<myles> fantasai: we're done! Woop woop!

[tabatkins]

Editted this in 4a2cd1f

[fantasai]

Marking as Needs Edits for CSS2.