Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
NicolasJEngler opened this issue Feb 18, 2017 · 14 comments
Closed

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

NicolasJEngler opened this issue Feb 18, 2017 · 14 comments
Assignees

Comments

@NicolasJEngler
Copy link

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
Copy link
Member

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

@jonathantneal
Copy link
Contributor

jonathantneal commented May 15, 2017

@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
Copy link
Author

@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
Copy link

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
Copy link

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

@tabatkins
Copy link
Member

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
Copy link

rolfen commented Oct 31, 2017

@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
Copy link

yatil commented Dec 27, 2017

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
Copy link

NE-SmallTown commented Jan 16, 2018

@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
Copy link
Member

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.

@lubomirblazekcz
Copy link

What's the status on this? Is this really abandoned for good? Or is there already some alternative for lightdom?

@tabatkins
Copy link
Member

Yes, it's abandoned. It turned out to be a bad approach to this idea, for vital technical reasons that mean it can't be salvaged. Nobody's taken the time to figure out the problem space well enough to find a possible solution that doesn't have similar problems yet.

@lubomirblazekcz
Copy link

Understood, so there are currently no alternatives for lightdom? What about https://tabatkins.github.io/specs/css-extend-rule/ that proposal was abandoned as well?

@tabatkins
Copy link
Member

That one's not abandoned, it's just not actively being worked on. I hope to have the time to do at some point, as I believe it has potential, but it's never risen high on my priority list so far, sorry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants