Re: [csswg-drafts] [css-contain-3] Revisit decision to make `style` the default `container-type` (#7066)

Sorry for another long comment, but I feel like there are again several issues getting confused in the thread - and I'd like to provide some context for how they pull apart, and how they relate. (along with the resolution that I would like to see here)

> The idea would only work if we made size containers the default.

Even different size containers rely on different containment (1d or 2d), so there's still no obvious 'default' that we could apply, even with size-alone. There's no way to remove container-type without severely limiting the feature.

> Just to summarize how container queries should work as proposed…

All queries use the same logic: querying the nearest ancestor container that is able to reflect the requested features, optionally with a given name. 

In most cases, for both size and style, it would be ideal to query the direct parent by default - because the baseline purpose of container queries is to have the most immediate information available. 

That's not viable with size queries, because they require invasive containment in order to 'reflect the requested features' – so authors need to carefully select where that containment is applied. With style queries, any element would be 'able to reflect' the query without any intervention, because no containment is required. The same seems likely for the potential 'state' queries that have been discussed so far.

In cases where authors don't just want the nearest ancestor, but want a specific container, they can use a container-name to look farther up the tree. That will be useful across all query types, and is especially a good idea when querying non-inherited properties.

All of this has lead to several distinct questions that are getting mixed together in this thread:

## Are style queries even useful?

I'm confident that they solve a problem that has been raised in various places, and I will continue to make the case for them. But either way, my syntax proposal for what to launch now is the same (see below).

## Should every element be a 'style container' by default, since no containment is needed?

We initially said 'yes', because this entire feature is designed around authors getting the most immediate available information by default. For usability of the feature, this is the right way to go. Container-name is a better solution than container-type for filtering the list of containers when necessary from an author perspective. It is also likely to make sense down the road for other hypothetical query-types that don't rely on specialized containment, since it seems like the ancestor-descendant requirement is enough to protect most query-types from looping.

### Are there performance issues that should make us reconsider that?

The answer depends on both the implementation approach, and the way authors write their queries. Those potential performance issues only apply to the resolution of style queries, they are not a general performance penalty for all sites across the board.

Container queries involve two levels of element 'filtering' - one to find the 'containers' elements that will be queried, and the other to find the selector 'target' elements impacted by the query. Currently, the Gecko and Chromium implementations filter selector targets first, and then use that information to narrow the search for viable containers (which must be an ancestor of the target). The Webkit implementation takes the reverse approach - first filtering viable containers, and then selector-matching only within their descendant trees. As with the internals of selector-matching, the more narrowly targeted the first step, the better the performance. If selector-matching narrows the list farther, then it ought to go first, and vice-versa.

If all elements are style containers (either by default, or through a global declaration), then a style query without a container-name is very broadly targeting all elements as potential containers. That will impact the performance of all container-first filtering algorithms. The first step has basically no filtering impact. For selector-first algorithm, the impact is relative to the specificity of selectors involved. In either case, it is possible for authors to cause performance issues through a combination of broad selectors inside broadly-targeted queries. The concern is that having more containers on the page makes more queries 'broadly-answerable'.

Since authors are likely to apply this global rule if we don't, it seems essential that we optimize for it, no matter how we conclude this issue. It's also possible that selector-first filtering will have some advantages here. In the meantime, authors can avoid those performance concerns by using container-names to narrow the container list, or keep selectors more narrowly targeted to avoid broadly-applied queries.

However, it's still not clear to me _how much_ of a performance slow-down we're talking about. While the `*` selector is less performant than an `#id`, that hasn't been enough of a difference to impact most developers choice of selectors.

## Can we help authors avoid some container declarations overriding others?

With both container-types and container-names, it's likely that authors will want to apply different values in different places – and ideally would be able to merge those declarations, rather than one overriding another. That's an issue that has come up with many other CSS properties, and is the driving concern behind the idea of 'additive cascade'. 

In this case, we could consider breaking out individual longhand properties for different categories of container-type (size, style, etc) which would allow those types to be set in parallel. But: 

- That doesn't help with conflicts inside a given category (size vs inline-size)
- It only works if authors entirely avoid the shorthand, which would reset all longhand values anyway
- The conflict is even more likely with container-names, which cannot be broken into shorthands

I don't think the benefits here are worth the effort. I would rather see us work on a general solution to the problem of additive cascade.

## My proposal

These are all good concerns to raise, and I'm glad to be walking through them in some detail. I find it very hard to weigh the performance concerns in relation to author usability - since it involves a number of factors that change over time. Clearly, implementors have a better sense of that than I do. But at this point I still feel that we had the right proposal here initially.

I would like to resolve that:

- The initial value of `container-type` is `none`.
- All elements are `style` containers, no matter what `container-type` value is applied.
- Browsers should feel free to ship size queries as they are implemented, and ship style queries later.

In the meantime, I'll work on providing more detailed use-cases for style queries, so that the reason for implementing that feature is clear. Even if I fail at that, this resolution on the initial value of container-type allows us to ship the best syntax for size queries now. And if anyone wants to work on a proposal for additive cascade, I would love to help push that forward. 

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


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

Received on Thursday, 16 June 2022 22:14:37 UTC