- From: theAdhocracy via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Apr 2024 13:05:27 +0000
- To: public-css-archive@w3.org
Another vote for keeping it as part of CSS Grid. Alongside the ability to use subgrid, column spans, and other existing features, as others have noted, making masonry a new feature for Grid allows for easier progressive enhancement and adoption. You could build a regular grid, then enhance to be masonry for those browsers that support it, in a lot of scenarios where this functionality would be used. I'm also someone who has been hoping for native masonry layouts for some time; many of the reasons given above overlap with my own experience. However, I think it is worth flagging the accessibility concerns that such a fluid layout algorithm can have. What considerations are being included in the spec for dealing with the disconnect between visual layout order and DOM order? Or for handling focus order correctly? As the nature of masonry is very hands-off from a developer's perspective – we're letting the browser decide placement, after all – it won't be easy (or even impossible) to retroactively patch this behaviour for assistive technologies. I'm aware that there are discussions elsewhere within the CSS community (and Working Group) around making better, more robust accessibility APIs for functionality like Grid, but masonry seems to come with these concerns baked in and unavoidable, so it would be good to see a concerted effort to ensure that they are covered before masonry sees wide usage or implementation. -- GitHub Notification of comment by theAdhocracy Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10233#issuecomment-2074903714 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 24 April 2024 13:05:28 UTC