W3C home > Mailing lists > Public > public-css-archive@w3.org > April 2017

Re: [csswg-drafts] [css2][css-align] Last Baseline Alignment of Scrollable Boxes

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 19 Apr 2017 04:14:26 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-295076343-1492575264-sysbot+gh@w3.org>
The CSS Working Group just discussed last baseline alignment of scrollable boxes.

<details><summary>The full IRC log of that discussion</summary>

```
<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">
```
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/766#issuecomment-295076343 using your GitHub account
Received on Wednesday, 19 April 2017 04:14:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 10:12:53 UTC