- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Jul 2017 17:02:42 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Compatible alignments aren't always compatible`, and agreed to the following resolutions: * `RESOLVED: Option 3 from issue` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Compatible alignments aren't always compatible<br> <dael> github topic: https://github.com/w3c/csswg-drafts/issues/1556<br> <dael> There's an issue where we preform baseline content alignment on two items if their align: self allows them to both baseline align.<br> <dael> fantasai: However for last baseline we'd need both aligned to the bottom<br> <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?<br> <dael> TabAtkins: The important bit is for last baseline they need to be end or stretch aligned to be compat.<br> <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.<br> <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.<br> <dbaron> I don't see why the growing thing requires start<br> <dbaron> I also don't see how last-baseline is different for the growing thing<br> <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<br> <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.<br> <dael> fantasai: 3rd is exclude items that are stretched only if the constraint is triggered.<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/1556#issuecomment-311463877<br> <dael> fantasai: These are all in the issue^<br> <dael> fantasai: We need to pick one.<br> <fantasai> q+ dbaron<br> <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.<br> <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.<br> <dael> dbaron: I didn't understand a bunch of the premises.<br> <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<br> <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.<br> <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.<br> <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.<br> <dael> dbaron: You can...okay.<br> <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.<br> <dael> Rossen_: In any of that, why would you decide to override the min/max constraint?<br> <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.<br> <dael> dbaron: What does fallback align mean?<br> <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.<br> <dael> Rossen_: Your third option you said it's end or start?<br> <dael> TabAtkins: Yeah. In this case if you're trying to last baseline align a stretch item we would do an end fallback.<br> <dael> Rossen_: Why? Why not start?<br> <dael> TabAtkins: It means you can't align because if your alignments aren't compat there's no obvious way to make ti work.<br> <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?<br> <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.<br> <dael> Rossen_: I need to look at test cases.<br> <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...)<br> <dbaron> OK, I think I'm ok with your suggested option #3 now.<br> <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.<br> <dael> Rossen_: Proposal is option #3?<br> <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.<br> <dael> Rossen_: All three are acceptable solution.<br> <fantasai> +1 to everything Tab said<br> <dael> Rossen_: Opinions?<br> <dbaron> I guess #3 probably seems better than #1 and #2, although there is the random complexity...<br> <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.<br> <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.<br> <dael> Bert: So you say the htree solutions aren't 100%, they jsut imporovet he solution.<br> <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.<br> <dael> Bert: I'm oakyw ith option #3.<br> <dael> Rossen_: Other opinions?<br> <dael> Rossen_: dbaron preference?<br> <dael> Rossen_: Oh, I see in IRC #3<br> <dael> Rossen_: Let's call to resolve on option #3?<br> <dael> Rossen_: Objections?<br> <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.<br> <dael> TabAtkins: THis is when max-height is in play and we honor that over other constriants.<br> <dael> gregwhitworth: I was just curious if an author wants the inverse.<br> <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.<br> <dael> Rossen_: I don't hear objections.<br> <dael> RESOLVED: Option 3 from issue<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1556#issuecomment-314833215 using your GitHub account
Received on Wednesday, 12 July 2017 17:02:48 UTC