[csswg-drafts] [css-grid-N] Flowing grid items together (#9098)

tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-grid-N] Flowing grid items together ==
**Problem:** There are several situations where authors want to use a particular DOM structure for semantic reasons, but want to rearrange the elements on layout. Grid (and other layout methods) can do this to some extent, but when the rearrangement would involve wrapping a container around some of the elements, it's impossible. This proposal aims to solve a limited subset of these use-cases, that should be sufficiently useful, widely implementable, and have minimal (ideally, none) accessibility implications.

**Examples:**
* DOM structure of `<h2>...</h2><section>...</section><h2>...</h2><section>...</section>`, but author wants to display it as tabs, with the `h2`s collected together into a flexbox and only one section showing at a time.
* Author uses a Grid for whole-page layout, and to allow changing the layout significantly between desktop and mobile. On desktop, they have two independent sidebars that they put some of the elements in (a nav, a footer, an aside...), and each sidebar should flow naturally regardless of the sizes of the elements. Using several grid areas for each sidebar, one per element, accidentally establishes relationships between the sizes of the elements across the sidebars, tho.

**Complications to Avoid:**
* Significantly changing the layout tree can have significant a11y implications; see the continuing troubles with `display: contents` and its ability to remove an a11y-significant parent from the tree. If possible, we should avoid changing the layout tree in major ways; ideally don't reparent anything, just rearrange.
* Large-scale layout-tree reorganization is non-trivial (maybe impossible, depending on browser). Currently CSS is limited to fairly trivial reorderings like popover and other top-layer effects, or `display: contents` which is a local transform.

**Proposal:**
* Add a new `grid-flow: <<dashed-ident>> <<integer>>?` property, valid on in-flow grid items. It indicates that the grid item will be reparented in a group with other grid items using the same ident. (They are sorted by integer, then by DOM order, identical to how auto-flow works with the 'order' property.)
* Add a new pseudo-element to grid containers, `::grid-flow(<<dashed-ident>>)`. Each distinct ident refers to a separate pseudo-element. It's an anonymous block, treated as a grid item of the container, that holds all the reflowed grid items with the matching ident. It's tree-abiding and can take all properties, so you can position it in the grid, set background/border, set overflow, make it a flexbox, etc.

**Details:**
* As this just reparents grid items to a new, pseudo-element grid item of the same container, the a11y structure is still essentially the same, just in a different order. The layout-tree movement is fairly local, so it should be doable without too much rearchitecting by other browsers.
* We might want to limit what values the ::grid-flow() pseudo can take in some cases, to avoid accidentally causing a11y implications. Ideally the ::grid-flow() pseudo is "transparent" for a11y purposes, so for practical purposes the reflowed items can still be treated as children of the grid container. For example, disallow `display: list-item`, as list items are reflected specially in the a11y tree. (TODO: figure out what the full set of a11y-significant properties/values are and decide how much we want to restrict things.)

**Additional Notes:**
* We want to allow `::grid-flow()` to exist even if nothing is flowed into it, for stable layouts - an area might have items in it only conditionally, but you still want to display the (empty) area itself. This solves the ["decorative grid pseudo-elements" issue](https://github.com/w3c/csswg-drafts/issues/499#issuecomment-248051233) as well, which will make people happy.

Questions:
* Is this satisfactory from an a11y standpoint? We want to verify this early to avoid another `display:contents` debacle.
* This proposal is intentionally limited, but is it still powerful enough to be worthwhile?

Examples using this proposal:

```
.tab-container {
  display: grid;
  grid-template: "tabs" "cards";
}
.tab-container::grid-flow(--tabs) {
  display: flexbox;
  grid-area: tabs;
}
.tab-container > h2 {
  grid-flow: --tabs;
}
.tab-container > section {
  grid-area: cards;
  &:not(.active) {
    visibility: hidden;
    order: -1;
  }
}
```

```
@media (width < 800px) {
  body {
    display: flexbox;
    /* just lay out the page vertically */
    ...
  }
}
@media (width >= 800px) {
  body {
    display: grid;
    grid-template: "header header header"
                   "side   main   ads"
                   "side   footer footer";
  }
  body > main { grid-area: main; }
  body > header { grid-area: header; }
  body > footer { grid-area: footer; }
  body > nav, body > aside { grid-flow: --side; }
  body > .ad-spot { grid-flow: --ads; }
  body::grid-flow(--side) {
    grid-area: side;
  }
  body::grid-flow(--ads) {
    grid-area: ads;
  }
}
```

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9098 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 20 July 2023 20:38:46 UTC