-
Notifications
You must be signed in to change notification settings - Fork 81
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
JS in CSS #51
JS in CSS #51
Conversation
I'd be tempted to say that the backtick character doesn't appear in CSS so this might be a better syntax than Overall I think this is a nice idea, but I feel like it might be hellish given all the css preprocessors people are using. |
@antony Interesting, through some digging I found that backticks were also once used by Less for inline javascript, so there was an existing convention! (Though deprecated by Less) I've updated by my repo to test out multiple preprocessors and the backtick syntax. Result:
Looks like backticks doesn't get enough love from the preprocessor ecosystem. Update: |
What does this give us that css variables don't? I don't think the 'difficult to learn' criticism of css variables is valid. It is a standard and is no less esoteric then this proposal. Aligning to existing web standards where possible has always been a design goal. This would add a huge amount of complexity to the css handling and would be a significant feature. |
@pngwn Perhaps the biggest benefit this gives that CSS variables don't is that CSS variables can be scoped by Svelte, similar to how classes work. Besides that, it's purely subjective whether the syntactic sugar is actually worth it. I'm currently comparing this to style properties as it plays at the same "syntactic sugar" feature level, that both can be done with pure CSS variables manually. Regarding web standards, I chose But if the goal is to stick proper laid-out web standards, then I'm fine if we wait longer for the CSS ecosystem to progress, but at the same time it'll be interesting for Svelte to take the first leap. |
The issue there is that we don't want endless sugar, we already have the css properties thing we don't want to keep adding different kinds of sugar to do the same thing. We have a pretty clear preference to use the simplest, most standardised approach where possible. |
I agree that having too much sugar isn't great, but however I don't think the style properties feature is doing the same thing as this, as highlighted in the technical background section. Furthermore, in a bigger picture of JS in CSS, I'd like to see CSS variables as the implementation detail only. So would the consensus be that JS in CSS would not be implemented/considered in the future? Nonetheless, I'm hoping to have a final answer for this as it's a topic that comes around from time to time. |
I've gotten by in a lot of cases by just putting the dynamic CSS on the elements e.g. |
While that's fine, it's not necessarily the most dry if you're going to be repeating the same style in multiple places, especially you have more than one rule that might need some dynamic rules in the same element. Would be nice to frame this off a class and do the dynamic stuff in CSS with that class and apply it all with one class definition. |
Just realized Vue had this feature for a while now in this RFC and have recently be merged into Vue 3.2. It's using |
This came up in the discord today because someone shared a link of vue's implementation of this and people (at least I) got very excited about the idea of having this in svelte as well. <script>
let color = 'hotpink'
</script>
<h1>Pretty in pink</h1>
<style>
h1 {
background-color: var({color});
}
</style> if this desugars to something like this <script>
let color = 'hotpink'
</script>
<h1 style="--svelte-hash-h1: {color};">Pretty in pink</h1>
<style>
h1 {
background-color: var(--svelte-hash-h1);
}
</style> the |
@Theo-Steiner The issue with that syntax, or any other curly braces syntax, is that they don't work well with IDE extensions. I've tested them in VSCode with this repo for postcss, sass, and even normal css, they all currently report parsing errors, which the Svelte vscode extension can't handle (?) as the syntax highlighting are all done by external vscode extensions. Using |
with #42 I don't think, we will need this RFC at all, and I think, this will add more complexity and unexpected behaviours and other disadvantages than advantages. CSS can be dynamic only in values, that are already covered by CSS variables, so I don't see any reason to have this. But I actually like idea of #51 (comment) |
@Mlocik97 I guess so, looks like #42 had some discussion related to this feature too. Though I don't think it completely overlaps with this usecase-wise (e.g. #51 (comment)) and feature-wise (e.g. hashed css vars). But I'd agree if that RFC got merged, it would be really weird to have this merged as well since we would have too many ways of doing similar things.
As explained in the comment above, unless we embrace breaking every tooling out there, it won't be a viable option. |
I don't think this is problem at all. And it's not really reserved. |
I've tried that before and it is a problem. If you insist, you can try implementing that variant based on https://github.com/bluwy/svelte-js-in-css then. |
Closing this as half of the votes are not in favour of this feature. |
@bluwy
|
Rendered