_blue, _green and _red were mostly added for testing the variants feature, It doesn't hurt, if these need to be reworked or even replaced.. Cleaning the CSS was more than necessary, I think we should merge ASAP..

They'd just need some minor tweaks if anyone wanted to use them. Nothing huge.

Thank you, Ant!

Changed some in images/white. Yay for green moose!

Is it supposed to be in, I don't see changes in images/_white?

Eh. Looks like Spuds missed that bit. Oh well. Easy fix. Can give you green moose on the forum. I'll check it all against my local.

Eh. Looks like Spuds missed that bit. Oh well. Easy fix. Can give you green moose on the forum. I'll check it all against my local.

Oops sorry .. I had noticed that when I did the PR and went back committed it to my local but forgot to push it ... I'll send it now

Ant: you've added the colors, box-shadows etc. directly to index.css. If someone doesn't want them in their variant those need to be removed, now..
To be honest: it's now much more work. The initial idea to use ema's white theme was to reduce this work, therefore we've removed most colors, box-shadows etc. and moved them to variant files instead...

Ok, well can change that easily enough for the colours. However, if we're doing it that way, the IMO the default (as in the one you see if nothing else is ever set) should call a variant file for its colours too, with index.css being only structural stuff. This is the way I always used to do multi themes, and as you pointed out it does make editing much easier. I'm happy to set it up that way.

TBH, the basic white theme was too much. It wont get a good public reception IMO. What I think would be the go is to have two default variants: light and dark. Light would be the one that the software calls if not otherwise set (best for most environments). Dark would be the easy option for gamerz, people who get migraines, etc.

I'd love to do this as I've long thought this is how SMF really should have been set up, and I think it'd get a lot of approval from the punters if Elk did it.

Had another thought. How about this for a plan?

At the moment, it's handy being able to do the basic css revamp without jumping between files. It'd be kinda cool to just finish the cleanup and new theme look in index.css, then can go though it and pull all the colours, etc out into a new variant file.

That would be pretty quick and easy to do once the default look is finalised. Then, doing a dark variant would be quite easy, since all the layout stuff would already be dealt with.

Are you ok with that plan?

Sounds like a good plan to me ... I thought that is what you were doing anyway 👼

Wasn't talking to you. Mind yer own biz. 😛

OK then ... I take it all back, yer plan stinks 😄

Yer mom.

Quick and dirty reset (could easily be improved) would be to add something like this to the start of any custom variant files, just during testing:

/* Quick and rough style reset for variant testing.
-------------------------------------------------- */
* , a:link, a:visited, a:hover, .cat_bar, .title_bar, .roundframe, #wrapper {
    background: none;  color: transparent; background-image: none;
    border: none; box-shadow: none; text-shadow: none;
}

Horribly inefficient for production use, but fine on local.

Well, additions are not cleanup. It runs the risk of doing too much in the same time in the same place (index.css having everything). Which in return will ask for more work to clean it up afterwards. Dunno. I thought the intention was cleanup (of redundant css).
I think additions (shadows, colors even) should go in a separate file. This way, we keep tabs on them, and themers can have a simple default to customize, while the default theme using any of its 4 (or 2) variants is included in the main package.

At least we could try to keep the additions to index.css low?

I'm not sure, why not use _white (or _green?) instead of the main index.css file, for shadows, more colors, and that?

IMO it'd be easier to do the default all in index.css first, then pull stuff out if you want to. However, this conversation got me thinking.

There's an important consideration for the final product: what do you wish to optimise for?

There two ways of doing it, depending on what your aim is. It's a bit long for a GitHub comment, IMO, so I posted about it here: http://www.elkarte.net/index.php?topic=439.msg3018#msg3018