- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 27 Sep 2024 00:55:30 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-grid-3] The initial value of `masonry-slack` should be 0``. <details><summary>The full IRC log of that discussion</summary> <khush> oriol: it would be better to summarize the prop. another issue for naming it<br> <khush> with masonry we place the item into a track that is less filled.<br> <khush> with this prop you can provide a threshold so instead of doing it strictly order is preserved<br> <khush> current spec tentative initial value is 1m<br> <khush> i think it should be set to 0<br> <kbabbitt> s/1m/1em/<br> <khush> was investigating js frameworks which provide this<br> <khush> all of them have the strict value<br> <khush> they offer 2 possibilties: masonry-slack: 0 or infinite<br> <astearns> ack keithamus<br> <khush> when you set it to a positive value, no framework supports it<br> <khush> authors don't expect or ask for it<br> <khush> maybe it can be beneficial. exact value which will work well is highly dependent on the use-case<br> <khush> so just supporting 1em is confusing<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to point out they don't have a concept of masonry-slack<br> <khush> align with frameworks and set initial value to 0<br> <TabAtkins> +1 to fantasai's point<br> <khush> fantasai: the reason why frameworks don't have non-0 initial value since there is nothing other than infinity<br> <khush> this is a concept frameworks don't have<br> <khush> allows placements to occur in a more natural way for the user<br> <khush> slight diff of a few pixels jumping to a diff track breaks accessibility and sequencing order also<br> <khush> it would be better to have a non 0 initial value<br> <khush> 1em is used for gap<br> <khush> significantly more than 1px but less enoug<br> <khush> almost no use-case for anything less than this<br> <astearns> q+<br> <khush> oriol: i don't get the accessibility problem. reorder happens anyway in other cases<br> <khush> fantasai: when you start mixing span values, you have this problem. span: 1 doesn't cause jumping backwards.<br> <khush> the most common case won't have this jumping around<br> <khush> as long as your slack is big enough yoy're always moving fwd<br> <khush> masonry-slack being too small makes it not obvious why the movement happened<br> <khush> noticeable difference between 2 columns for you to go higher. user won't understand why we moved unless the slack is high<br> <khush> astearns: i don't understand the argument that an em's worth of slack is more natural when none of the current libs give you that facility<br> <khush> fantasai: they just didn't think of it<br> <khush> astearns: it's been long enough. why no feature request?<br> <khush> fantasai: we might be able to do better than the js framework though<br> <khush> astearns: 1em is currently spec'd?<br> <khush> fantasai: yea<br> <khush> TabAtkins: +1 to fantasai<br> <khush> oriol: this would align with col-gap. it's initial value is normal.<br> <khush> should we do something more along the lines?<br> <khush> not 0 but normal keyword<br> <khush> oriol: there may be different cases where the value changes due to other things and changing the initial value would be harder<br> <khush> so yes<br> <khush> fantasai: sounds good to me<br> <khush> oriol: i still believe defaulting to a positive value will trigger confusion<br> <khush> fantasai: happily surprised?<br> <khush> astearns: any implementations?<br> <khush> fantasai: not yet<br> <fantasai> s/happily surprised/surprised and delighted/<br> <dholbert> I have a concern that 1em as a magic value might produce unexpected layouts, if a user has a different font-size in their UA stylesheet etc<br> <dholbert> 1em as a threshold of "a distance that a user may notice" is a bit fiddly<br> <dholbert> which means I think I agree with a "normal" value, but I'm not sure how it should be defined. :)<br> <fantasai> dholbert, it's not 1rem, it's 1em :)<br> <khush> astearns: we don't have a basis to decide this issue. let's implement and get feedback from authors. revisit once we have that data<br> <fantasai> so it will always scale with the font the author chose<br> <kbabbitt> +1 astearns<br> <miriam> I would consider 1lh…<br> <khush> fantasai: let's resolve on what we have<br> <dholbert> fantasai: if a user sets a minimum font-size in their browser, I thought that still impacts 1em sizing? need to confirm<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-2378200125 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 27 September 2024 00:55:30 UTC