You can now add CSS classes to your WeWeb elements to create and re-use styles across your project.
Let's say you want to replicate the style of Bootstrap buttons in a WeWeb project:
In code, it would look something like this:
In WeWeb, you could do approach this in two ways.
In this case, create a `btn` class and a `btn-primary` subclass attached to the `btn` class
This approach has the benefit of being super simple to maintain. The downside of option 1 is that, in WeWeb, you can only have one sub-class per class so you won't be able to handle states with a subclass.
We did this to help you build in a way that is efficient and maintainable while addressing 90% of use cases but if you find this too restrictive, please don't hesitate to reach out to us to share your specific use case.
In this case, in addition to the `btn` class, you'd create a class for each style (i.e. `btn-primary`, `btn-secondary`, etc.) with multiple subclasses for `hover`, `focus` and `disable` states on each class.
This approach allows you to have as many classes as you want on an element (though we encourage you to stay lean for readibility and maintainability purposes).
It has the added benefit of enabling you to save and re-use states across elements in a subclass.
Here's how both approaches to classes work in WeWeb:
A few things to note about classes in WeWeb...
We didn't want to enable autosave when styling a class because of the risk of updating something by mistake that impacts other elements in the project.
When editing the CSS property of a class, you will see a light gray background appear around the name of the property you just changed.
Once you save the change (by going to the pencil icon of the class and clicking on "Save", you will see a yellow/orange background around the name of the properties you saved.
The order of classes matters: the style of the bottom class will override the style of classes above.
If you want the `btn-primary` class to inherit styles from the `btn` class, it needs to be placed below its parent class.
You cannot have sub-subclasses. We chose this approach because we believe it is the most user-friendly to get started and most maintainable as your project grows in complexity.
After extensive user interviews in beta testing, we have yet to come across a use case where this is an issue.
If you feel stifled by this implementation, please reach out in the WeWeb community to let us know more about your use case.
Sign up now, pay when you're ready to publish.
