- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Nov 2022 23:12:54 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-align-3][css-multicol-1] First baseline of a multicol`, and agreed to the following: * `RESOLVED: We define the first baseline as the highest baseline in all the columns and spanners of the multicol` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-align-3][css-multicol-1] First baseline of a multicol<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/7856<br> <dael> iank_: Basically currently the spec says to take the first baseline from the first column<br> <dael> iank_: This has a couple of poor side effects<br> <dael> iank_: Came up while Morton reviewed new last baseline behavior<br> <dael> iank_: What can happen now is that if there is no content that produces a baseline in the first column it has no first baseline but might have last from another column<br> <dael> iank_: Two potential solutions. First is mirror last baseline and take highest of all content<br> <dael> iank_: Second is take the first baseline of the first non-empty thing. First thing that produces a baseline<br> <dael> astearns: And we are taking the lowest baseline for last baseline because it's often the case the first column has a much lower baseline<br> <dael> iank_: Correct. Not always, quite common for it to come from later<br> <dael> astearns: For symmetry taking highest baseline seems like might be better. No strong opinion<br> <dael> dholbert: I was going to say roughly same. Like simplicity of first that exists but asymmetry unfortunate<br> <dael> iank_: Pros and cons. First baseline if you're trying ot align it will roughly give you always first line on first column. Highest if you switch to smaller font size in another column that would be first highest. So pros and cons. Happy with either<br> <dael> dholbert: Do we generally have symmetry between first and last determined in other layout modes?<br> <dael> iank_: We broadly have symmetry.<br> <dael> iank_: Ignoring some convoluted table case. But wouldn't be an issue to break here. We found this because writing last baseline logic, noticed the asymmetry and went that's weird<br> <dael> astearns: In terms of what effect you want to have, presumably you're trying to align some other element with first baseline. First column will often be taller in a heading. If we take first baseline of column with a baseline the thing outside will align with the title. If we take heighest it will align with first body text. I can see either being useful<br> <astearns> ack fantasai<br> <dael> fantasai: I think you described what is the most likely scenarios<br> <dael> fantasai: We have an issue open on selecting which element you want to take baseline on. If we went highest and you wanted first you would be able to request that. That might be a reason to take highest<br> <dael> iank_: Fine with that<br> <miriam> I like that approach<br> <dael> astearns: And that way we get symmetry.<br> <dael> fantasai: We haven't worked out how this interacts with splitting element but can definte to work<br> <dael> astearns: Prop: We define the first baseline as the highest baseline in all the columns and spanners of the multicol<br> <dael> astearns: Obj?<br> <dael> dholbert: This is symetrically defined with last baseline. Does that take relpos into account?<br> <dael> iank_: It does not. Out of flow it does not and baselines are pre-relpos<br> <dael> dholbert: No objection. Just wanted to check<br> <dael> astearns: Good to check we're defining as in-flow<br> <dael> iank_: Probably don't have language but all engines are same<br> <dael> RESOLVED: We define the first baseline as the highest baseline in all the columns and spanners of the multicol<br> <fantasai> ACTION: fantasai to make sure we define that relpos doesn't affect baseline alignment<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7856#issuecomment-1301479565 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 November 2022 23:12:56 UTC