Strange Styles bug? Or by design?

@flo I think you may be the best person to ask about this.

I’ve been diving deep into building our design system using styles and I notice that if I make a change to a style and update it - it does not automatically update all other elements using the style. I have to go to each individual element and re-apply the style.

Is this a bug or by design?

If by design, why is this a design choice? Curious to know the thought behind why this is better than having the style update all elements its used on.

This seems like a bug, but to confirm: what do you mean by making a change and updating a style?

Did you update the class after having updated the CSS rule?

@luka @Quentin

yeah so I had a class called text.input-label applied to about 10 elements on a page. I then made a change to the font weight, then clicked the edit pencil for the class and saved my changes to the class.

None of the other elements on the page with the same class updated. I had to go to each element, remove the class and then re-apply it.

Does that make sense?

@samwilco can you check that your element in question does not provide their own value for each property?
By default, when you apply a class we set to undefined all property defined by the class.
If you go to your element, the property name should be in yellow, not in grey

Hmm I think this may have to do with the typography feature. in my original class the typography was set to large or whatever. I then removed the typography and changed the font weight to 500 and then resaved the class. It did not update the rest of the elements.

Seems likely to be a bug :frowning_face:

Could you open a ticket on support.weweb.io? We’ll fix this asap.

Thanks!

I keep getting confused by this too, and I think it may be a side effect of doing CSS in a UI.

In CSS, element styles are more important than class styles which are more important than global styles. Thus, an element with a class on it should have those styles, and any local styles applied to it.

In the UI, though, I would intuitively expect that adding and removing a class would add/remove all those styles, and override anything I had done locally to that element.

It seems like (although I haven’t verified this programmatically) when you update a class, it keeps the existing styles on elements as if they are element styles.

@elyseholladay see the style properties as element style in CSS.
When you add a class on an element, to make it easier and more intuitive, we reset the local style properties, so that class is ‘winning’.
If later you update the class we still do this courtersy reset, but only on the active element (the one you are editing) because we do not want to silently do this on other elements.

So if you edit a class, add a property P from an element A, and an element B has the class, and defined a value for P, you will need to delete the property P in B (local style) so that the class is winning.

If you have any feedback how we can do better, let us know, but the problem is sometime the defined value can be on purpose, and we can’t go through all your object and silently update them.

Totally makes sense @aurelie — like I said, WeWeb has implemented it the way code works; I think it’s just slightly confusing through a UI than through code.

I wonder if it’s possible to ask user intent on a class edit. For ex., “Hey, you changed the color on this class. Some of the elements that use this class have their own colors. Do you want this class edit to override their local styles or not?”

In my current case, I’m building buttons and nav, and I do want my class edits to override anything I have going on, because I am tweaking til I get to a design I like.