Re: [csswg-drafts] [css-conditional] [css-contain] Fleshing out @container queries with single-axis containment (#5796)

I've been thinking about this proposal a lot since I came across it, and I just want to mention something.

When you're querying the viewport with `@media`, there's essentially a single "object" being queries. While I totally get the argument that with this `@container` syntax, a selector is not needed, I believe consideration should be given to the fact that _omitting_ a selector, even a star selector, (IMO) makes this conceptually harder to understand for new CSS authors. "What am I querying?" "Well it's the available container dimensions anywhere." " 🤔  "

If you're intimately familiar with CSS and browser layout mechanisms, it's not hard to grok a container query without a selector. But for new authors, I feel like the ability to query a selector should at least be _optional_, if not recommended.

e.g.
```css
@container * (width > 45em) {
  .media-object {
    grid-template: "img content" auto / auto 1fr;
  }
}
```
To me, this is an easier mental model, and there's good reason it's been included in almost every container query proposal. It ties into the mental model for CSS authors the "what" of what I'm querying, followed by the query, and IMO is the most analogous to a `@media` query, in which the "what" is clearly established, not explicitly in the syntax, but implicitly by the nature of the query.

I wouldn't consider this a feature blocker, of course, because I'm so jazzed that this proposal has legs, and honored to have been mentioned, and for me personally, I won't struggle with the mental model. But the more I think about it, the more I worry that the omission of a selector as even an option makes this hard for new devs, because the "what" takes a lot of concept knowledge. Couple that with needing to understand the `contain` property, and it's a lot to grok.

As to these points arguing against the inclusion of a selector from Dave Baron's proposal:

> Explicitly targeted queries are less modular, so components would not be able to query whatever contasiner they happen to be in.

That may be exactly what the author desires! An author may want to write queries which only apply in specific contexts (and change in others.) And to make them ultra-modular, one would target a `*` selector, which is easy for new authors to understand, because it ties into the basics of CSS.

> It adds potential confusion about what selectors are allowed in the block. 

To me, the inverse is true. A selector, even a star selector, makes the context of the query clear. Omitting a selector in the query muddies the "what", leading to more possible developer confusion. For advanced authors, the option to omit a selector makes a certain sense; you (usually) want this to apply regardless of context. But even for advanced authors, I can see myself wanting to apply a query only within certain contexts, and it makes the feature much more powerful as a result.

There are a lot of very talented people / CSS experts who've weighed into this proposal. My suggestion is just to consider the non-expert. Will they understand the context? What syntax is most intuitive? Have they been asked? I can imagine a person teaching this CSS concept to someone new and saying something like, "Imagine there's a star selector in this query, even though it's not present." That lesson would be made easier if the selector was _actually_ present.

Okay, that's enough of my $0.02. Thanks so much for moving this along!

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


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

Received on Friday, 12 February 2021 11:39:10 UTC