- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 18 Jul 2023 22:23:47 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-flexbox] Intrinsic main size algorithm for row flexboxes not web compatible`, and agreed to the following: * `RESOLVED: take existing algo, mark it as informative, and explain why that is.` * `RESOLVED: spec what chrome has implemented in canary currently` <details><summary>The full IRC log of that discussion</summary> <bramus> iank_: currently all the implemrentations have same interop algo for single line row flexboxes<br> <bramus> … this however does not take a bunch of stuff like flex basis<br> <bramus> … effort by tab and elika to specify an algo that would be compatible that takes all that suff into account<br> <bramus> … chrome has been experimenting with this algo<br> <bramus> … and tried to ship on canary. tldr is that currently spec algo is not web compatible<br> <bramus> … we added test cases for sites that we know that we broke<br> <bramus> … impact was very very wide<br> <bramus> … we broke a lot of stuff, like gmail<br> <bramus> … we are likely a lot or compat constrained<br> <bramus> … have a proposed algo, that we have been running in canary and we have not broken anything (yet)<br> <bramus> … I think this is a floor for us to start<br> <bramus> TabAtkins: we}ve been avoiding looking at this issue for a while<br> <bramus> … i need to refresh my brain on why this case gets 300px wide in the spec<br> <bramus> iank_: keep in mind that is only 1 of the issues that we ran into, there is at least 5 different issues that we run into that are subtly different<br> <astearns> q?<br> <bramus> … we tried a variation where we tried to fix a few things when the flex fraction is ??? its not gonna work. we are very compat constrained<br> <bramus> … we think that we can go for a super relative small incremental fix, that fill fix the ??? case that will fix some flex basis being a definite thing.<br> <bramus> … roughly it is if the flex base size is greater than the main contribution and it cant shriink then use that. same for growing and same for max contributions.<br> <bramus> … for other things we are way more compat constrained<br> <bramus> … we broke everything<br> <astearns> ack fantasai<br> <bramus> fantasai: there are two havles to intricinsic size computation. min and max content sizing<br> <bramus> … these are different in a bunch of cases. did we break both of them?<br> <bramus> iank_: yeah, both<br> <bramus> … got reports for both<br> <bramus> fantasai: the min content stuff we wer etyring to make it there was no overflow within the items. so the ??? was larger than the naive version for party that reason<br> <bramus> … the max content one we get a size that is bigger but also dont get the max content size if you do the current behavior, which does not seem like it satisifes the use case?<br> <bramus> iank_: need to check, but we also broke the max content size. people have relied on current behavior because we have good interop. wet hink we can get away with respecting flex-basis as described bc that is very broken<br> <bramus> … is running on canary, so we might identify issues<br> <bramus> fantasai: seems unfortunate, bc we cant size a flexbox to fit its content<br> <bramus> … like you get a random size<br> <bramus> astearns: proposed change is to revert the algo?<br> <bramus> fantasai: this was original algo that was never implemented<br> <bramus> iank_: we tried to implement to see if its compatible<br> <bramus> astearns: how did we manage to get to interop?<br> <bramus> fantasai: were doing a much more naive implementation. if you take a flex-grow that wraps, then it would just pretend there is 1 row and next content would be widest item which is not the case.<br> <bramus> … that kind of thing were a simple approach was taken ???<br> <bramus> … people are therefore relying on werid behavior<br> <bramus> iank_: i think we can fix flex-wrap column case<br> <bramus> fantasai: the hardest one<br> <bramus> iank_: like col wrapping flexbox boxes are mininal while the nhnmber of row flexboxes is hight<br> <bramus> fantasai: I have not dug into this issue, but wonder if we at some point might need a switch sizes properly<br> <bramus> iank_: I think we can get a long way there. ???. it would be nice, but i am not hearing from devs about the brokenness, as opposed to the column wrap case<br> <bramus> … the row case is “sure, whatever”. dont know how much value there is in a switch for devs.<br> <bramus> … we would have had a lot more reports about it<br> <bramus> astearns: so, waht do we want to do?<br> <bramus> fantasai: I think tab and I are gonna need to do a follow up and figure ou twhat spec changes are needed and also what comes back from web compat<br> <bramus> iank_: having a quick look at definitvie flex basis case is pretty simple. we are 90% sure that we can do this change.<br> <bramus> … it seems like a col wrap case and not a lot people set a flex basis<br> <bramus> … if we get a resolution about path forward with flex basis algo then we can roll forward. wont push to beta channel without out<br> <bramus> fantasai: seems like step in right direction. we should take resolution to support going in this direction<br> <bramus> TabAtkins: yeah<br> <bramus> iank_: yeah, we think this is a flaw and that we can ship this<br> <bramus> … incremental changes<br> <bramus> … i think that is path forward<br> <bramus> fantasai: from spec perspective we ???<br> <bramus> astearns: take the algo that is in the spec that turned out to be problematic from a compat concern, leave it in the spec as informative note with explanation about it being a note and then add this 1 change so that blink can try shipping<br> <bramus> fantasai: it is creating an algo for … we have to draft the algo + blink change<br> <bramus> … it is adding a new algo<br> <bramus> … i agree on keeping it as informative note<br> <bramus> … with mention that we ar egoing to tweak it more<br> <bramus> iank_: at the very least, also writing down what browsers are currently doing<br> <bramus> … and the incremental thing<br> <bramus> astearns: so first resolution is to take existing algo, mark it as informative, and explain why that is.<br> <bramus> astearns: objections?<br> <bramus> RESOLVED: take existing algo, mark it as informative, and explain why that is.<br> <bramus> fantasai: second bit is to tentatively spec what chrome has implemented, and mark it as tentative<br> <bramus> iank_: also tweak it if there is feedback<br> <bramus> astearns: objections?<br> <bramus> astearns: with intent to improved it as much as we can<br> <bramus> astearns: proposed is to tentatively spec what is interoperable for this area of flexbox sizing, and mark it as tentative<br> <bramus> fantasai: I’d rather spec what chrome is doing<br> <bramus> astearns: other browsers any concerns about this?<br> <bramus> dholbert: seems fine to me<br> <TabAtkins> sammy_gill ?<br> <bramus> sammy_gill: double check that is the conservative and web compatible version<br> <bramus> iank_: yes, web compatible up to canary<br> <bramus> … we might find out that we broke stuff when pushing to beta<br> <bramus> astearns: and you said you found 6 issues?<br> <bramus> iank_: yes, we’ve had cases that broke large sites<br> <bramus> RESOLVED: spec what chrome has implemented in canary currently<br> <bramus> TabAtkins: it is in the thread<br> <bramus> astearns: (missed)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8884#issuecomment-1641069059 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 18 July 2023 22:23:49 UTC