- 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
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