style blocks

[pasqui23]

rendered

[lukaszpolowczyk]

Take a look at my proposal:
sveltejs/svelte#6422

The advantage is that styles are passed explicitly, by property, and used in a controlled way.

[pasqui23]

From what I understand of @lukaszpolowczyk 's proposal bind:styles would be actual js objects. This would hinder server side rendering as it would ask to compute the value of js objects( for example, what should the server output on <Component styles={fetch(...)}/>? )

[lukaszpolowczyk]

@pasqui23 It would accept only one object type - a special object that is a style reference.

But I am aware that there are problems with my proposal.

Along the way, I made a preprocessor(not published) that takes a style fragment from any *.svelte file - such a simpler form of passing style between components.

Rather, this is not the final version, just something to think about.

[pasqui23]

sveltejs/svelte#6422 (comment)

I just wrote that if I did it less dynamically, it could all be prepared on the compiler side, and now it can be done, but doing some extra runtime side operations.

The problem is that neither javascript nor typescript have any mechanism to check whether a given code block is constant (and is in general a hard problem). My proposal sidesteps almost any runtime overhead by merely translating CSS selectors.

[pasqui23]

Along the way, I made a preprocessor(not published) that takes a style fragment from any *.svelte file - such a simpler form of passing style between components.

Well this proposal is exactly this

[pasqui23]

The exaple you have written look like a more comlicated way of doing `@import` https://developer.mozilla.org/en-US/docs/Web/CSS/@import. And if you let the `extended:` be a runtime string /object/whatever you still go in the problem of having to compile css at runtime, while my proposal limit css generation at compile time (except for web components)

[lukaszpolowczyk]

The exaple you have written look like a more comlicated way of doing @.***`.

I don't know what ***@***.*** means.

And if you let the extended: be a runtime string /object/whatever you still go in the problem of having to compile css at runtime, while my proposal limit css generation at compile time (except for web components)

Have you checked?
My suggestion is preprocessor, everything is ready after compilation.

[pasqui23]

The exaple you have written look like a more comlicated way of doing @.***`.

I don't know what ***@***.*** means.

I meant @import. My proposal is about parents styling children components, while your proposal let children take styles from svelte files, as you have presented here.
Also I think it would be better if you would post a rfc and explain in detail your alternative, clarifying any of the less clear details

[lukaszpolowczyk]

I found a much better syntax - using CSS @layerand working similar to set/getContext:
sveltejs/svelte#7465

The new CSS standard helped me. :)

In the preprocessor I can use this new syntax of mine and publish already without shame. :P

[pasqui23]

@lukaszpolowczyk Please open a RFCand in it put an example of how a parent should put for e.g. a ~font-size:14px` in a child

@pngwn I would like to know it this would solve your concerns on a svelte theming system.

[pngwn]

No it doesn't. It also has a number of limitations.

For example it says that this would be a way of styling immediate children but components are frequently made up many child components which may have any number of child components themselves. So this proposal requires them to be passed down manually, or in complex cases will require authors to set up a complex style managament system in the component itself in order to manage all of the components being passed down.

This proposal isn't very clear and lacks any detail on what the various tradeoffs are but it doesn't look like it would allow you to pass down multiple background-colors for example. It also isn't clear how you would actually make use of the passed classes or styles in the children.

This also looks like the Svelte compiler needs to take into account both parents and children when compiling which it currently isn't capable of (because it only ever looks at a single file and does not retain any context about other files).

CSS variables solve this problem far more elegantly and provide far more flexibility, I can't imagine this RFC will be accepted for that reason alone.