- From: Alan Stearns via GitHub <sysbot+gh@w3.org>
- Date: Mon, 29 Apr 2024 18:39:06 +0000
- To: public-css-archive@w3.org
(chair hat off still, this is just me trying to make sense of the options) Assumptions and caveats: - We can avoid performance pitfalls in both scenarios. That is a bit handwavy but we do have the tools to restrict what combinations of values have what effects. - We can add all the masonry properties we need to get appropriate grid functionality - I am only thinking of author use, not about implementation complexity. **Masonry + Grid together** Pros: - No duplicate properties for similar sorts of things - You can reuse most of what you know about Grid in Masonry Cons: - More complicated value spaces (some apply only to one mode) - New properties must be designed to accommodate both modes **Masonry as a separate display type** Pros: - Less complicated values (each mode has only what it can use) - New properties are less complicated to add Cons: - Duplicate (or very similar) properties need to be added - New properties can add to the duplication By “new properties” I mean things that aren’t yet in Grid or proposed for Masonry. If the new thing works identically in both modes then the property duplication for the separate display types is annoying. But it’s also not great if a new single property has to have a mode switch designed into it. From a “designing future extensions to grid/masonry” standpoint I think I am favoring a separate display type. -- GitHub Notification of comment by astearns Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9041#issuecomment-2083405465 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 29 April 2024 18:39:07 UTC