- From: Kokomi via GitHub <sysbot+gh@w3.org>
- Date: Sun, 22 Sep 2024 17:24:59 +0000
- To: public-css-archive@w3.org
@rjgotten, thank you for your detailed response. I'd like to further clarify my position and respond to some of the points you raised. --- ### Fallback Strategy While it's true that using a JavaScript library might affect performance and download size, sites that rely heavily on a masonry layout (e.g., Pinterest or Tumblr) place a high value on visual consistency. For these sites, switching to an entirely different layout could significantly compromise the user experience. In such cases, using a lightweight JavaScript solution like Masonry.js as a fallback allows for maintaining visual consistency while minimizing performance and size concerns, ensuring a similar user experience across browsers. Additionally, while it's possible to use `@supports` to fallback to a different layout, this isn't always practical. For content where visual consistency is crucial, managing multiple fallback layouts increases the burden on developers and complicates maintenance. As a result, JavaScript-based fallbacks can often be a more pragmatic solution for both development and maintenance. --- ### The Benefits of Integrating Masonry into Grid From what I've observed, creating a typical masonry layout using Grid syntax does not seem to introduce any noticeable complexity. Using Grid as a foundation for masonry layouts feels intuitive and straightforward, especially for developers already familiar with Grid's existing features. One possible area of concern might be the `grid-template-areas` property, which may seem less applicable to a masonry layout due to its auto-placement nature. However, since masonry primarily focuses on automatic item placement, I believe this property would not be frequently used in such scenarios. Additionally, the evolution of Masonry.js has largely stayed within the bounds of what can be accomplished using the current Grid system, suggesting that independent development of Masonry layouts may not be necessary. This reinforces the argument that masonry should evolve as part of the broader Grid system rather than as a standalone feature. --- ### Improving Developer Experience Using Grid syntax to implement masonry feels natural for developers who are already familiar with Grid. This reduces the need to learn new concepts and allows developers to apply existing knowledge effectively. An important point to consider is that Firefox Nightly and Safari Technology Preview already support masonry layouts within the Grid system, and we haven't seen any major complaints from developers about this implementation. This lack of negative feedback suggests that the developer experience when using masonry within Grid is already quite positive and intuitive. If there are specific examples where integrating Masonry into Grid could confuse developers, I'd appreciate it if you could share them. So far, I haven’t come across any such issues. --- ### Lack of Independent Evolution in Masonry.js and Its Relationship with Grid Masonry.js has been around for a long time, and while it has evolved, it has primarily done so within the constraints of what can be achieved using the existing Grid system. This suggests that there hasn't been a strong need for Masonry to evolve independently outside the scope of Grid. Most of the features needed for masonry layouts can already be handled by Grid, further supporting the argument that Masonry doesn't require independent evolution and should be part of the Grid system's future development. ## Conclusion Integrating Masonry into Grid would reduce the learning curve for developers by allowing them to reuse existing properties, minimizing the burden of adopting new concepts. Additionally, the fact that Masonry.js has not evolved beyond what the current Grid system can achieve indicates that independent evolution isn't necessary. If those who support `display: masonry;` believe there are specific reasons or properties that justify the independent evolution of Masonry, I’d be keen to hear them. -- GitHub Notification of comment by cat394 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9041#issuecomment-2366882505 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 22 September 2024 17:25:00 UTC