Re: [csswg-drafts] [css-contain] Should there be a new syntax for establishing queryable containers? (#6174)

I'm sure we'll bikeshed the details, but here's my initial attempt at a new `container` property:

```css
main {
  container: inline-size;
}
```

This property would:
- Explicitly establish the element as a container
- Establish the types of queries allowed on the container (e.g. `inline-size`)
- Apply the minimum required containment to make those queries possible (e.g. `layout`, `inline-size`, and `style`) without changing the computed value of `contain`

There are several query/container "types" that we could consider values for:

- dimensional: `size`, `inline-size` (or just `inline`?), `block-size` (or just `block`?)
- computed values on normal/custom properties: `style`
- interaction states: `stuck`, `in-view`, etc…

At this point we've mostly focused on dimensional queries, but the others are discussed in #5989. What's most essential here is that the property could be extended as we add new query features. Multiple values could be supplied, and browsers would be expected to determine what containment is required for the given values:

```css
main {
  container: size style state;
}
```

## Bring back named containers?

I think this syntax would also open up a path to bring back named-containers -- similar to the selector argument in David Baron's initial proposal, but more flexible & customizable in the CSS. While I don't think this is needed for most dimensional queries (we almost always want the most immediate dimensions), it becomes more essential when you consider mixing different query types.

In that case, `container` could become a shorthand property (specific syntax TBD):

```css
main {
  /* container: [ [<custom-ident> /]? <types>+ ] | none; */
  container: layout-area / inline-size style;
}
```

With two longhand variants:

```css
main {
  /* container-type: <types>+ | none; */
  container-type: inline-size style;

  /* container-name: <custom-ident> | none; */
  container-name:  layout-area;
}
```

And then queries could include an optional name, before establishing conditions:

```css
/* @container <custom-ident>? <container-query-list> { <stylesheet> } */
@container layout-area (inline-size >= 30em) { /* … */ }
```

This would resolve in two steps:
- Find the appropriate container...
  - if no name is specified, use the _nearest ancestor container_
  - otherwise, filter to the list of ancestor containers _with a matching name_ before selecting the nearest ancestor
- Resolve the query conditions against the selected container

## Considerations

While there might be some downside to triggering `contain` behavior from outside the `contain` property, I believe there is already significant precedent for that. On the other hand, attempting to shoe-horn the entire future of Container Queries into the existing `contain` property would be limiting, and potentially confusing:

- We might want container values that do not generate any containment behavior
- There has been significant concern about accidentally creating containers, when you only want to set containment
- The syntax would get quite cluttered to support both

## Next steps

I think there are several questions to answer here:

- Do we want to add a new property for this purpose?
- Are we happy with `container` as a working name for the new property?
- Are we interested in pursuing named containers?
- meta: does this all belong in the css-contain spec? Or does some of it belong with css-conditional? Or somewhere else?

(I would save the specific values and other syntax details for separate issues, if we decide to go down this general path)

-- 
GitHub Notification of comment by mirisuzanne
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6174#issuecomment-846313720 using your GitHub account


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

Received on Friday, 21 May 2021 23:55:42 UTC