- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 01 Oct 2025 15:31:35 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-grid-3] The initial value of `item-tolerance` should be 0``, and agreed to the following: * `RESOLVED: close no change` <details><summary>The full IRC log of that discussion</summary> <ydaniv> astearns: last time it was inconclusive and wanted more info added to the isseu<br> <ydaniv> ... so what are we discussing?<br> <ydaniv> fantasai: TabAtkins and I believe it should be the initial value of gap<br> <oriol> q+<br> <ydaniv> astearns: last time it wasn't conclusive<br> <ydaniv> fantasai: where are we stuck here?<br> <astearns> ack oriol<br> <ydaniv> oriol: my preference is still towards 0, since most JS libs are using that<br> <kbabbitt> q+<br> <ydaniv> ... providing a prositive value by default, it depends too much on what content you have and will cause more confusion than being useful<br> <ydaniv> ... but not strongly object otherwise<br> <astearns> q+<br> <ydaniv> fantasai: TabAtkins and I wanted a value that would be noticeble, and a few pixels won't be<br> <ydaniv> ... we could pick between 16 px or ...<br> <astearns> ack kbabbitt<br> <ydaniv> ... 1em is one value we have prececdent for<br> <ydaniv> kbabbitt: do we have feedback from authors?<br> <oriol> q+<br> <ydaniv> almaher: we do suppet it but haven't heard from authors<br> <fantasai> s/16 px .../16px or 10px or something like that, but/<br> <ydaniv> kbabbitt: would it worth having more data from social media?<br> <ydaniv> fantasai: I think it may be problematic to have different layouts<br> <ydaniv> astearns: guessing this is an edge case, people that are paying attention to masonry layout won't have this often?<br> <ydaniv> fantasai: no will happen a lot<br> <ydaniv> astearns: can different tolerance for overflow be clipped?<br> <ydaniv> fantasai: no don't think it will cause clipping<br> <ydaniv> TabAtkins: [giving example]<br> <ydaniv> astearns: my point is if this can cause overflow, like an 1em, can we prioritize defaults that will not overflow?<br> <ydaniv> fantasai: I think TabAtkins' example is reasnoable, while having a randomized layout, expect that you'll be checking tolerance, you can't expect that everything will fit<br> <ydaniv> ... if it's not randomized you'll fix it<br> <ydaniv> astearns: disagree that on different screesn people will notice<br> <astearns> ack astearns<br> <ydaniv> fantasai: where layout varies with non-fixed sizes, you're wont be able to foresee the layout<br> <astearns> ack oriol<br> <ydaniv> ... the only case where it will fit perfectly is where you control everything<br> <fantasai> What I was saying is that, if we take a social media poll, it would need examples and illustrations -- it can't just be a theoretical question because it won't be understandable<br> <ydaniv> oriol: on that topic, all JS libraries default to 0, but authors asked to opt into behavior of infinite, as for a value that's small and positive<br> <ydaniv> ... lot's of authors asking for this<br> <ydaniv> fantasai: I think most libs are inifinite scroll layout, and at that point it's randomized, and doesn't matter much<br> <ydaniv> ... but one of concerns is a11y that it jumps around<br> <ydaniv> ... this reduces the amount of jumpiness, that's why with think it's important<br> <ydaniv> astearns: so oriol won't obejct, and neither will I<br> <ydaniv> astearns: shall we have a poll?<br> <astearns> 0<br> <ydaniv> astearns: so 0 for initial value of 0 and 1 for initial value of 1em<br> <oriol> 0<br> <fantasai> POLL: 0 for 0px 1 for 1em<br> <fantasai> 1<br> <kizu> 1<br> <TabAtkins> straw poll: put 0 in chat for an initial value of 0, 1 for an initial value of 1em<br> <alisonmaher> 1<br> <castastrophe> 1<br> <kbabbitt> 1<br> <romain> 0<br> <ydaniv> abstain<br> <ydaniv> astearns: other opinions?<br> <JoshT> abstain<br> <hoch> abstain<br> <TabAtkins> 1<br> <miriam> (I would love to see the examples that authors would need to see to make a good call)<br> <ydaniv> astearns: romain are you not objecting to 1em?<br> <ydaniv> romain: exactly<br> <ydaniv> astearns: suggest we resolve on 1em, and others can comment later if otherwise<br> <ydaniv> PROPOSED RESOLUTION: close no change<br> <ydaniv> astearns: any objections?<br> <ydaniv> RESOLVED: close no change<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10882#issuecomment-3356983086 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 1 October 2025 15:31:37 UTC