[css-contain-3] Nesting Context (side effect / enhancement)

[jakob-e]

Based on the current implementation in Chrome Canary and Safari TP Container Queries seems to only need a property name – allowing them to be used to expose nesting context.

  /* this works */
  .container-a {
    container-name: A;
    container-type: inline-size;
  }

  @container A (inline-size) {
    .child { color: orange; }
  }

IMO it makes a lot of sense to use Container Queries to handle this scenario (child styling without a direct reference to the container selector(s)).

If possible it would be nice if container-name could be used without having to specify container-type and query

  /* simplified syntax (suggestion) */
  .container-a {
    container-name: A;
  }

  @container A {
    .child { color: orange; }
  }

Codepen Example

I hope it makes sense and that I haven't overlooked existing issues Thank you for your hard work – it is highly appreciated 😃

[andruud]

Maybe this is a job for @scope instead? https://drafts.csswg.org/css-cascade-6/#scope-atrule

[jakob-e]

Maybe this is a job for @scope instead? https://drafts.csswg.org/css-cascade-6/#scope-atrule

I'm thinking it more as a reference to the container selector(s) using a simplified syntax based on the current implementation

.sidebar-left, 
#sidebar-right {
   container-name: sidebar;
}

/* nested inside .sidebar-left or #sidebar-right */
@container sidebar {
  .component { color: tomato; }
}

[tabatkins]

If I'm reading the request correctly, I think this is just asking for the CSS Nesting spec, right?

[jakob-e]

If I'm reading the request correctly, I think this is just asking for the CSS Nesting spec, right?

No, it is more of a reference - I'm not sure how to explain it - maybe this demo will help clarify Here is a demo link

Chrome Canary with container queries enabled chrome://flags/#enable-container-queries or Safari TP

[tabatkins]

Right, it's like Sass's @extend feature that lets you package a selector into a ref. What I'm saying is that, for the most part, Nesting gives you the same benefits, just without the potential for indirection across a stylesheet.

[jakob-e]

I'm not sure what you mean by

potential for indirection across a stylesheet

What I'm talking about is allowing to omit parts of a syntax in the _Container Query_ implementation that is already being rolled out (not a new feature).

As shown in the demo you can use CQ's to detect if a selector is a child of a container. But if used for that purpose (side effect) alone the syntax feels a bit hackish.

My suggestion is that – if you omit the parts shown below as comments - the type and query would be implicit. I know inline-size is not the correct type it was just what I found to be working

.container {
   container-name: MyContainer;
   /* container-type: inline-size; */
} 

@container MyContainer /* (inline-size) */ {
   .child { color: orange; }
}

I'm sorry for being bad at explaining myself – please bare with me 🙏🏻🤗

[tabatkins]

The "indirection across a stylesheet" means that you can define a container in one spot, and then rely on the container name somewhere else to condition another selector; as opposed to Nesting, where the outer selector is directly wrapped around the inner selector with no indirection. You can even define a container in a different stylesheet entirely!

But that indirection is the only benefit this (admittedly hacky) usage brings over Nesting. They're otherwise doing the same thing.

[jakob-e]

True, but I feel this is similar to CSSVars – a trade-off for having better composition options (structure).

[mirisuzanne]

This is a use-case that I've considered as well. I think there might be use-cases for simply checking that you are in a named container, without additional query info. There's a lot of overlap with the use-cases for style queries or higher level custom properties – checking to see if you are in a particular style context, and adjusting to match it. This would basically be syntax sugar for a style query of the container-name property, which in some cases could be used instead of creating a new custom property to query.

To summarize:

• I think this has totally reasonable use-cases that are distinct from nesting, but those use-cases can already be achieved
• The existing solutions provide the same functionality with only a little more explicit code
• If we find that it's a very common use-case, this seems like a change we could make down the road without compat issues