The front-end work of defining all the colors with variables is in place - I’d be super happy if what ultimately happens is that all the fields in the backend editor are generated by reading the variables in the SCSS file… so if variables are added and removed from the core in the future, it adjusts without any additional effort. I think some fine-tuning of how general or specific the variables are may happen once there’s a usable backend editor.
It seems to keep getting higher on the priority list as 1.0 approaches, so we’ll know more soon!
I have done a robust re-skinning of Discourse, here, and might I suggest that we add a toggle to the custom CSS box for SCSS or CSS? I think the CSS bit could be loaded in after the asset packer CSS (as it is now), whereas the SCSS customizations could be incorporated into the packer, and allow use of variables/functions defined by the core SCSS files. I’m not sure how this would impact theme store or whatever, but it would take some of the pain out of hand coding the CSS.
I’m thinking something like this for the admin section… anything that changes the opacity from 100 would have to be converted from HEX to RGBa, complicates things a little bit… but seems like something that would be useful.
Support for a color picker would be nice too, and there are a bunch of javascript pickers floating around ( if we’re not going to roll our own )… though I’m not sure what the best option is. I used JSColor for this example… It’s ugly by default, but simple to restyle.
I like the first mockup better. I’m not sure a color picker is needed. In general, you want to choose the colors using some other tool anyway and just plug them in here. Text input is fine for that and makes the ui simpler.
The , , and reset to default buttons are from the Settings UI, where each value is saved individually and immediately. But I don’t think we want each color value to be saved to the server immediately like that. Colors will be saved with the Save button at the bottom like the rest of the customization tabs.
So I don’t think we need the . But an undo button that puts back the saved value would be useful.
What does reset to default do?
use the default value from variables.scss?
if a built-in theme was chosen, get the value from that theme?
Are there any plans in the pipeline for a WordPress style theming system (independent and isolated from core)? I guess the real equivalent would be bundling all the handlebars templates into a plugin.
As nice as Discourse is at the moment, it’d be nice to have a way to make each forum structurally different (as opposed to just differently coloured).
I think ideally we would have two different top-level tabs in the customize section, one for customizing colors and the other for creating CSS/header customizations that we have right now.
The colors tab doesn’t even need to be shown if the upcoming suppress_default_style_sheet site setting is set to true.
I think this makes sense, and solves the problem of enabling multiple customizations. You choose your colour theme, and then you can make customizations.
, 
, and reset to default buttons are from the Settings UI, where each value is saved individually and immediately. But I don’t think we want each color value to be saved to the server immediately like that. Colors will be saved with the Save button at the bottom like the rest of the customization tabs.
