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

[css-align][css-tables][css-flex] Synthetized baselines seems like a breaking change #373

Closed
FremyCompany opened this Issue Aug 2, 2016 · 9 comments

Comments

@FremyCompany
Contributor

FremyCompany commented Aug 2, 2016

The new specs states that baseline alignment shouldn't happen to synthetized baselines when alignment happens in a container with a top and bottom instead of just a text line (something along those lines).

This is a breaking change for flexbox and css-tables, and I think we should talk about this now.


Also, about synthetized baselines, I understand tables align to baselines even things that have a synthetized baselines, and I don’t think we wanna change that. Maybe we need to clarify that somewhere?

Yes, we need to do that.

Where do you think we should write that statement? In the table spec, or as part of the changed text you introduced?

I am also worried there might be compat issues for flexbox that would prevent us from doing the change there. I think that's a question we should bring up to the Working Group for consideration.

@FremyCompany

This comment has been minimized.

Contributor

FremyCompany commented Aug 12, 2016

@FremyCompany

This comment has been minimized.

Contributor

FremyCompany commented Aug 17, 2016

The distinction was mainly intended to ease issues related to block-aligned axis. Since that feature was dropped, we can now safely close this issue as well, with the resolution that we will continue to synthetize baselines on everything in the inline axis as we did before.

We resolved so in today's working group telcon.

@fantasai

This comment has been minimized.

Contributor

fantasai commented Aug 26, 2016

Reopening because this isn't entirely resolved. The current situation is as follows:

  • Flexbox is underspecified wrt items without baselines (in particular, flex items with display: block don't have a defined baseline).
  • Flexbox requires items that have a writing mode orthogonal the baseline-alignment axis to be flex-start aligned.
  • The baseline of a flex container itself is synthesize from its first item’s content box (or its own content box, if it has no items).

https://drafts.csswg.org/css-flexbox/#flex-baselines

  • Firefox aligns items without baselines and those with orthogonal writing modes at their bottom margin edge.
  • Chrome aligns items without baseline at the bottom border edge and uses start-alignment for orthogonal writing modes.
  • Edge has the same behavior as Chrome [edit by Rossen]

http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4416

There's a few concerns here:

  1. Probably, boxes in orthogonal flows and boxes without a natural baseline should be treated the same.
  2. It's uncertain whether authors want such items to have a “baseline” alignment, or whether merely having them fall back to start alignment would be sufficient.
  3. The inline-layout practice of using the margin edge is useless when the margin is positive because it does not align anything visible to the baseline. The author could use negative margins to control the alignment point, but that risks overlapping content.
  4. In grid layout, we have items that can span multiple rows; in this case baseline-aligning the bottom edge of the item could be awkward.

Further notes:

  • The alignment point of a box without a baseline set can be controlled with the alignment-baseline property; it will use the top/center/bottom as appropriate. Which edge is used (margin/padding/border/content) is not controllable, however. A future property may allow more precise control of how baselines are synthesized, though.
  • Inline layout synthesizes a baseline from the margin edge of an item. Note it performs baseline self-alignment (shifting the box itself).
  • Table layout synthesizes a baseline from the content edge of a cell. note it performs baseline content-alignment (adding extra padding to shift the content within the box).

Proposals:

  • A. Make boxes without a natural baseline and boxes establishing an orthogonal flow synthesize a baseline.
    • A.1 Base this synthesized baseline on the margin box edges
    • A.2 Base this synthesized baseline on some other box edge
  • B. Make boxes without a natural baseline and boxes establishing an orthogonal flow use start alignment instead of trying to synthesize a baseline.
  • C. Something else.

Questions to consider:

  • Do authors need or want synthesized-baseline alignment? If not, falling back to start is simpler.
  • Are there considerations wrt implementation complexity?
@FremyCompany

This comment has been minimized.

Contributor

FremyCompany commented Aug 27, 2016

I thought we resolved on A already during last telcon?

For baseline alignment the conclusion was we keep synthesizing baselines for everything

Except if we really want rediscuss that, that leaves A1 vs A2. I guess for the sake of consistency, we should probably just have the behavior of flex be the same as a table-row (and therefore use margin box?), though I have no strong opinion on that.

@astearns astearns removed the Agenda+ label Aug 30, 2016

@astearns

This comment has been minimized.

Member

astearns commented Aug 30, 2016

Not sure it's ready for the meeting again - please add the tag back if it is

@fantasai fantasai added the Agenda+ label Aug 30, 2016

@fantasai

This comment has been minimized.

Contributor

fantasai commented Aug 30, 2016

Table rows don't use the margin box, they use the content box of the cells.

@fantasai

This comment has been minimized.

Contributor

fantasai commented Aug 30, 2016

And no, we didn't resolve on this. That was a comment from me about our conclusion, but it was not a WG resolution. Comments from some random WG member in a meeting, even if minuted, do not constitute a WG resolution. WG resolutions are things that are specifically and explicitly called out in a RESOLVED line.

@FremyCompany

This comment has been minimized.

Contributor

FremyCompany commented Aug 31, 2016

Just adding this test case for tables, since I wrote it anyway:
https://jsfiddle.net/8c88yb7q/1/

@fantasai

This comment has been minimized.

Contributor

fantasai commented Sep 6, 2016

CSSWG resolved on A.2 - synthesize from border box.
https://lists.w3.org/Archives/Public/www-style/2016Sep/0000.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment