[css-mixins-1] Do we really need the `@contents` parameter?

[andruud]

The @apply rule accepts a block following it, which can be used inside a @mixin rule using @contents:

@mixin --m(--color, @contents) {
  color: var(--color);
  &:hover {
    @contents;
  }
}

div {
  @apply --m(green) {
    text-underline: underline;
  }
}

The spec currently requires @contents to appear in the parameter list of the mixin for the above to be valid. Do we need that, though? Can't we just pretend that the @contents parameter is always there?

[tabatkins]

We don't need it, strictly, but having it gives us better consistency with normal arguments. With normal arguments, while you can omit arguments just fine (the missing ones will take their defaults), you can't provide more arguments than the mixin is defined with - it makes the invocation invalid. (Same for custom functions.)

If we didn't have an indicator of a contents-block argument, then, our behavior needs to be inconsistent in some way: either contents block is always valid to pass even if the mixin doesn't expect or use it, or we determine whether a contents block is valid to pass based on whether the mixin uses one in its body.

[SebastianZ]

If we didn't have an indicator of a contents-block argument, then, our behavior needs to be inconsistent in some way: either contents block is always valid to pass even if the mixin doesn't expect or use it, or we determine whether a contents block is valid to pass based on whether the mixin uses one in its body.

+1 on being consistent. As arguments are currently defined, I think it makes most sense to determine whether the mixin uses an @contents in its body. And if it doesn't, @apply's having a block are invalid.
No need for redundancy.

Sebastian

[SebastianZ]

Side note: DevTools should provide some feedback regarding incorrect usages of @applys.

Sebastian

[tabatkins]

+1 on being consistent. As arguments are currently defined, I think it makes most sense to determine whether the mixin uses an @contents in its body. And if it doesn't, @apply's having a block are invalid.

That's one of the inconsistent behaviors I mentioned. ^_^ We don't determine whether a normal argument is valid based on whether it's used in the function/mixin body; we base it purely on the arglist. Basing it on the body means that you couldn't, say, temporarily simplify the mixin to debug something (removing the use of the content block), as that would mean you have to go back and change all the call sites too.

[SebastianZ]

As arguments are currently defined...

That was a subtle hint that I believe the best would be if exceeding arguments were just disregarded instead of making the whole rule invalid.

... I think it makes most sense to determine whether the mixin uses an @contents in its body. And if it doesn't, @apply's having a block are invalid.

The consistency lies in @apply being considered invalid when an unexpected argument or body is provided. But if exceeding arguments and an unexpected body were simply ignored, we'd also have consistency.
Having to add @contents to the @mixins signature is consistent with having to declare the arguments, but in my eyes (and obviously also @andruud's) it is an unnecessary redundancy.

Basing it on the body means that you couldn't, say, temporarily simplify the mixin to debug something (removing the use of the content block), as that would mean you have to go back and change all the call sites too.

Right, same applies to simplifying mixins by removing an argument, currently.

Sebastian

PS: @tabatkins Little tip on quoting: Select the part you want to quote and choose "Quote reply" from the menu. Doing so keeps the formatting intact and doesn't unnecessarily poke any GitHub accounts coincidentally having the same name as some at-rules.

[tabatkins]

Right, same applies to simplifying mixins by removing an argument, currently.

No, it doesn't apply the same, that's my point. If you are playing around with a Mixin and temporarily stop using an argument in the body, all your @applys still work. Whether you use the arg or not doesn't matter, just that it's specified in the arglist. That's the behavior I was trying to maintain, with the @contents in the arglist.

The only reason you'd have to go back and edit your call sites is if you actually remove the argument from the arglist, because you've decided you don't need that argument at all, permanently. That's perfectly reasonable.

[andruud]

So the @contents parameter can't do anything that regular parameters can do (have a chosen name, type, default) except be declared. This might be what makes it feel unnecessary and/or out-of-place in the parameter list.

[tabatkins]

Correct.

[SebastianZ]

Sounds like nobody is objecting to removing it. @andruud Maybe it's fine to add it to the agenda then or even ask for an async resolution?

Sebastian

[andruud]

@SebastianZ I think Tab's arguments are slightly stronger here vs the "it feels wrong" argument, so I would like more support for removing it before asking for that resolution. For example, maybe co-editor @mirisuzanne has an opinion.

I'm still weakly in favor of removing it, but I'm also OK with a no-change here.

[mirisuzanne]

I raised this same concern in the original meta-thread. I still don't see a need for content to be declared in the arglist, it feels redundant to me – and I'm not convinced there's a real use-case where adding/removing the declared content argument is necessary for debugging. I'm not sure what problem it solves.

[romainmenke]

or we determine whether a contents block is valid to pass based on whether the mixin uses one in its body

Why is this?

Why can't it be valid when the mixin contains @content at least once anywhere in its body?
Is there a constraint or limitation that makes it harder or impossible to determine that a mixin contains @content?

[tabatkins]

Why can't it be valid when the mixin contains @content at least once anywhere in its body?

Check my reply from two days ago