- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 09 Dec 2020 17:44:20 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-grid][css-flexbox][quirks] Avoid percentage height quirk in new layout models`, and agreed to the following: * `RESOLVED: dholbert to make a change to quirks spec to clarify behavior for flex and grid items and containers` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-grid][css-flexbox][quirks] Avoid percentage height quirk in new layout models<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5545<br> <TabAtkins> The nice part of this is that it inverts the grouping from "all variants of a given property" to "all properties associated with a given variant", which can be much more readable in some circumstances.<br> <dael> oriol: This is about this % quirk. When in the block axis you have % and your containing block has auto height in quirks mode sizing skips the ancestor until it find another with a definite height and resolves % against this<br> <dael> oriol: For compat reasons must happen in flow layout. Quirks spec says shouldn't happen for grid and flex<br> <dael> oriol: I'm prop we should say quirk should not skip over grid and flex items<br> <dael> oriol: The current behavior chromium has where grid item with auto height and inside an element with % height it's resolved from grid area not grid item. If item is stretched the height is supposed to be definite. But knowing if we will stretch before is tricky and i think it's bad to prop this to new layout modes<br> <Rossen_> q?<br> <dael> oriol: FF does not skip grid and flexbox items. WK skips flex not grid. Chromium skips both. I think we should align with FF and never skip<br> <dael> TabAtkins: I'm very satisfied to limit quirks here if other impl are<br> <dholbert> I'm happy to align with the Firefox behavior. :)<br> <dael> iank_: I'm okay with this...it's a pretty late hour to do this change to flexbox in particular but also grid. Chromium can try but might have revert if there's web compat issues.<br> <dael> iank_: I think WK is closer to chromium then issue says and I think it exposes a WK bug. I'm okay with this but want to reserve the right to go back if there's compat issues<br> <dael> Rossen_: One thing to double check, you said quirk shouldn't apply to anything in grid and flex items. I didn't hear you say anything about grid and flex items themself<br> <dael> oriol: Grid and flex items have grid or flex container parent and spec says about that already so already not happening.<br> <dael> Rossen_: Means later subgrid as well. If we all agree with rule, which makes sense, but we should define anything in a grid boundary should not have to take the quirk<br> <iank_> q+<br> <dholbert> q+<br> <dael> oriol: Not sure I would go that far. A grid item can have varied structure. If you have nested block we could keep the quirk. Maybe breaking that on whole tree of grid item would be more problematic<br> <astearns> ack iank_<br> <dael> Rossen_: Having had to impl this quirk twice it's super nasty. Less we have to do it the better. If we can't get away it is what it is<br> <dael> iank_: I forgot to say a couple things. Would it be possible to instead of relying on quirks spec pull it into flexbox and grid specs? Quirks spec doesn't necessary spec correctly and leaves open to interpretation<br> <dael> iank_: Also, would have been nice if when FF did the change this was brought up<br> <dholbert> talking, can't hear me?<br> <astearns> ack dholbert<br> <dael> dholbert: Sorry, I don't htink I did enough testing of other browsers when impl. I was aligning to quirks spec, I think.<br> <dael> dholbert: To forbidding quirk inside grid I think best way to think is it tunnels up through blocks and if you hit an unsupporting container it just stops. If you think of flex and grid as an unsupporting container you have it. It's not that flex items are special but that flex and grid container are special<br> <dael> Rossen_: I believe this is the exact issue. If flex or grid item fits the bill and has a spec height you can use in quirks algo this item can later stretch with a lot of properties that effect fixed height.<br> <dael> Rossen_: Fully agree we should have a stronger rule here about flex and grid items to have them not partake in quirks.<br> <astearns> ack fantasai<br> <dael> Rossen_: I don't disagree with anything you say, but the less we can have the nasty quirk the better<br> <dael> fantasai: Note on edits, I don't think makes sense to have in flex and grid. It's really a special behavior for block and anything other then that should not have quick. Quirks should say these boxes do this thing and if you hit any other kind you terminate.<br> <dael> fantasai: In flexbox and grid we'd have to list a lot of exceptions.<br> <dael> astearns: I agree it should be defined in one place<br> <dael> fantasai: We don't have a block layout spec so we don't have a plce to put it<br> <dael> astearns: I was thinking flex and grid specs could have a note saying we're not doing this thing for the reason it defines<br> <dael> fantasai: I don't think there's a natural place to put that. Update the quirks mode spec, at some point it goes into a block spec<br> <dael> oriol: Quirks mode mentions block containers, but grid and flex can be block containers<br> <dael> fantasai: Whatever correct term is. Seems related to block layout and not about flex or grid. It's not an exception, it's block being special and that shouldn't have anything to do with flex and grid<br> <dael> Rossen_: sizing?<br> <astearns> s/grid and flex/grid and flex items/<br> <dael> fantasai: It's special for blocks.<br> <dael> Rossen_: We have a lot of sizing things that apply to not everything<br> <dael> TabAtkins: I don't mind sizing since it will apply to table sizing as well<br> <dael> astearns: Do we need a resolution to move the definition of the quirk to sizing and be explicit about how it does not apply to grid and flex items<br> <dael> fantasai: Need to say it's only blocks and tables.<br> <dael> astearns: Might be good to have as an example b/c has been impl confusion<br> <dael> plinss: Need to be careful about is this really a quirk and only in a compat mode or is this normal css behavior?<br> <dael> fantasai: It' snot normal.<br> <dael> plinss: Then it should stay in quirks and not be in a normal module in my opinion<br> <dael> astearns: Fair. We do need to firm up the definition<br> <dael> fantasai: dholbert do you want to propose a change to quirks spec?<br> <dael> dholbert: I can take a look at it.<br> <dael> dholbert: FF behavior falls out of how I understodd quirks spec. I'll take a look<br> <jensimmons> I do think we need something to help future implementors / anyone who doesn't remember this call to know what to do if they are implementing Flex/Grid/Future stuff. Something far off on the side is too off in the side. A note, as Alan suggested, or something would be good.<br> <dael> astearns: Prop: dholbert to make a change to quirks spec to clarify behavior in this case<br> <dael> astearns: And iank_ is okay with it being tried in chromium to check for compat<br> <dael> plinss: Is this only in quirks or is it certain conditions of normal css?<br> <dael> ??: Only quirks mode<br> <dael> astearns: Objections?<br> <dael> iank_: Test would be nice as well<br> <dael> astearns: Yes. Test would have shown this earlier, but thanks oriol for finding. Can you write tests?<br> <dael> oriol: Didn't hear<br> <dael> astearns: Will need tests to show we have interop behavior. Could you commit to adding tests?<br> <dael> oriol: Yeah<br> <dael> oriol: I think FF already has tests. I'll look better and write some if needed<br> <dael> astearns: Would be great to have in WPT<br> <dael> RESOLVED: dholbert to make a change to quirks spec to clarify behavior for flex and grid items and containers<br> <dael> astearns: Anything else?<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5545#issuecomment-741938953 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 9 December 2020 17:44:23 UTC