- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 09 Feb 2022 17:52:50 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `CSS Container Queries Level 3`, and agreed to the following:
* `RESOLVED: when we select a container, we determine which container by looking at the actual queries and finding an appropriate container for the questions being asked`
* `RESOLVED: remove the container-type syntax from the preamble of the @container rule`
* `RESOLVED: All queries in an @container rule are against the same container, which can answer them all`
* `RESOLVED: defer style containers to L4`
<details><summary>The full IRC log of that discussion</summary>
<fantasai> Topic: CSS Container Queries Level 3<br>
<fantasai> miriam: All three of these issues are around how we handle container selection<br>
<fantasai> miriam: which is, in a container query, we have to find a container to ask the questions<br>
<astearns> github: https://github.com/w3c/csswg-drafts/issues/6644#issuecomment-1033245188<br>
<fantasai> miriam: and once we've selected a container can query against it<br>
<fantasai> miriam: these are all issues around how we find that container<br>
<fantasai> miriam: 3 issues being discussed, I think it all ties together in the first one, so will start there<br>
<fantasai> miriam: Current logic is any element with container-type is a container<br>
<fantasai> miriam: and always look to nearest container for querying<br>
<fantasai> miriam: so quite easily to get false negatives if you ask a query that that container type doesn't support<br>
<fantasai> miriam: so looking at how to avoid that<br>
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/6644<br>
<fantasai> miriam: Proposal here is to look at the different conditions being asked<br>
<fantasai> miriam: is it asking for inline-size, block-size, style<br>
<fantasai> miriam: instead of looking for nearest container, can look for nearest container of a type that can answer all the queries<br>
<fantasai> miriam: This ties into earlier decision that all elements are style containers<br>
<fantasai> miriam: if all are style containers, then nearest container is always the parent, so this exacerbates the problem<br>
<fantasai> miriam: most queries will want to look higher in the chain than the parent<br>
<fantasai> miriam: even if we reverted that, though, we still have this issue<br>
<fantasai> miriam: fragile to assume that no container will be inserted between you and what you're trying to query<br>
<fantasai> miriam: so I think we want to solve this issue regardless<br>
<fantasai> miriam: Una wanted to return to that decision<br>
<fantasai> miriam: could potentially punt on having style issues<br>
<fantasai> miriam: third issue is, if looking for inline-size container and style query looking for style container<br>
<fantasai> miriam: can nest those<br>
<fantasai> miriam: and then each query looks for its own container<br>
<fantasai> miriam: could also combine multiple queries in a single @container rule<br>
<fantasai> miriam: in this case, are we querying a single container or multiple containers (per query)?<br>
<fantasai> miriam: proposal is in the issue [LINK PLEASE!!!]<br>
<fantasai> miriam: and then Jen Simmons was asking about deferring style queries entirely<br>
<fantasai> miriam: so that's the overall summary<br>
<astearns> the links are all in the comment at the top of this minuting section, and the topic in the channel<br>
<chrishtr> q+<br>
<fantasai> chrishtr: What is the implementation complexity and runtime implication of these changes?<br>
<miriam> Issues are 6644, 6393, 6876, and 7020 to defer<br>
<fantasai> miriam: I haven't gotten any pushback form engineers I've talked to<br>
<fantasai> chrishtr: Anders and Rune think it's doable?<br>
<una> q+<br>
<astearns> ack una<br>
<astearns> q+ una<br>
<astearns> ack chrishtr<br>
<fantasai> fantasai: Can't imagine there's any runtime complexity, just deriving type from query, not looking at the document tree at all, and then back to where you were when we had to have an explicit type<br>
<fantasai> astearns: I assume spec would need to be clear how the queries select for container types?<br>
<fantasai> astearns: but that seems simple enough to me<br>
<astearns> ack una<br>
<fantasai> una: I want to add that it seems doable, you'd still have to specify a container type whether explicitly or whether stating in container query<br>
<fantasai> una: I like the idea of determining type based on the query, only writing in one place<br>
<fantasai> una: I still dislike everything being a style query by default<br>
<fantasai> una: In order to have 6644, we'd have to revert 6393<br>
<fantasai> miriam: I don't understand why we would have to revert<br>
<fantasai> una: wouldn't having everything be a style container interfere?<br>
<fantasai> miriam, fantasai: no<br>
<fantasai> fantasai: Not making every query a style query, making every container a style query container<br>
<fantasai> astearns: still means your style query looks up to a parent every time<br>
<fantasai> miriam: yes, but I don't think that's a problem<br>
<astearns> s/a parent/the immediate parent/<br>
<fantasai> miriam: In my mind, we should be encouraging authors that if they are relying on something that might move, might have a new container in between, need to use a name<br>
<jensimmons> q?<br>
<fantasai> miriam: If you're looking for background-color ancestor, need to use name to filter the ancestors, shouldn't rely on being nearest style query container because might insert another style query container in between for other purposes<br>
<fantasai> astearns: any other questions or comments about selecting the container based on query characteristics?<br>
<fantasai> jensimmons: I think it's a good idea to have sensible defaults so that the browser chooses containers instead of defaulting to something that doesn't work<br>
<fantasai> jensimmons: In chatting with our engineers, sounds like we don't have implementation concerns<br>
<fantasai> astearns: Shall we make this resolution and move on?<br>
<fantasai> +1<br>
<fantasai> astearns: Proposed that when we select a container, we determine which container by looking at the actual queries and finding an appropriate container for the questions being asked<br>
<fantasai> RESOLVED: when we select a container, we determine which container by looking at the actual queries and finding an appropriate container for the questions being asked<br>
<fantasai> miriam: Next, is there any reason to keep an explicit container type argument in the preamble?<br>
<fantasai> miriam: since we're already automatically determining it<br>
<fantasai> astearns: what else goes in preamble?<br>
<fantasai> miriam: name and type, would drop type but keep name and that simplifies the syntax<br>
<fantasai> +1<br>
<fantasai> una: I'd prefer to write explicitly, but if not majority opinion ...<br>
<fantasai> una: interested in hearing others<br>
<fantasai> una: I think default of style queries is unclear<br>
<emilio> +1<br>
<fantasai> una: would prefer each time you specify the query type<br>
<fantasai> una: I don't think this works in default case because of everything being a style query<br>
<fantasai> miriam: We're already looking for the right type of container<br>
<fantasai> miriam: so I'm saying we can remove that type from the preamble from the container rule, now that it's automated<br>
<fantasai> una: sounds good to me<br>
<fantasai> jensimmons: What's the preamble?<br>
<fantasai> miriam: @container starts with a preamble for selecting the right contianer<br>
<fantasai> miriam: right now allows choosing type of contianer and name of container, before the query<br>
<TabAtkins> The part between the at-keyword and the {} block.<br>
<TabAtkins> (I call this "prelude" in Syntax.)<br>
<fantasai> miriam: suggesting we drop the type keyword, since we can automatically determine that<br>
<TabAtkins> Ah no preamble is a subset if the prelude, I see<br>
<fantasai> astearns: No use case for wanting to query a more limited set of containers than the query needs?<br>
<fantasai> fantasai: Better in that case to use a named container<br>
<fantasai> astearns: Seems we could add it later if needed<br>
<fantasai> astearns: Anyone else with concerns about removing container type form the preamble?<br>
<fantasai> RESOLVED: remove the container-type syntax from the preamble of the @container rule<br>
<fantasai> miriam: This is where we could reconsider the style default, or delay implementation of style queries to L4 and bring it back later<br>
<fantasai> miriam: or we can discuss it now<br>
<fantasai> miriam: whether a default of style container is good to have on every element<br>
<TabAtkins> Yeah I'm quite happy with this latest resolution<br>
<fantasai> astearns: I'm concerned that we will constrain ourselves if we push this off<br>
<fantasai> fantasai: I think we should take it up, style queries are not that complicated<br>
<fantasai> fantasai: and I support Miriam's take on this issue<br>
<fantasai> astearns: That is?<br>
<fantasai> miriam: The default style query type is very useful for a lot of cases, particularly for inherited properties<br>
<fantasai> miriam: e.g. query the font-style style of the parent and flip it from italic to normal or vice versa<br>
<fantasai> miriam: would replace the toggle() feature that had been proposed<br>
<fantasai> miriam: It's helpful in many situations<br>
<fantasai> miriam: and for cases where you're looking at a non-inherited property, want to look for a specific container<br>
<fantasai> miriam: and in that case should be looking for a named query, not relying on the container type<br>
<fantasai> miriam: So my argument is it's a good default, it helps some cases though not all of them, and for cases where it doesn't should be using a name anyway and we should encourage that<br>
<fantasai> una: My thought on this is, it feels a bit brittle to me<br>
<fantasai> una: If you add an additional element between the container you're querying and the query, breaks your query<br>
<fantasai> una: You have to go up the tree for many things, so looking at the parent feels brittle to me<br>
<fantasai> astearns: I'm also leaning Una's way, since we made this other change to avoid the mistake of selecting the direct parent; odd to leave that in place<br>
<emeyer> scribenick: emeyer<br>
<miriam> q+<br>
<emeyer> fantasai: Two arguments. One, on the issue of being brittle and easy to break, yeah. If you were relying on a container type lookup, and some other type of query container gets in between, that will break. If we’re consistently looking at the parent, things become very predictable for authors. It becomes clear that naming is needed to break that nearest-container behavior.<br>
<emeyer> …The second thing is that there are a lot of cases where the ability to just look at your parent is useful. I suspect there will be a number of pages that want to set this on every element on the page just to get that ability. If they do that, then the entire tree has a non-default value and that’s not performant.<br>
<astearns> ack fantasai<br>
<jensimmons> q+<br>
<emeyer> …I think it’s going to be easier for authors to understand what they’re doing if we have the default be that every element is a style query container. That gets us default behavior of the parent being the initial thing to look at. We’ve had multiple request for features to look at the parent for something. This would deliver that very easily.<br>
<emeyer> …So I think we should do this. It will be a useful feature and cause less breakage rather than more.<br>
<fantasai> astearns: Yes, we have a lot of requests for a parent selector thing, but this is a container feature<br>
<fantasai> astearns: might be a source of confusion<br>
<astearns> ack miriam<br>
<fantasai> astearns: You mentioned can get into bad state by adding another explicit container to the hierarchy. If you add a container, queries will respond, different than just adding an element<br>
<fantasai> miriam: That gets into what I was going to add to what fantasai was saying<br>
<una> q+<br>
<fantasai> miriam: When you're dealing with inherited properties, and just want to check the parent, adding any element will break it.<br>
<fantasai> miriam: let's use <strong>, I want it to respond to whether parent is bold or not bold and do something based on that<br>
<fantasai> miriam: if parent changes to something no longer container, and changes whether we're in bold or not bold, then any element breaks that use case<br>
<fantasai> miriam: the inherited property use case is only useful if we assume we can get the right answer from the parent<br>
<fantasai> miriam: and I'm guessing we'll get a "best practice" where people set style containment on every element<br>
<astearns> ack jensimmons<br>
<fantasai> miriam: and as fantasai said, that will create a performance hit<br>
<fantasai> jensimmons: I feel from an author's perspective, the proposal that Miriam has put together is the best way to go<br>
<fantasai> jensimmons: I understand what Una is saying that in big projects, it doesn't give a lot of functionality. THey want to create components and style systems and have no idea what the DOM is going to be<br>
<fantasai> jensimmons: but I think that's true for a lot of CSS, where the simple way, the default of CSS doesn't hold up in big projects, and more powerful tools are needed<br>
<fantasai> jensimmons: and that's what container names are for<br>
<fantasai> jensimmons: But there really are many many projects that are not multimillion dollar projects<br>
<fantasai> jensimmons: and this simple querying that we're discussing, with the font-style: italic query example, it's so nice and expands what's possible<br>
<fantasai> jensimmons: I don't think we should break that because the big projects need something else<br>
<astearns> ack una<br>
<fantasai> jensimmons: Philosophy in CSS should be to give simple defaults that work for the small projects, and give more powerful tools for the big projects<br>
<fantasai> una: I don't see this a large or small project thing<br>
<fantasai> una: My concern is that the DOM change so quickly, you have a paragraph inside a list and link inside, so lots of layers already<br>
<fantasai> una: and not realize that you're not directly within a parent<br>
<fantasai> una: 2nd question, example of font-style italic<br>
<fantasai> una: what happens when you have an em that also has a span and then a link inside of that?<br>
<TabAtkins> Miriam's point is that in that nested case you *can* generally depend on the parent for style, because you very likely want the inherited value. If you don't, then you should be explicitly naming on both sides.<br>
<fantasai> una: This is where the uncertainty of the output comes to me<br>
<fantasai> una: I don't see the direct parent, you don't know as a publisher what the output DOM would be<br>
<fantasai> una: So I see this getting murky<br>
<fantasai> una: But there is room from dev perspective to get really clunky, and generally expanding more into component queries it get less useful<br>
<fantasai> una: Is this going to introduce confusion if not fully aware of what DOM looks like?<br>
<fantasai> una: Is this going to be majority use case, worth a default?<br>
<fantasai> astearns: One thing that made me possibly reconsider, you're talking about clunkiness, for the cases that you're concerned with, authors can use container names<br>
<fantasai> astearns: but if we do not have the style container be the default for all elemets, then in order to serve that use case, then there needs to be a reset with * { container-type: style }<br>
<fantasai> astearns: which seems even more clunky than using container names<br>
<fantasai> una: So you'd need a container name?<br>
<fantasai> miriam: Right. You'd need it to be always the parent for it to work.<br>
<fantasai> una: Yeah, that's the strongest argument I've heard<br>
<fantasai> miriam: And to me, brittle DOM is an argument for this. Or rather, it's an argument for always using a container name when you need the DOM not to be brittle.<br>
<fantasai> una: Sounds like it would be a best practices / education point then<br>
<fantasai> una: That last point really drove this home<br>
<fantasai> astearns: I'm really concerned about the teachability of this<br>
<fantasai> astearns: We've got explicit containers, and also implicity style queries.<br>
<fantasai> astearns: But it does seem to be the best default to start with<br>
<fantasai> astearns: So spec currently says that style containers are the default?<br>
<fantasai> miriam: I'm not sure that's in the spec yet, but it was resolved<br>
<fantasai> astearns: What if we don't re-resolve, just leave things as they are and give Una and whoever else some time to come up with arguments for changing back?<br>
<fantasai> una: works for me<br>
<fantasai> una: I definitely see both sides of this<br>
<fantasai> una: want consistency for the spec<br>
<fantasai> astearns: Anything more on this issue?<br>
<TabAtkins> ack<br>
<TabAtkins> ack TabAtkins<br>
<fantasai> miriam: Need to clarify when multiple queries in a contianer rule, would they individually select different containers<br>
<fantasai> miriam: I think we should resolve that for a given @container rule, select a single container for all queries in it<br>
<TabAtkins> Strong+ on this new resolution<br>
<fantasai> miriam: not different containers for each query within the @container<br>
<fantasai> astearns: We would have that with nested @container queries, right? SO this would just be about adding easier syntax<br>
<emeyer> fantasai: I’m a strong +1 on this resolution<br>
<emeyer> …If we want to do mixed in a single statement, that’s an argument for syntax that allows you to flatten nesting.<br>
<una> LGTM<br>
<fantasai> s/for syntax/for using @if/@when syntax/<br>
<fantasai> astearns: Proposed that we check all queries against a single container that can answer them all<br>
<fantasai> RESOLVED: All queries in an @container rule are against the same container, which can answer them all<br>
<fantasai> astearns: Next question is whether to punt on style queries<br>
<fantasai> astearns: Since we still have this open question of whether to make all elements style containers, we should punt?<br>
<fantasai> jensimmons: yes please<br>
<fantasai> RESOLVED: defer style containers to L4<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6644#issuecomment-1034036418 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 9 February 2022 17:52:54 UTC