search

w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.5k stars 665 forks source link

[css-align] Compatible alignments aren't always compatible #1556

Closed tabatkins closed 6 years ago

tabatkins commented 7 years ago

When grouping boxes into baseline-sharing groups for content-alignment, one of the checks we do is that the elements either have "stretch" or "start"/"end" self-alignment. This ensures that the contents all share an edge in the direction they want to align towards, preventing silly situations.

However, if an element is last-baseline-aligned, and is set to "stretch", but with a max-height smaller than the container's height, it won't line up with an "end" element (because, when "stretch" is constrained, it falls back to "start"). This makes them not compatible. We should handle this in the algorithm.

fantasai commented 7 years ago

There seem to be three ways to handle this case:

Tab and I are currently leaning towards the last option, since it seems the easiest to specify and implement and probably also the most author-friendly. Agenda+ to ask for opinions from the rest of the WG.

css-meeting-bot commented 7 years ago

The CSS Working Group just discussed Compatible alignments aren't always compatible, and agreed to the following resolutions:

The full IRC log of that discussion <dael> Topic: Compatible alignments aren't always compatible
<dael> github topic: https://github.com/w3c/csswg-drafts/issues/1556
<dael> There's an issue where we preform baseline content alignment on two items if their align: self allows them to both baseline align.
<dael> fantasai: However for last baseline we'd need both aligned to the bottom
<dael> fantasai: Otherwise if the boxes aren't the same size they're in different positions. If they're start o stretch fine. Does that make sense?
<dael> TabAtkins: The important bit is for last baseline they need to be end or stretch aligned to be compat.
<dael> fantasai: There's two types of baseline alignment. You shirnk wrap the box around content and move the box, that's self. Or the box can fill the area and you align the content in the box.
<dael> fantasai: There's two different propties so we can do both on a flex item. If you want content baseline alignement you need for that bo to be stretch to fill the whole row. Or you can do it if they're both start aligned so they grow downwards.
<dbaron> I don't see why the growing thing requires start
<dbaron> I also don't see how last-baseline is different for the growing thing
<dael> fantasai: That's fine for first baseline alignment, the box doesn't have to fillt he whole row. For last baseline if it's shorter than the entire row we have a rpoblem. We need to evaluate what to do. Our spec says if you're bottom or stretch aligned you can do last baseline. That's fine but if you have a width or max-width you're not necessarily stretched and you're aligned tot he top
<dael> fantasai: There's 3 ways to deal with this which are in the issue. 1 is exclude items with stretch and a height constraing. another is that if you ahve align self stretch and align last baseline you get bottom aligned instead of top aligned.
<dael> fantasai: 3rd is exclude items that are stretched only if the constraint is triggered.
<fantasai> https://github.com/w3c/csswg-drafts/issues/1556#issuecomment-311463877
<dael> fantasai: These are all in the issue^
<dael> fantasai: We need to pick one.
<fantasai> q+ dbaron
<dael> Rossen_: Going through our grid updates and doing this for grid items I'm pretty sure we did similar to #1 where constrion takes precendence over stretching. That makes sense and is mostly consistant except able cells.
<dael> Rossen_: Third seems more hacky where we're trying to make the fallback work. Does that mean constrints are ignored and, if yes, that's weird.
<dael> dbaron: I didn't understand a bunch of the premises.
<dael> dbaron: I don't understand why you can't combine start alignment with last basesline align content by aligning a different amount. Basically first or last with an alignment that says stick to one side says you have to move and laign the content. I don't see why that's different between first and last
<dael> TabAtkins: Let's say you have a whole bunch of vertical space. One is start and one is center. They're small and there's a ton of space so they don't overlap veritically. How do you content align that? You can't without breaking self align.
<dael> dbaron: I agree center is more itneresting. but doing baseline lignment generally requires you grow boxes. IN the case where they don't overlap you grow them by a lot.
<dael> TabAtkins: That would be so weird. I don't thinkt here's an obvoiusly correct way to choose which to grow. I doubt anyone would expect that to happen.
<dael> dbaron: You can...okay.
<dael> TabAtkins: Element have to grow, but this would require to grow an unbounded amount and it's not clear which should grow. If they share an edge they have a fairly obvious where they grow and how much.
<dael> Rossen_: In any of that, why would you decide to override the min/max constraint?
<dael> TabAtkins: We're not. If a max is there it can make stretch not compat with end alignment. That's why one suggestion was strech falls back to end.
<dael> dbaron: What does fallback align mean?
<dael> TabAtkins: If you can't fully align based on self you fallback to something that can be adhered to. If you can't grow enough in the left over space, we fallback to start by default.
<dael> Rossen_: Your third option you said it's end or start?
<dael> TabAtkins: Yeah. In this case if you're trying to last baseline align a stretch item we would do an end fallback.
<dael> Rossen_: Why? Why not start?
<dael> TabAtkins: It means you can't align because if your alignments aren't compat there's no obvious way to make ti work.
<dael> Rossen_: You have an items that's too small and cannot grow and you have to decide it goes to top or bottom. You're deciding if it's last baseline it goes toward the bottom. Why?
<dael> TabAtkins: So it's compat and last is possible. If it goes to start you cannot do last baseline alignment in a reasonable manner.
<dael> Rossen_: I need to look at test cases.
<Bert> (Seems to me that, even if you align to the bottom, there is still a chance that is needs to grow more than max-height to align the last baseline...)
<dbaron> OK, I think I'm ok with your suggested option #3 now.
<dael> TabAtkins: This one is simple. Last nie of text in a box. One is last aligned, the other tries to stretch but can't get bit enough. It's impossible fo the box to grow so that the last line can get down and align b/c the heigh constraint. Only want to make so is that the end edges align. If they're not sharing same vertical space you can't relably do a baseline alignement.
<dael> Rossen_: Proposal is option #3?
<dael> TabAtkins: We prefer option 3 because it means more things can baseline align. It's changing a currently undefinable default. Other 2 would also work, but they break the baseline alignment and we feel in this case it's better to try and honor.
<dael> Rossen_: All three are acceptable solution.
<fantasai> +1 to everything Tab said
<dael> Rossen_: Opinions?
<dbaron> I guess #3 probably seems better than #1 and #2, although there is the random complexity...
<dael> Bert: Is it actually a solution? It seems there are two cases where you get conflicts. Say you have two items you want to align to last baseline, first is very small with small height. second is very tall.
<dael> TabAtkins: That's a natural break of baseline and is handled. First small one overflows upwards. Since it can't, it'll break the alignment and sit still.
<dael> Bert: So you say the htree solutions aren't 100%, they jsut imporovet he solution.
<dael> TabAtkins: Yes. The one you brought up is unsolvable, but what we're tyring to do is solve one where an undefinable default is causing the break. We want to make the default a little smarter.
<dael> Bert: I'm oakyw ith option #3.
<dael> Rossen_: Other opinions?
<dael> Rossen_: dbaron preference?
<dael> Rossen_: Oh, I see in IRC #3
<dael> Rossen_: Let's call to resolve on option #3?
<dael> Rossen_: Objections?
<dael> gregwhitworth: Would anybody see authors expecting for the stretch to still be adhered to where it goes upwards? Like it does #3 but still stretches.
<dael> TabAtkins: THis is when max-height is in play and we honor that over other constriants.
<dael> gregwhitworth: I was just curious if an author wants the inverse.
<dael> Rossen_: Authors want rainbows and unicorns but we can't deliver them so we need to honor the constraints and have an okay default.
<dael> Rossen_: I don't hear objections.
<dael> RESOLVED: Option 3 from issue
fantasai commented 7 years ago

Okay, I fixed the case we talked about.

We forgot another case: suppose we have two end-aligned things and they have specified safe overflow. They will behave as start-aligned. Do we force unsafe alignment in this case or bail and break baseline alignment or what?

css-meeting-bot commented 7 years ago

The CSS Working Group just discussed Compatible alignments aren't always compatible, and agreed to the following resolutions:

The full IRC log of that discussion <dael> Topic: Compatible alignments aren't always compatible
<dael> github: https://github.com/w3c/csswg-drafts/issues/1556
<dael> Rossen_: Can you summerie fantasai ?
<dael> fantasai: We opened this and resolved on some. The cases where you have a stretch item and a last basesline aligned. If you have content alignment you can alight stretch items. As lng as the stretching takes effect. If the stretching is constrained we resolved that since there's an explicit need to align to top or bottom t hat's fine. We're covered.
<dael> fantasai: If you have 2 end aligned things that norminally are last basseline content alignment, but if one is overflowing and safe alignment it would end up start aligned. So what do we do for that thing?
<dael> fantasai: Does everything shift down and do unsafe, do we bail where if you overflow we don't do baseline? We need to figure out and i don't have a clear proposal.
<dael> fantasai: You have 2 items, self align to the end. They have content baseline alignment. One of them happens to be bigger than the box, but has safe alignment so it'll overflow the bottom. What do we do?
<dael> fremy: I'm saying that i don' tknow if we need to baseline align It seems like an error. I'd be fine saying we don't baseline align and just give up.
<dael> Rossen_: You favor where baseline align is ignored?
<dael> fremy: Yes.
<dael> fremy: Yes, IRC is right.
<dael> Rossen_: fantasai do you ahve a strong opinion?
<dael> fantasai: Options are we perform las tbaseline alignment and treat all as overflow. Alternative is to say the overflow thing can't be last baseline.
<dael> Rossen_: And i think that second is what fremy was pointing out.
<dael> Rossen_: From impl PoV I would also favor the second. It would be good to hear from more people.
<dael> Rossen_: If there are no other opinions we can try and resolve or postpone to F2F with a whiteboard and more people.
<dael> Rossen_: Preference?
<dael> fantasai: I'm okay resolving to bail on baseline alignment and if this happens that item can't participate.
<dael> Rossen_: Fine to me. Prop: Such alignments that overflow will not participate in last baseline alignment. Obj?
<dael> RESOLVED: Such alignments that overflow will not participate in last baseline alignment