- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 15 Sep 2023 14:22:26 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-grid-3] Masonry - Intrinsic sizing of tracks & masonry-grid doesn't produce to good/desirable results. `, and agreed to the following: * `RESOLVED: Remove first-row-is-special handling of intrinsic track sizing in Masonry spec, replace with all auto-placed items contribute to all intrinsically sized tracks` <details><summary>The full IRC log of that discussion</summary> <emeyer> iank_: Spec as it was initially introduced has some awkward placement + intrinsic size outcomes<br> <emeyer> …In grid layout, you have to put everything into areas and then size areas based on that placement<br> <emeyer> …Masonry layout is kind of backwards, in that you place your item into the highest available track<br> <emeyer> …The original spec got around this, but by placing everything into the first column after it had placed an item in each track, this had a lot of bad side effects around intrinsic sizing<br> <emeyer> …You can have intrinsically sized track and something goes into the second column, the column might not be wide enough<br> <emeyer> TabAtkins: The upshot is part of our larger argument that masonry shouldn’t be defined on top of grid because of the inside-out ness<br> <astearns> ack emilio<br> <astearns> ack fantasai<br> <emeyer> …We think masonry should be its own display type that can have its own layout approach and maybe some new features that aren’t possible as long as it’s based on grid<br> <emeyer> fantasai: I’d like to sidestep display types and focus on sizing<br> <emeyer> …We a gree with Ian that it’s not ideal and speccing something out that handles intrinsic sizing on its own terms makes sense<br> <emeyer> …We’d like to spec that out in the editor’s draft<br> <emeyer> …Asking for a resolution to remove the “first row is special” thing from the spec<br> <iank_> q+<br> <emeyer> …And add l anguage to keep intrinsic sizing from being dependent on placement<br> <emeyer> …If we embed into grid, this is a bit more complicated<br> <astearns> ack iank_<br> <emeyer> astearns: This reworking is necessary whether we change display types?<br> <emeyer> fantasai: Yes<br> <emeyer> iank_: I don’t think it’s that simple because there are a lot of touchpoints with the grid specification<br> <emeyer> …Regarding placement in the non-masonry axis regarding how the element contributes<br> <emeyer> …I’m a little concerned that implementations-wise, there’s lots and lots of edge cases that rely on grid placement<br> <astearns> ack fantasai<br> <emeyer> fantasai: I recognize that this is complicated, but I’d like to at least try<br> <emeyer> …We can definitely come back to where we are if our proposal isn’t workable<br> <emeyer> iank_: We could work out the issues in a PR<br> <emeyer> fantasai: True, but the Draft is a draft and we all agree the current draft isn’t what we want<br> <emeyer> iank_: I think the Microsoft folks had a look and came to similar conclusions<br> <emeyer> …I want to avoid falling into quadratic behavior with variable track sizes<br> <emeyer> …When I originally wrote this up, I thought it could be mitigated, but now I’m pretty strongly in the camp we’ll need a new display type<br> <emeyer> astearns: I propose we task Elika and Ian to work on a PR and come back to the group<br> <emeyer> fantasai: Can we please land changes in the ED and iterate until we either have a solution or decide we can’t?<br> <fantasai> It's an "editor's draft" for a reason.<br> <fantasai> This is exactly what editor's drafts are for<br> <emeyer> jensimmons: It sounds like there’s a lot of disagreement between Appole and Google on this<br> <emeyer> astearns: I was thinkg of it more as “let’s collaborate” so we know whatever gets into the draft won’t have immediate objections<br> <emeyer> jensimmons: I think there’s good questions about implementability and speed, and Ian’s skepticism is perhaps correct<br> <emeyer> …We want to push further down the road<br> <TabAtkins> It wasn't minus, but I said "yes, please work in the ED"<br> <emeyer> astearns: So we propose Elika fix up the Editor’s Draft and bring it back<br> <emeyer> iank_: Okay with me<br> <TabAtkins> s/minus/minuted/<br> <emeyer> fantasai: If we’re going to stick with the grid model, we should go this direction<br> <emeyer> astearns: I want to avoid resolving on a direction since we don’t know what the direction will be<br> <emeyer> fantasai: I think we need to take Ian’s approach contributions of all auto sized items in every auto sized track<br> <emeyer> …Updating the draft to say that we want to push in that direction seems to make sense to me<br> <emeyer> iank_: Yes, the direction, like, when I proposed this direction I didn’t see all the complications I now see<br> <emeyer> …If we want to go down the grid path, I’m not sure this path is workable<br> <emeyer> …I’m fine with editing the ED with a large scary note that details what’s being worked out<br> <emeyer> jensimmons: There’s an inconsistency between how this is being handled and how anchor positioning is being handled<br> <emeyer> …We have real objections about try blocks and they’re not being heard, but here similar objections are being taken seriously<br> <TabAtkins> We've already said that we'd like fantasai to continue iterating on this in the Grid 3 ED. Unsure what the complaint is.<br> <fantasai> proposal: Remove first-row-is-special handling of intrinsic track sizing in Masonry spec, replace with all auto-placed items contribute to all intrinsically sized tracks<br> <emeyer> astearns: Elika, can you state the proposed resolution?<br> <fantasai> Also: add a scary warning<br> <fantasai> :)<br> <emeyer> RESOLVED: Remove first-row-is-special handling of intrinsic track sizing in Masonry spec, replace with all auto-placed items contribute to all intrinsically sized tracks<br> <TabAtkins> I'm here ://///<br> <TabAtkins> Dang zoom<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8206#issuecomment-1721366240 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 15 September 2023 14:22:28 UTC