Improved styling

[trueadm]

One thing that is critical to styling libraries, is the ability to "pass" or "forward" styles between components. Today, it's not easy to do that, but imagine if we could use our # syntax to make this happen. Essentially, you can use #style.{cssClassName} to reference a style in your scoped <style> block and pass that on to another component – to be used as a className.

The Ripple TS compiler would ensure that this also type-safe – so trying to apply a className style that isn't in <style> would result in an error.

component App() {
  <Child class={#style.child} />

  <style>
    .child {
      color: red;
    }
  </style>
}

Then it got me thinking – maybe this is how we could also apply reactive dynamic styling too via CSS variables?

component App() {
  let color = track('red');

  <Child class={#style.child(@color)} />

  <button onClick={() => @color = 'blue'; }>{"Change Color"}</button>

  <style>
    .child(--color) {
      color: var(--color);
    }
  </style>
}

[leonidaz]

This is very cool! Both the type safety and the passing parameters as css custom props (if we can parse them correctly). For the latter, we'd still have to create some kind of wrapper to be able to apply the css prop.

scoped css props with an ability to use :global with them, might also be interesting to implement.

[anubra266]

Not a fan of the custom css syntax i.e. .child(--color),
IMO data-* attributes is perfect for reactive styles, while keeping to standard css. ripple with it's custom js templating is awesome, but it gets tricky and possible rabbithole if we start moving that into css.

First idea seems awesome to me.

[Yusyuriv]

Not a fan of the custom css syntax i.e. .child(--color),
IMO data-* attributes is perfect for reactive styles, while keeping to standard css. ripple with it's custom js templating is awesome, but it gets tricky and possible rabbithole if we start moving that into css.

That was my initial thought as well, although I'm not a big fan of using data- attributes either. But then I kept thinking of a better way to do this and couldn't come up with anything:

(Kind of) Like in Svelte? But that would mean style attribute also needs to be available on all components:

<Child style={{ '--color': @color }} />
<Child style:--color={@color} />
<Child --color={@color} />

Like in Vue? But that requires the child to declare props it wants to bind to CSS:

<!-- Parent -->
<Child :color />

<!-- Child -->
<script setup lang="ts">
defineProps<{
  color: string;
}>();
</script>

<div class="text">Text</div>

<style scoped>
.text {
  color: v-bind(color);
}
</style>

Both of these seem more verbose than this:

<Child class={#style.child(@color)} />

Especially if there are multiple variables:

<Child class={#style.child(@color, @bg, @border, @outline)} />

It would be the other way around, more verbose this way, if you wanted to assign multiple classes to a child that use the same colors, but I think it's not a very common situation:

<Child class={[
  #style.child(@color, @bg, @border, @outline),
  #style.otherClass(@color, @bg, @border, @outline),
  #style.thirdClass(@color, @bg, @border, @outline),
]} />

So, overall, the solution from the OP seems the cleanest to me.

[jdrebin]

Is there a reason why we can't just allow for multiple style tags? i think the more the syntax changes the more needs to be learnt and the less familiar the language/framework becomes.

If we would allow for style tags under all elements we can generate a new unique class for each tag which would enable much flexibility for targeting children different ways. heres an example of how it can look:

component Content({ rippleClass }) {
<p class={[rippleClass, 'content']}>
{"Lorem ipsum..."}
</p>
<style>
{ color: black; font-size: 1rem; }
</style>
}

component Wrapper() {
<div>

<h3>{"Title"}</h3>
<style>
{ font-size: 1.2rem }
</style>

<Content />
<style>
{ padding: 1px; }

:hover { font-weight: bold }
</style>

</div>
<style>
{ width: 100px; height: 20px; }
</style>
}

the prop "rippleClass" would be a placeholder for a unique class generated during comp, and that property gets passed into any element that has a style tag or is targeted.

additionally, the styles with "{ ... }" will be compiled to ".unique-class { ... }". so you won't need to add arbitrary classnames just to apply the styles to the element being targeted

[jdrebin]

and for reactivity, the most intuitive would probable be:

<style>
  .child {
    color: ${@color};
    font-size: ${@fontSize + 'rem'}
  }
</style>

during compile simply replace the parameters with unique css variables and add an effect which updates the variable value when the parameter is updated.

[trueadm]

I'm really not that keen on multiple <style> tags, as it makes it very complicated for the compiler and how pruning works. I'm also not keep on the ${} syntax inside the style tags, as that will conflict with CSS parsing as that syntax conflicts. Ultimately we have to use CSS variables anyway, as the CSS is generated statically and atomically rather than at runtime.

[Yusyuriv]

I think having multiple style tags adds a lot of visual noise. Imagine 5 nested elements, all having their own style tags.

[trueadm]

Personally, I think we should go ahead with part 1:

component App() {
  <Child class={#style.child} />

  <style>
    .child {
      color: red;
    }
  </style>
}

This is the MVP and will likely unlock the compat problem we currently have with using Ripple with React. So I think we should go ahead and implement this – otherwise there's no real easy way to pass styles in Ripple to React components.

[leonidaz]

A few notes:

1. We are going to allow only top level classes.
2. Has to be a pure class: not compounded, etc.
3. If a class has a dash, like big-red, do we require `{#style['big-red']} or just keep the dot which will be technically incorrect js?
4. Currently, if a class is not used, it will be commented out, so we'll have to include the #style.class in our algorithm compiler.
5. For clsx, it will have to be an array, e.g. prop={[#style.child, #style.another]}

[anubra266]

@leonidaz what so you man by pure v s compounded class

[trueadm]

1. Yep only top-level, otherwise it's a compiler error.
2. Not sure what you mean by this
3. Yeah, you'll need to use a computed class name
4. Classes referenced like this will not be pruned
5. Makes sense

[leonidaz]

I meant .child.another or child[data]. I guess a better description for it would be a standalone class.

[trueadm]

Yes it needs to be stand-alone

[WebEferen]

For me personally, we can go with the idea of #style at first. We anyway iterate quickly so let's first unlock compat layer and then later on we can eventually change it for the better suited approach.

I'm not a fan of an additional property (#style) as of global/root style, because we are going away from our idea of being simple. Additional custom property means additional learning curve and difference what people already know.

But let's start from something and then see how it goes. @trueadm

[erodriguez40157]

Is it possible to do it on a component level like Mycomponent.style.classname or in the case of your example could do this.style.classname so you could import styles from other components and it would read a bit more javascript without any magic #?

[trueadm]

No, this needs to be statically picked up by the compiler as it's not a runtime thing.

[leonidaz]

I really liked the original idea of having a feature where css custom properties can be connected to a component's tracked variables.

As an alternative to using a "function" syntax, we can use #component.@someTrackedVar syntax to declare custom props inside the <style> to reference tracked variables at the component's top lexical scope.

Each declaration needs to specify a default and use the css var syntax: e.g. --somecolor: var(#component.@color, red);

Users can create global or class scoped custom prop declarations, inside :root { ... } or selectors.

But regardless, all ripple-managed declarations end up being created in the :root { ... } with a unique name for each.

The user-defined declaration stay where they were declared and get set to the ripple-managed uniquely named declarations.

We basically set up an internal effect to track changes of each of the referenced component tracked variables and once they change, we change the ripple-managed uniquely named custom properties, e.g. document.documentElement.style.setProperty('--ripple-1ikjjlr-1-somecolor', newValue)

It seems like a pretty simple, flexible and familiar syntax and users can still use the already implemented #style.class syntax to pass-in scoped class names to children.

Here's a code example:

component App() {
  // variables used by style have to reside in the top scope
  let color = track('red');
  let someOther = track('blue');
  
  <Child class={#style.test} />
  <button onClick={() => { @color = @color === 'red' ? 'black' : 'red' }}>{'Change color'}</button>
  
  <style>
    /* has to come from the component's top scope */
    :root {
      --somecolor: var(#component.@color, red);
     }
    
    .test {
      --bgcolor: var(#component.@someOther, blue);
      color: var(--somecolor);  
      background-color: var(--bgcolor);
    }
  </style>  
}

component Child(props) {
  <div {...props}>{'Child'}</div>
}

transformed to css:

<style>
  :root {
    /* all ripple-managed declarations go into `:root` with unique var names */
    --ripple-1ikjjlr-1-somecolor: red;
    --ripple-1ikjjlr-2-bgcolor: blue;
    
    /* set the global user var to the managed */
    --somecolor: var(--ripple-1ikjjlr-1-somecolor);
  }  
  
  /* scoped to the class selector */
  .test.ripple-1ikjjlr {
     --bg-color: var(--ripple-1ikjjlr-2-bgcolor);
      color: var(--somecolor);  
      background-color: var(--bgcolor);
  }
</style>

and js:

  _$_.effect(
    var __a = _$_.get(color);

    // this will be wrapped in a function
    document.documentElement.style.setProperty('--ripple-1ikjjlr-1-somecolor', __a);
  );
  
  _$_.effect(
    var __b = _$_.get(someOther);

    // this will be wrapped in a function
    document.documentElement.style.setProperty('--ripple-1ikjjlr-2-bgcolor', __b);
  );  

During compilation we perform:

1. Validation

• top scope component variables
• css syntax has to have a default value

2. compile style:

• collect all scoped usages of the css custom prop declarations (analyze)
• replace the var(#component.var, default) with the default
• all custom properties declarations go inside the :root with unique names
• js added to track changes and change the uniquely named managed css custom props.

[trueadm]

I completely missed the trackCssProp bit. Makes 100% sense now. Although trackCssProp is not the best name. What if we had a prop on the style tag to do that instead too?

[leonidaz]

Yeah, I agree trackCssProp is not the greatest name.

What if we had a prop on the style tag to do that instead too?

You mean like so?

let color = track('red');

<style --color={color}>
  .test {
    color: var(--color);
  }
</style>

That's very cool and very elegant!

We'd need to have a default value though for SSR and in general since css is set before js kicks in. so, something like this: <style --color={color, 'red'}> (we can probably compile this as a function) or as a tuple actually : <style --color={[color, 'red']}>.

it's less type safety because @property forces to use a type (and a default), but definitely much more intuitive and a lot less typing.

I like it a lot actually, it's a brilliant idea!

[trueadm]

What about

<style {color}=“red”>

[leonidaz]

I think it would be less clear.

It forces you to use the variable name as the css prop name, which is not feasible in many cases.
Not as intuitive because the --color is the exact same thing you'd use in css.

[trueadm]

Yeah that’s fair. Let’s go the tuple route then. Do we need a default value? Couldn’t you do ?? “red”

[leonidaz]

Yeah, we definitely need a default value to set the custom css prop. Our build step, as well as vite, places the css into a separate file which gets placed into the <head> vs embedding it from the component so we need something there.

We could set it to initial or inherit but then the user will get a fouc. Or we can set it to an non-existing custom property, e.g. --color: var(--non-existent);

If there is no default than the browser falls back to the previous valid value in the cascade, eventually reaching the browser default, e.g. for color it's white.

We could rely on the user to set the default when they use var, e.g. .test { color: var(--color, red) } but they'd have to do it everywhere where they use the var(--color).

We could allow the user to declare the css custom property inside the <style> with the same name as the prop, but that's essentially the same as providing it n the prop in the first place but now separate from it and more confusing.

We could make the default optional and let the user decide but I'm afraid most won't be aware of the fouc consequences. To be fair, it still could occur if the provided default is different from the tracked value on load.

I'm good if you want to allow both syntaxes: <style --color={color}> or <style --color={[color, 'red']}>

I'm also good if we want to allow the shorthand, although it's less readable to me: <style {color}>

Couldn’t you do ?? “red”

<style --color={color ?? 'red'}>, while we can make it work in the compiler, semantically it implies runtime js behavior. I think if the user is providing a default anyway, using a tuple would avoid these impressions: <style --color={[color, 'red']}>

But again, I'm totally open to going with <style --color={color ?? 'red'}> or <style --color={color || 'red'}>

So, the resulting spec, except for the final decisions on the syntax for the default, would be the following:

style source code:

<style --color={[color, 'red']}> /* or --color={color ?? 'red'} or --color={color || 'red'}  or --color={color} or {color}> */
  .test {
    color: var(--color);
  }
</style>

style compiled code:

<style>
  :root {
    /* set a uniquely named var with the default on the document for fast access and modification */
    --ripple-1ikjjlr-color: red;
  }
  
  .ripple-1ikjjlr {
    /* create a scoped custom prop that only apples to the scoped styles linked to the one in the `:root` */
    --color: var(--ripple-1ikjjlr-color); 
  }
  
  /* user compiled code, same as today */
  .test.ripple-1ikjjlr {
    color: var(--color);
  }
</style>

the tracking js is compiled to something like this:

  _$_.effect(
    var __a = _$_.get(color);

    // this will be wrapped in a function
    document.documentElement.style.setProperty('--ripple-1ikjjlr-color', __a);
  );

[trueadm]

Yeah, we definitely need a default value to set the custom css prop. Our build step as well as vite, places the css into a separate file which gets placed into the vs embedding it from the component so we need something there.

Yeah, but during SSR runtime, we can just set the CSS variable in the containing HTML element right? It doesn't need to be in the CSS file because it's just a CSS variable. Just like how StyleX and Svelte 5 deal with this, no?

[leonidaz]

this design doesn't require a containing element which is a big win in my opinion.

We still could figure out a way to to set the custom prop in ssr, but then not everyone will use ssr

[leonidaz]

actually, we probably need another parameter in the tuple.

as designed, the custom css prop is scoped to the component, you can use it inside the component or pass it in to child component via #style.class and then be able to use it.

but we should support a way to create a global css custom prop. so, thinking by default it will be scoped to the component but you can provide another "param" to the tuple, e.g.

<style --color={[color, 'red', 'global']}> or
<style --color={[color, 'red', 'scoped']}> or it could be called component or local

The global one will compile to:

<style>
  :root {
    /* set a uniquely named var with the default on the document for fast access and modification */
    --ripple-1ikjjlr-color: red;
    /* global custom prop */
    --color: var(--ripple-1ikjjlr-color); 
  }
  
  /* user compiled code, same as today */
  .test.ripple-1ikjjlr {
    color: var(--color);
  }
</style>

[trueadm]

You need contain it to an element regardless it’s common to have the same variable mean different things through an app with scoping and overriding. It’s not a single global thing

[leonidaz]

yes, for sure, but people can create container elements on their own if they need to override something.

Here's we're dealing purely with the style / css where you're able to update css via js. We're not dealing with elements.

If we allow css custom props on components then we can automatically compile them inside a container element with css props set on the style prop and then people can use them inside the child component's <style> like in svelte.

The scoped css custom props are accessible only within a component or by passing in the class to children: #style.class and then the child could override the scoped css variable via a container element.

We're also allowing creating global props that can be overridden anywhere down the dom tree by a container element.

If you're saying that scoped css props have no or limited value, we can drop them or only create them with an option.

[leonidaz]

Ok, I had time to sleep on it, reflect and simplify.

We should definitely separate container elements from the stylesheet implementation. Container element handling should be either done by users or we can come up with something like what svelte did.

We're going with the style prop syntax where we can have a few variations and i think we can and should support them all:

 <style
   {color} /* shorthand, no `--`, no default value */
   color={something} /* longhand, no `--`, no default value */
   --color={something} /* `--` in front, always longhand, no default */
   
   color={[color, 'red']} /* longhand, no `--`, with a default value */
   --color={[color, 'red']} /* `--` in front, always longhand, with a default */   
 </style>

Here's an example to illustrate the spec:

<style --color={[color, 'red']} {font} --global-margin={margin} {padding} border={cssBorder}>
  :root {
    --global-margin: 6px;
  }
  
  .test {
    color: var(--color);
    padding: var(--padding);
    border: var(--border, 1px solid grey);
    --font: 12px;
  }
  
  .test :global(button) {
    color: 'red';
  }  
</style>

transformed to:

<style>
  :root {
    --ripple-1ikjjlr-global-margin: 6px;
    --ripple-1ikjjlr-color: red;
    --ripple-1ikjjlr-padding: initial;
    --ripple-1ikjjlr-border: 1px solid grey;
    --ripple-1ikjjlr-font: 12px;
    
    --global-margin: var(--ripple-1ikjjlr-global-margin);
  }
  
  .test {
    color: var(--ripple-1ikjjlr-color);
    padding: var(--padding);
    border: var(--ripple-1ikjjlr-border);
    --font: var(--ripple-1ikjjlr-font);
  }
  
  .test :global(button) {
    color: var(--ripple-1ikjjlr-color);
  }
</style>

The result is:

1. if style prop provided a default, that default is used, otherwise, the default specified in the stylesheet is used and if no default, initial is used.
2. all custom property declarations in the stylesheet that match the style prop name have their values set to the ripple-managed custom prop
3. all usages of var(--custom-prop), aka non-declarations`, that match the style prop are replaced by the ripple-managed custom prop

Wins:

1. simple and familiar prop syntax for connecting Tracked variables to affect styling via the stylesheet
2. custom prop stylesheet declarations can reside at any level, so users can create scoped custom props, including using :global to affect child components
3. unscoped, aka global, custom props declarations can be placed inside the :root { } and used as needed and overwritten by using container elements
4. stand-alone classes with scoped custom properties can be passed in to children via #style.class where they can overwrite the scoped custom properties if needed.
5. tracked variables connected to the stylesheet can be passed in to children to be mutated, affecting the parent or their own styling.

[trueadm]

Perfect, maybe create a PR so we can play around with it and then I can give more feedback next? Looks awesome :)