-
Notifications
You must be signed in to change notification settings - Fork 669
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
Comments
Assigning me to this issue is the opposite of what's happening. ^_^ |
@tabatkins, I think you’ve indicated Secondly, @tabatkins, do you think there might be an acceptable alternative to I am curious if something like /* style any focused element with a "my-ident" part */
::theme(my-ident):focus {
color: var(--one);
}
x-component {
--one: blue;
part: my-ident;
} |
@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 |
I support @jonathantneal, we need some way of abstracting css. In sass we use mixin to share common style but this has his drawbacks. |
Very interested in seeing how this plays out. I've found @apply to be extremely useful when building out large scale design systems. |
It can't - that causes worse issues than |
@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 ( 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. |
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. |
@tabatkins Hi, tabs, in your article, you say:
But I think we still can use
You can test in the http://cssnext.io/playground/ , it will works fine If I am wrong, please let me know, thanks! |
My name is just Tab. It's not a title or a nickname. ^_^
Yes, the user of the Say you want to apply some styles normally, and then some different styles on
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:
With this, the user of your component can set their normal styles in a |
What's the status on this? Is this really abandoned for good? Or is there already some alternative for lightdom? |
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. |
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? |
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. |
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.
The text was updated successfully, but these errors were encountered: