Hi Guy,
This seems a very useful discussion to have. I wonder if it's worth also having in the Technical forum, which seems to see a lot more traffic.
I've spent a bit of time theming using the existing Vanilla theme as a starting point. I come at this as someone with a degree of CSS and SASS/LESS experience, but whose starting-point/comfort level is with taking an existing framework (Bootstrap/Foundation/etc.) and customising from there, rather than beginning a project from scratch.
My workflow would be to customise the theme in the framework, then upload to the authoring tool on projects where that's being used. I don't find that too problematic - though I have a feeling that the step-by-step instructions for branching a theme could be a bit more spelled out in the documentation. There is a tendency not to keep the authoring tool theme as up-to-date as the version I have in the framework, just because the round-tripping does take a little bit of time and my experience has been the authoring tool can be a bit moody about theme uploads. (It'll take them, but seems to hang/require a reboot.)
My experience of theming has been that, initially, the ability to change the colour scheme by adjusting just a few variables from which a great deal then inherits seemed great -- allowing a quick departure from the default theme without major work.
However, the extent of this inheritance from a few variables - particularly in the colours - quickly presented challenges and frustrations when it came to applying a specific colour scheme or more detailed theming: especially in a scenario where I was trying to ensure that I maintained an accessible level of colour contrast. As time went on, I found myself digging deeper and deeper, unstitching some of the inheritance / fiddling with individual components, to address particular issues as they cropped up.
I'm very interested in playing a bit with the Kineo theme to compare the approach -- should I use the master or V2 branch from github as the starting point? What's the difference between them?
First thoughts are: on the one hand, I can definitely see the merits of making aspects of the theming more directly configurable in the JSON - that feels like it would match the needs of many people who really just want to change a background, and would be more authoring-tool friendly. And it's certainly a good idea to make elements like the header -- that are probably the first thing anyone wants to theme, but fall outside the standard article/block/component scope -- more accessible to customise. I guess other common scenarios are adding institutional logos to top of the page, etc.
On the other hand, you can already add classes in the JSON; and I've not had a particular problem setting up background images/colours by this means - with the added advantage that this means you can do things like mix-and-match (e.g. when combining textures with background colours). If the Vanilla theme/documentation came with some standard examples of classes that could be adapted to achieve particular things - e.g. to add a background image - I wonder if this would fulfil the same end?
Not entirely on topic, but I've also sometimes wondered whether there'd be any merit in trying to align the standard Adapt theme with something like Bootstrap or Google's Material, so that you could then more readily plug-in to the wider range of variants/alternative themes that exist for these, to quickly restyle a project. But I can appreciate this would probably be something that'd be very challenging to implement without implications for the basic DNA of the framework.
Final thought - I do have a private BitBucker Git repository that provides a step-by-step record of my first stumbling attempts at theming. Would that be of any use to take a look through? I can't share generally on the forum but don't mind giving someone individual access.
