[css-apply-rule] New advocate for the spec

[NicolasJEngler]

Recently I found a discussion in the WICG Discourse platform, were it was stated that @tabatkins would be leaving behind the at-apply rule spec to focus on other solutions pointed towards the Shadow DOM. Even with the "Just use a class™" argument, I believe the at-apply rule could be a great addition to CSS (independently if it was initially thought for the Shadow DOM or the Light DOM), and apparently right now the spec is in danger and will most likely be dropped if no one else takes care of it.

Is there someone in the CSSWG interested in keeping this feature alive with enough time as to take care of its evolution? I'd love to contribute in any way I can, but I'm afraid that since I'm not a part of the CSSWG there's not much that I can do besides making proposal/additions and or corrections for the spec.

[tabatkins]

Assigning me to this issue is the opposite of what's happening. ^_^

[jonathantneal]

@tabatkins, I think you’ve indicated @apply is a bad solution which should not be implemented. If that’s accurate, would you mind placing a deprecated notice or something similar to the spec linked above?

Secondly, @tabatkins, do you think there might be an acceptable alternative to @apply, or do you think its best lightdom does not have such a feature/sugar at all? In the event there is hope for an alternative, @NicolasJEngler, would you accept moving forward with that, or would you still want an advocate for the @apply syntax specifically?

I am curious if something like ::part or ::theme can still be applied to the lightdom. I roughly understand its syntax relies on a part attribute in HTML, but could that attribute be moved within CSS itself?

/* style any focused element with a "my-ident" part */
::theme(my-ident):focus {
  color: var(--one);
}

x-component {
  --one: blue;
  part: my-ident;
}

[NicolasJEngler]

@jonathantneal I'd be more than happy to move forward with an alternative if that's the case, as long as it works in the same (or similar enough) way @apply was intended. I'm not necessarily rigid on following to the current syntax, but I don't see a problem with it either.

[MatteoWebDeveloper]

I support @jonathantneal, we need some way of abstracting css. In sass we use mixin to share common style but this has his drawbacks.

[jarodtaylor]

Very interested in seeing how this plays out. I've found @apply to be extremely useful when building out large scale design systems.

[tabatkins]

I am curious if something like ::part or ::theme can still be applied to the lightdom. I roughly understand its syntax relies on a part attribute in HTML, but could that attribute be moved within CSS itself?

It can't - that causes worse issues than @apply originally had, because now selector matching depends on what other selectors matched. @apply only has circularity issues within the space of properties; at least you can tell ahead of time what selectors apply to the element.

[rolfen]

@apply is pretty cool. It basically allows you to re-use CSS declaration blocks without having to copy them around, without having to modify their selectors (better CSS organization) and without having to use a CSS pre-processor (eventually).

It will make it easier to use CSS frameworks and keep semantic class names at the same time.

CSS frameworks won't have to use visual semantics anymore (<input class="fl w-third ba b--blue pa3 h3">...).

It would be a simple, native solution. I would hate to see it dropped in favor of something more complicated.

I understand that there are issues with variable substitution, however I hope that these can be resolved.

At the moment, I would just add a selector if I want to reuse a CSS block (without a pre-processor), so a block can end up with many unrelated selectors. It works, but looks disorganized and is somewhat difficult to maintain.

[yatil]

I use(d now) @apply to separate “visual classes” from semantic ones here:

https://github.com/w3c/wai-website-components/blob/master/css/base.css

I think it might be useful to have its mechanism, maybe we could reduce it to a minimalist use case, disallowing @apply and the declaration of variables… It is very useful and it would be sad to lose the functionality.

[NE-SmallTown]

@tabatkins Hi, tabs, in your article, you say:

With @apply, the user doesn't have access to selectors anymore, so pseudo-classes don't exist.

But I think we still can use @apply, e.g.

.foo:hover {
  @apply --variableName;
}

or 

.foo {
  &:hover {
    @apply --variableName;
  }
}

You can test in the http://cssnext.io/playground/ , it will works fine

If I am wrong, please let me know, thanks!

[tabatkins]

Hi, tabs

My name is just Tab. It's not a title or a nickname. ^_^

But I think we still can use @apply

Yes, the user of the @apply rule can certainly use pseudoclasses. But the person who is setting the custom property can't.

Say you want to apply some styles normally, and then some different styles on :hover (a quite ordinary use-case). You cannot do this:

.foo { @apply --var-name; }
.foo:hover { @apply --var-name; }

This will just apply the exact same styles in both cases, which isn't what you want. You instead have to manually invent a separate variable, like:

.foo { @apply --var-name; }
.foo:hover { @apply --var-name-hover; }

With this, the user of your component can set their normal styles in a --var-name: ...; property, and their hover styles in --var-name-hover: ...;. But then what if they want to set :focus styles? Or :active styles? Or a combination of those? You get an explosion of variable names, because you're being forced to reinvent selectors using property names, which are much less powerful.