Re: [w3ctag/design-reviews] CSS Masonry Layout (Issue #1003)

@nt1m [Trying to channel the rest of the TAG, but I haven't checked this with them, so it could be wrong.] There are two ideas here:
1. The Webkit blog that we linked to in that point argues that "it’s an easy transition to go from thinking about CSS Grid to thinking about packed masonry-style layouts". That seems like an argument that you don't have to change the code much when you have a grid layout and want to adopt masonry, or that it's easy for people who already know grid to start using masonry. That doesn't seem like a great argument, since most future code will be written directly into either grid or masonry, and by people who had the option of learning either grid or masonry first.
2. The point you're making in this comment, that it's good for code to gracefully degrade in browsers that don't support masonry. All things equal, code absolutely should degrade gracefully. But if other things aren't equal, it's probably better to prioritize some of the other considerations like (for example) learnability and the coherence of the whole space of properties. Graceful degradation would be more important if `@supports` didn't exist, if there were going to be a years-long gap between the different engines shipping this, or if pages written to use this in evergreen browsers are likely to be completely unusable in older browsers, but I didn't find an argument that that's the case for either masonry syntax.

Keep in mind that this review isn't guaranteed to be correct: it's just the TAG's opinion with maybe a wider view but less context and study than the CSSWG.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1003#issuecomment-2491973729
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1003/2491973729@github.com>