Working with Valo as a base theme is … not a great deal of fun.
Variables are multi-purpose, which on the surface, seems like a great idea. It gives continuity, allows for clever use of automatic color variations - everything is just fine…
Until you want a specific component to have a different color and then find, in the mixin, it’s bound to the same variable as another.
Two of the main culprits are $v-focus-color and $v-background-color.
These are by no means the only ones.
So, lets say I want the spinner to be a different color to $v-focus-color?
I have two options:
Create yet another class, overriding the default valo spinner, thus resulting in more css overhead
Copy the mixin into my child class and modify that.
Why on earth not just have:
$v-spinner-color: $v-focus-color
In the variables file?
Then in the _loading-indicator.scss file, use that variable instead?
As I’ve mentioned, these problems are replicated across the entire valo theme.
It’s so overcomplicated, such a mess of ‘clever’ mixins, I’m having to replicate entire mixins in my child theme to get the flexibility I require.
I strongly advise the team who created valo to have a good look at Twitter Bootstrap - at it’s simplicity, elegance and extreme ease of modification.
I am currently working on the next version of Valo for Vaadin 8, and I would love to talk with you more in detail about the problems you’ve been having with the current version of Valo and what you would like to see in the next version.
If you (or anyone else who has tried to theme with Valo, for that matter!) would like to be interviewed for about an hour through Skype or Google Hangout and thus contribute to a better Valo in Vaadin 8, please send me an email: marlon(at)vaadin(dot)com
I think a good course of action is to study how Twitter Bootstrap and Zurb Foundation are structured.
As I’m primarily a front-end developer, at this stage, I’m not well versed enough in the internal workings of Vaadin to make suggestions related to the structure of class names and exactly why Vaadin generates what I’d call “div soup”.
The single biggest improvements, which would have no impact on devs who aren’t doing advanced theming, would be:
Variables for many more properties - this is the single biggest win
Less complex mixin structures - although having to work with these would be lessened by applying point 1.
