Do you guys happen to have a template for the default themes other than the .css file itself? One what would allow variable substitution or the like for easy color changes? I mean offline variable substitution, not actual css variables.
You mean something like storing CSS values in the database like vB?
No in this case I literally meant just a file that I could substitute into offline. I guess there are systems for doing this, but I'd happily take a text file with #color1 #color2 etc. (or any other naming scheme) that I could use almost any scripting language to do an easy substitution.
Ah. No such thing. Why not just use the hex codes to do the substitutions? Standard find/replace stuff.
Ultimately that's what I'll do. But it would be nice to see where they all are. I just thought I'd ask if they were designing the themes that way and thus had a nice file where I could see it was #button1, #button1_highlight, etc.
But the problem with doing that is what if someone wants to use different presentation? All your defaults become inapplicable, so it's going to be a PITA to make such a file to start with, and it'll be of limited use for theming anyway, AFAICT.
I'm not even sure how you think such a file would be made. You're going to have to look things up anyway before you know what they are, so how is that different to checking hex codes or classes?
Hey relax. This isn't an attack. I figured if the theme were built that way it would be a nice file to have. Since it wasn't built that way I'm not asking anyone to make it.
And sure people might want to do all sorts of things. Others like me would just like to start with a quick simple color change to the theme like replacing the green with another color. Of course it's not as simple as replacing one green. There are lots of greens.
I ran this on the css file for light.
http://hex.corvidworks.com/
It shows me there are several colors I would feel safe collapsing into a single color. So i can simplify the number of colors I have to choose and swap out.
I didn't think it was an attack. I was just wondering how you thought it would be more useful than other methods. I can't see it myself.
ETA: The problem with "feeling safe collapsing several colours" is that you can't really tell how it will look until you do it. Font weight, font size, surrounding content and umpteen other factors can change how a colour looks in different elements. That's why they aren't all the same green. Put bluntly, if they were it wouldn't look as good. The way it was done was to start with the same colours, and then see what needed tweaking to make it look better.
Makes sense. And if I was highly skilled at choosing just the right color that might be important, but I'm not. And on my and most people's uncalibrated monitor I don't think I'll ever notice the difference between 38642e and 38642d. Honestly zooming in on divs of those two colors and 3a642d there simply is no appreciable difference on my monitor.
And on my phone all the colors are different of course. It's a SAMOLED display. It's blue weighted. That's because the blue has the shortest life. So over time it will go from blue weighted to blue deficient.
So as an amateur making a site for a small group of people I feel perfectly ok simplifying the color scheme.
Ok. Up to you. I can see the difference on my monitor (obviously).
And assuming you work with color, that's a good thing. :)
Hi Scripple,
I seem to recall you mentioned somewhere else eye site issues, is that correct? If so, you probably are keeping in mind the type of color and clarity.
I am not a themer or expert at all with CSS but I can muck around a bit in it. With the current _light theme you can easily use some flat colors but you should also consider removing the box-shadows if clarity is what you are after.
There is no simple fast way to make the changes but FireFox and Firebug go a long way to finding where you want to change the colors and what the colors are.
Yeah I have issues which make certain fonts difficult to read at times. Fortunately most of the shadows and such are on buttons which aren't that big of a deal as they're static content. But I have noticed some on headers and such which you're right should probably go. Honestly it would be nice if I knew more about best practices for all of this stuff, but then I've seen my share of pages that claimed to be the ultimate in readability that for me at least were certainly not.
In the end the forum is a hobby for me and a relatively small group of friends. So as long as we can all live with it things will be fine. ;)
I'd like to have reasonable looking dark and light themes, for certain definitions of reasonable.
I've been poking around in firebug today and replacing colors and kind of realized I was never going to get all the colors replaced to my liking that way. It will be much simpler for me to normalize them a bit, then replace them more algorithmically. If the result is a that a few things look horrible than I'll do as Antechinus suggests and tweak some by hand, no doubt falling far short of the detail he'd put into it.
I should have a go at a dark theme. I already had one roughed out way back in alpha days.
I will help you with what I can. Do you use Notepad++? If not, download it ( free ) and use it.
http://notepad-plus-plus.org/
Use its Find in Files feature and look for all the box-shadows. There are a bunch. :) Surround them with comment tags like this:
/* box-shadow: 1px 1px 2px #e5e5e5; */
Get rid of the box-shadows and you will get a clearer picture of what you need to change, color wise. You will want to do that in the
index_light.css and the admin_light.css files.
Do you know how to create and install a theme? There are a few files you will need to alter to set the variant.
Because of my eyes I am working on a theme that has some muted colors, no shadows and enhanced colors in some areas. I have it installed as a stand alone ( no variant ) and as a variant working off of the default.
I have not looked into how to create a theme (or variant) yet. I was simply using the custom.css option to progressively override more and more of the default _light theme.
As for editors I'm on linux not windows, but I have plenty of tools to search and edit text so that's not a problem.
Should I eliminate text shadows as well?
Yes, get rid of all shadows. It makes a huge difference for any of us that have vision issues. Shadows force our eyes to try to focus on something that we do not need to focus on. My theory is that I do not buy a book with text that is blurry or has shadows so I do not
want my forums to look the same. :)
Also, there is a good deal of gradiants in use, I have left those as I do not find them to be to bad. But if it has the words shadow in it, I would comment it out. I think there is something like 45 box-shadow in the index_light.css and 11 in the admin_light.css.
edit: I should add that you will want to look at all the files in the _light folder. There should be three .css files that you will want to edit and make any needed changes in.
Just be aware that some of the box-shadows aren't actually shadows. They're quite often used as a solid colour to provide an extra border or whatever. This gives extra versatility that you can't get with just a standard CSS border.
For instance, if you define a standard border, then add a solid colour of defined width as a normal (outside) box-shadow, and another as an inset box-shadow, you can get a triple border if you want to. Although these are technically box-shadows they can be done with no blur radius so they display as solid lines. It's a very handy CSS trick to have in your toolkit.
Yes I'm noticing that a lot of the box shadow effects are very subtle. But I have a local copy set up with them all removed and a copy with the original css.
Here's a (hopefully) simple question for you two if you don't mind. On a dark theme with a basic intent of white text on black background for the editor and main post text, my guess would be that accepted practice would not be to actually use #FFFFFF on #000000. Is that correct? And if so what would be a typical choice of off-white and off-black (inventing term?) for that?
Usually it'd be better to use something like #444 for the background, with text set to something probably not quite white (#eeeeee or whatever). There's a handy tool here if you want to check acceptable contrast levels: http://blackwidows.co.uk/resources/color-contrast-analyser.php
Speaking of dark themes, I had a hunt through my old posts here and found a screenshot of the one I was playing with ages ago. No idea if I still have the code, but could resurrect it easily enough.
http://www.elkarte.net/community/index.php?topic=328.msg2768#msg2768
Thanks for that bit of knowledge. I had seen the 'inset' used but had not looked to see how it was being used. I will go back and look at those box-shadows with the 'inset' and play with them.
My theme is using pastel colors, mostly, so I am trying to balance crispness with the pastel. I have a pretty good eye for color ( I think I do anyway :) ) but still I am looking for a nice balance. What do you know about Kearning.js? Is it worthwhile? It is on my list of things to look into.
http://kerningjs.com/
Again, thanks for the 'inset' tip.
I chose (before the test) #1f1f1f background with #cccccc as the foreground. The check site you linked to says Color Brightness: 173 and Color Difference: 519 which is says is ok by W3C standards.
For reference #444444 and #eeeeee scores Color Brightness: 170 and Color Difference: 510 so fairly similar according to that test.
I have been doing a fairly uninspired conversion of the default light theme to a dark theme with orange replacing the green and the light swapped to dark. I struggle with choosing shades of orange and gray for the button accents. I was just making the active button orange and the inactive buttons a darker gray which looked fine for me but choosing even darker accents on the dark gray buttons just made them disappear.
So that's when I started hoping there was a global replaceable set for like button accent that I could quickly try to swap everything out.
The commenting in the CSS should make them fairly easy to find. The buttons and menus have their own sections. If there's any that stump you, I probably know the classes for them.
With the contrast, I usually aim for something around the 450 mark. IOW, halfway between W3 and Hewlett-Packard recommendations, since some people would find W3's recommendation hard to read too due to too much contrast (see the discussion about dyslexia, etc). Doing one stylesheet to suit everyone gets tricky. In reality the best you can hope for is that most people will find it usable and think it looks ok.
My 2c is that when you get to the stage of relying on javascript to do something as basic as displaying text, things are getting silly.
It's not so much finding the classes. As you said the css is fairly readable. It's more a problem of picking colors. Thus my desire for an algorithmic replacement. Like rotate the color wheel or something. I fear that may not actually produce spectacular results though.
Oh, I forgot to say if you have the code for your dark theme and can find it easily I would appreciate it as a reference. Since I plan to replace the green though it seems unfair to ask you to actually spend the time to recreate it.
Oh I see that you mean. Sort of like an automatic palette generator. TBH I tend to ignore that sort of site. They're good for getting basic ideas, but attempting to stick with one generated palette in something as complex as a gui often doesn't work too well. I always end up looking at some part of it and thinking "Hey if I tweaked that bit like this....".
I'll take a look and see what I've got stashed, but it was a long time ago.
Oh Aaron could you tell me what files need to be changed to create a new variant instead of modifying and existing one?
Yes. Or an algorithmic replacement for the green shades with another color. Which is where I was coming from when I started this. Good discussion though.
I'm hoping to avoid obsessing over such things. GUIs to me are one of those things you can spend forever tweaking. And in the end no matter what you do someone will quickly tell you why they hate it. :(
ROFLMAO. Dead right. You have to have a certain amount of arrogance to do front end coding, otherwise you'll drive yourself nuts trying to please everyone. It's not humanly possible. Do something you like. If other people like it, good. If someone doesn't like it, that's their problem.
Take a look at the existing ones in the server (or install pack or whatever). If you copy one of the variant image folders and variant CSS folders and rename the copies to suit, you can then delete whatever CSS you don't want, or swap the existing files for blank ones and start from scratch.
To call the new variant you just have to add its name to the array at the top of index.template.php:
// This is used for the color variants.
'theme_variants' => array('light', 'besocial'),
Cool. Easy enough. Thanks.
Here is what I did ....
Go to Themes and Layouts>Manage and Install>Install a new theme: Create a copy of default theme named:
Let us use ScrippleTheme; now click Install.
In the \themes folder you will now have a folder with your newly named theme. In that folder in the \css you will find two other folders named _besocial and _light. These two are the variants. What I do now is rename the _light folder to something else, to avoid confusion with the default _light variant. Lets pick _scripple.
Now, in the _scripple folder you will see three .css file rename them to:
admin_scripple.css
index_scripple.css
rtl_scripple.css
Now go to the root of the ScrippleTheme and edit the index.template.php file. Around line 66 and 67 you will see this:
// This is used for the color variants.
'theme_variants' => array('light', 'besocial'),
Change it to look like this and save the file.
// This is used for the color variants.
'theme_variants' => array('scripple'),
Now, go to the ScrippleTheme directory root and create a sub dir\subdir. You want to create \languages\english. The same as you see in the Default theme. Into this newly created directory you want to copy from the \theme\default\languages\english the file named ManageThemes.english.php into the ScrippleTheme\languages\english folder.
Once that is done, edit the ManageThemes.english.php file and add this at the bottom of the file and save the file.
// Strings for the variants
$txt['variant_scripple'] = 'Scripple Theme';
That should do it. Unless I forgot something. :)
Frankly, I think this will be a real challenge for the average user and the theme designer will have fits helping people install their themes.
That's for creating a whole new theme, not just a new variant of an existing theme. ;)
If a theme is only going to have one variant, it's hardly worth using the variant system at all.* You might as well just run the default index.css and tack your custom CSS onto the end of the file, which is what a lot of people tend to do anyway. Or, you could just use the custom.css file trick. Same meat, different gravy.
Installing new themes, once they're made, will be as simple as it has always been. The process hasn't changed since SMF 1.1.x. You're getting things mixed up.
*Important point here: the variant system is provided for cases where it is useful. It does not have to be used. It's still perfectly possible to run a basic theme that only calls index.css, with no variant stuff at all.
Yep, I sort of did the whole shebang there. :D
For just the variant place the variant folder in the \default\css folder.
Rename the 3 .css files in the variant folder ( as shown above )
Make the change in index.template.php to identify the variant ( as shown above )
If you want a 'proper name' for the variant to display then make the change in the default\languages\english\MangeThemes.english.php ( as shown above )
While I still understand very little about this 'stuff', creating and installing a theme ala SMF will be the simplest way for someone to go.
Yes, you are correct and of course you insist on the last word. You may have the last word.
Thanks for all the information from both of you. I will be using the variants as I wish to have a light and a dark theme.
So I finally broke down and wrote a quick script to algorithmically convert all the non-gray color values. The end results could use tuning (the one off odd colors like error one especially) but it's actually not too bad and lets me very quickly make major color shirts bringing all the gradients and such along.
Of course orange being a rather compressed color space before it turns to brown did require a bit of extra fiddling with the script but first look is definitely better than my manual attempt that consisted largely of replacing things with a single color.
Yes, I'm terrible. :P
And went ahead and let if flip grays for the dark theme. Definitely needs some tuning there like the now bright gradient but it's a great starting point to tune specific areas from.
I think this might work even better applied to a parts of the css at a time with some tweaks like setting a luminance to shift to for the buttons.
Interesting approach. :) I sometimes open a screenshot of a theme in Photoshop and mess around with hue, saturation, etc to get ideas for variants. Usually they will still need some extra tweaking, but it's not a bad way to get ideas.
Yeah I think this is a great quick way to get me in the ballpark of what I want. Then I can make tweaks to the small elements that really need them in context of having things largely where I want them to be.
Also makes it very quick to explore whole color families for the general feel.