Re: [csswg-drafts] Alternative masonry path forward (#9041)

The CSS Working Group just discussed `Alternative masonry path forward`.

<details><summary>The full IRC log of that discussion</summary>
&lt;khush> rachelandrew summarize the feedback. we've got 2 versions in terms of feature parity they are the same<br>
&lt;khush> the syntax is different<br>
&lt;khush> taken it to 2 devs<br>
&lt;khush> after the initial post from webkit, we got feedback<br>
&lt;khush> there's no way that devs will get all features showed in the post if we go with separate syntax<br>
&lt;khush> went through all the comments and looked at how many of them said display:grid because that's the only way to get features<br>
&lt;fantasai> I think that's not quite correct, just that the state of the opposite proposal was to intentionally exclude some of the grid-integrated features.<br>
&lt;fantasai> at the time of that post<br>
&lt;khush> other feeedback is, is masonry grid or not.<br>
&lt;khush> as a teacher of CSS it matters how people think<br>
&lt;khush> there is noo consensus there<br>
&lt;khush> the other response, which approach is easier to teach and understand<br>
&lt;khush> that's the core issue, what is easier for devs to understand<br>
&lt;khush> that post is really hard to write<br>
&lt;khush> because it's complicated. display masonry has much simpler syntax. display grid requires changing other values<br>
&lt;khush> it's just hard. i'll have a hard time explaining it to people<br>
&lt;khush> the response to the second post has supported masonry<br>
&lt;khush> me and chrome team prefer display: masonry for ergonomics<br>
&lt;khush> the other point is future proofing<br>
&lt;khush> there are enough things in display grid which are weird<br>
&lt;khush> we will have to work around by saying they only work in masonry<br>
&lt;oriol> +1 to display:masonry<br>
&lt;astearns> ack fantasai<br>
&lt;khush> fantasai: i intentionally did not add it to the agenda. too early for this debate<br>
&lt;khush> underlying layout model is the same<br>
&lt;TabAtkins> q+<br>
&lt;khush> only syntax is up for debate<br>
&lt;khush> we only published it end of last week<br>
&lt;TabAtkins> (it's not just a syntax issue, there is still some behavior differences)<br>
&lt;khush> chrome madde the blog post last thursday<br>
&lt;TabAtkins> (and they're unresolvable imo)<br>
&lt;khush> we should continue to work on issues<br>
&lt;khush> impl is not blocked<br>
&lt;khush> i want to collect author feedback and think through the syntax<br>
&lt;khush> get input from TAG<br>
&lt;khush> too soon to start debating syntax<br>
&lt;khush> Won't go into my opinion on the syntax<br>
&lt;khush> the state of the draft which outlines the 2 syntax and have same functionality<br>
&lt;khush> there's pros/cons to each syntax. one is definitely not better<br>
&lt;khush> has to come from the context where the syntax is being used and rest of CSS<br>
&lt;khush> let's not argue it here right now<br>
&lt;astearns> ack TabAtkins<br>
&lt;khush> TabAtkins: the difference between integration into grid vs masonry is not just syntax.<br>
&lt;khush> diff initial values for properties<br>
&lt;khush> display: masonry gets you better values right away<br>
&lt;khush> masonry can do auto repeat of instrinsic size tracks<br>
&lt;khush> that is not even possible with grid<br>
&lt;khush> fantasai: those are separate issues<br>
&lt;khush> TabAtkins : it's incorrect to say it's only syntax. behaviour is different<br>
&lt;khush> i'm fine with deferring<br>
&lt;khush> TabAtkins: it's pretty clear that a bunch of common cases are indeed simpler with the display: masonry syntax.<br>
&lt;khush> want to see similar examples with grid.<br>
&lt;rachelandrew> Chrome post https://developer.chrome.com/blog/masonry-syntax<br>
&lt;khush> let's have those examples when this discussion happens<br>
&lt;keithamus> q+<br>
&lt;khush> keithamus: display: masonry is a inside display: grid<br>
&lt;khush> i can't see any examples for inline masonry<br>
&lt;khush> TabAtkins assume inline-masonry exists.<br>
&lt;khush> astearns please file an issue for this<br>
&lt;khush> fantasai: one argument for grid syntax is we don't have props which only apply to specific context<br>
&lt;khush> it's better to go with more examples/input before debating<br>
&lt;TabAtkins> I think we actually don't have *any* such properties here. Every property is *at least slightly* different in its syntax.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9041#issuecomment-2378188639 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:42:25 UTC