Martin Auswöger

> My one concern is that it might be hard to reason about what container is being queried, but then, that's just what we've come to expect from CSS, isn't...

To better describe the idea for the browser implementation here is an example: Lets go with a simple example DOM: ``` html ``` And the following CSS: ``` css body...

Thank you for the great feedback! So you would suggest first doing a style calculation without container queries, then a descendants-independent layout algorithm, then a style calculation including container queries...

The problem I see with splitting the style calculation and the first pass layout is that they have to run multiple times if elements with container queries are nested. In...

In my example above the body element is used as the container for the query. As I read it again now, I should’ve named it `.parent` instead of `.container`. The...

Yes it would. In my example above `html` and `body` are inheriting from their parents, they behave just like two nested `div`s would. A `.parent` with `float: left; width: 50%;`...

If someone is interested: I posted an [update on my proposal](https://au.si/css-container-element-queries) and added [a demo page](https://ausi.github.io/cq-prolyfill/demo/) for the prolyfill. The prolyfill script is now tested and pretty stable, so it...

IMO `:parent()` could be confusing for this proposed version, because the query doesn’t always target the direct parent element. What about `:context()`? Because we are querying the “context” the element...

> Isn't an element's query condition always retrieved from its parent node? The parent might have inherited the queries value but it still has the information, doesn't it? This is...

@stefanklokgieters IMO before making a proposal towards W3C, we need to know from browser makers if this version of container queries is any better than the others and if it...