[css-mixins-2] bring back `@result` and make `@private` more intuitive and generally useful?

https://drafts.csswg.org/css-mixins-1/#private

I've been working on a transpiler for @private and I found that this rule has some weird aspects.
I don't think we would design it this way if we weren't designing it to make mixins work without @result.

I also think that the use cases for @private go beyond mixins and that this is a feature that is often requested by authors and it is something we should get right.

If I have to pick between:

• @result in mixin and @private that works as authors expect it to
• no @result and @private mainly works in support of mixins and even then in a weird way

Then I would pick the first option.

---

@private is now specified and dependent on nesting for slightly more complex use cases.
For example:

.foo {
  @private {
    --color-a: red;
    --color-b: green;
  }

  color: var(--color-a);
  background-color: var(--color-b);

  &:hover {
    /* flip the colors */
    color: var(--color-b);
    background-color: var(--color-a);
  }
}

This example can't be written without nesting while using @private.
This second example isn't valid by the current spec:

@private {
  .foo {
    --color-a: red;
    --color-b: green;

    color: var(--color-a);
    background-color: var(--color-b);
  }

  .foo:hover {
    /* flip the colors */
    color: var(--color-b);
    background-color: var(--color-a);
  }
}

Where instead of being attached to the nearest style rule, custom props are attached to the nearest @private rule.

Because nesting is required, you run into issues with CSS that can't be written with nesting today.
Like for example referencing pseudo element selectors.

---

Any rule that can't be placed inside a style rule is also impossible to use with private props.
Like for example @keyframes.

Authors will want to use private properties inside @keyframes.

There should be a way forward for this.

.foo {
  @private {
    --color: red;
  }

  animation: --foo 2s;
}

@keyframes --foo {
  to {
    color: var(--color); /* can never see private props */
  }
}

The same is true for @property and having typed private custom properties.

/* this seems much better, but is invalid by the current spec */
@private {
  @property --foo {
    syntax: <color>;
  }

  .foo {
    --foo: red;
  }
}

Or even @import with @import "foo.css" private which auto wraps everything imported with an @private.

Things like that should just work but seem impossible with the current model.

---

Also see: https://github.com/w3c/csswg-drafts/issues/14407

Mixing private and non-private props doesn't have an obvious/intuitive way of working.
Authors will continuously stumble over this.

This problem exists only because of the way @private is specced in support of mixins.

It goes away when @private is a rule that encapsulate the entire set of styles wherein private things are defined and used.

Begin with the CSS Mixins Level 1 section linked in the issue and read the related issue 14407. Compare the current @private behavior against the examples; done means the CSS Working Group resolves the model and updates the relevant draft or specification text.