[css-mixins-1][css-values-5] The inherit() function in custom functions

[andruud]

The inherit keyword is left unresolved on the result descriptor, meaning that a function can return literally inherit, and trigger explicit inheritance at the call site. This behavior is good; it's to similar to how the var() in color:var(--c, inherit) can return inherit regardless of which syntax --c is registered with.

But is it weird that the same is not true for the functional form, inherit()?

@function --a() {
  --x: red;
  result: --b();
}
@function --b() {
  result: inherit;
}
#parent {
  --x: green;
}
#parent > #child {
  --x: --a();
  color: var(--x); /* green */
}

vs

@function --a() {
  --x: red;
  result: --b();
}
@function --b() {
  result: inherit(--x);
}
#parent {
  --x: green;
}
#parent > #child {
  --x: --a();
  color: var(--x); /* red */
}

This seems like a not-entirely-intended side effect of the "hypothetical element" model. While I'm sure there are use-cases for grabbing the value in the outer stack frame, it also defeats most/all of the use-cases outlined for the inherit() function (#2864), which do require inherit() to resolve against the actual flat tree parent.

---

Within the var()-based mixin model (#12927), this means the following would give red, which seems unlikely to be what you want:

<style>
  @mixin --m() {
    & > .child {
      color: inherit(--x);
    }
  }
  .parent {
    --x: green;
    @apply --m();
  }
  .child {
    --x: red;
  }
</style>
<div class=parent>
  <div class=child>
  </div>
</div>

I'm not sure how to solve this.

• The current state is bad, because it makes inherit() useless for its original use-cases.
• Always resolving inherit() against the flat-tree parent is also bad, because it makes values in the calling stack frame unreachable.
• We could add a parent() function in addition to inherit(), but I'd rather not add two very similar functions to "global" CSS due to @function being weird.
• Do we let both inherit and inherit() refer to the inherited value of the real element, and instead add a new keyword (+ function?) that refers to the calling stack frame? It weakens the "hyopthetical element" model, but perhaps this is the best move.
• EDIT: Or perhaps we generalize inherit()? [css-mixins-1][css-values-5] A general inheritance syntax #12990

cc @tabatkins @EricSL

[EricSL]

One more suggestion, if we want to lean away from the lots of inheritance functions approach. The behavior of inherit depends on where the closest version of the var is defined. This could actually be defined one of two ways:

• If the variable is defined for the current hypothetical element, then look in the parent of the hypothetical element, otherwise look in the DOM parent.
• If the variable is defined in any hypothetical element, then look in the parent of the current hypothetical element, otherwise look in the DOM parent.

So these are a bit more magical, but I think either would normally do what the user expects. If you avoid giving your function parameters and locals the same names that you use for your custom DOM properties, then there should be no ambiguity about what is intended.

[andruud]

Yeah, I was thinking along the same lines the other day. Maybe it is indeed viable, though I'm not entirely comfortable with the idea of inherit() being implicitly "unstable" in which element it targets based on custom properties defined above it in the call stack (your second option).

[kizu]

Do we let both inherit and inherit() refer to the inherited value of the real element, and instead add a new keyword (+ function?) that refers to the calling stack frame? It weakens the "hyopthetical element" model, but perhaps this is the best move.

This is what I would expect as an author.

I am not sure if there are that many use cases for getting the values in the calling stack via inherit()?

It is already possible to access the values from the outer scope of the function (although, in a hacky way) via default values for optional arguments: https://codepen.io/kizu/pen/gbPqzMe

@function --a() {
  --x: #F00;
  result: --b();
}
@function --b(--outer-x: var(--x)) {
  --x: #00F;
  result: color-mix(in srgb, var(--x), var(--outer-x));
}

.foo {
  background: --a();
  color: #FFF;
}

This produces a purple background, successfully mixing the --x from the --a() and --x from the --b().

If there will be actual use cases provided for having a dedicated function/keyword referring to the calling stack frame — we could add it.

[andruud]

Good point, @kizu. Since that lets you grab the outer-frame value unilaterally (i.e. no change on the call site), that seems sufficient for now.

Then how about the following:

Within a custom function:

• Functional equivalents for CSS-keywords resolve as they would on the real element.
• CSS-wide keywords behave as their functional equivalent, i.e. --x:inherit => --x:inherit(--x), --x:initial => --x:initial(--x).
  • This is to reinterpret the value using the local type. The spec already does this for inherit.
  • initial() does not exist yet, but you know what I mean.
• CSS-wide keywords (not functional equivalents) are still left unresolved on the result descriptor. (No change.)