Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
fantasai opened this issue Nov 26, 2016 · 7 comments
Closed

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

fantasai opened this issue Nov 26, 2016 · 7 comments
Labels
Closed Accepted by CSSWG Resolution Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. CSS2 css-align-3 Current Work css-inline-3 Current Work Needs Testcase (WPT)

Comments

@fantasai
Copy link
Collaborator

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.

@fantasai fantasai added css-align-3 Current Work css-inline-3 Current Work CSS2 labels Nov 26, 2016
@atanassov atanassov removed the Agenda+ label Feb 14, 2017
@atanassov
Copy link
Contributor

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

@fantasai
Copy link
Collaborator Author

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

Editted this in 4a2cd1f

@fantasai
Copy link
Collaborator Author

fantasai commented May 2, 2017

Marking as Needs Edits for CSS2.

@fantasai fantasai added the Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. label May 2, 2017
@fantasai fantasai reopened this May 3, 2017
@fantasai fantasai closed this as completed Apr 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closed Accepted by CSSWG Resolution Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. CSS2 css-align-3 Current Work css-inline-3 Current Work Needs Testcase (WPT)
Projects
None yet
Development

No branches or pull requests

6 participants