What about an easier styling/theming system?

Feature
1

This would really just be a “CSS generator”.

How about a page that has nice color selectors and then nicely named coloring categories, like:

  • Primary background color
  • Secondary background color
  • Tertiary background color
  • Primary text color
  • Secondary text color
  • Primary link color
  • Secondary link color
  • Button background
  • Button background hover
  • Button text
  • Button text hover
  • Last poster highlight color

It doesn’t need to be super detailed or advanced or able to do everything. Let people choose the colors on that page, and then click “Generate Style” which outputs a CSS page on the pre-existing Style page which they can then apply.

Most of the hours of work in theming Discourse are “replace #fff with #333, replace link colors with orange, replace #333/other dark with #ccc/other light”. Having a simple styling CSS generator would get us 80% of the way there, and then we would be able to just fine-tune the colors of things.

(this text belongs to @DanYouhon but I really wanted it here for discussion and could not wait, sorry Dan!)

16 Likes
2

Yep! I agree - it’s a solid idea and will cut a bunch of time out of the average customization.

I’ve mentioned it a few times on meta before, but I’m planning on collecting color values into SCSS variables, so it would be really easy to create a front-end interface to change a handful of values that would apply sitewide.

I’ve already started some work on it by going through all the CSS and choosing a set of consistent colors (for example, there’s no reason a #333 grey and a #222 grey need to exist - it should be one or the other)… and I just need to plug everything into consistent variables and clean out some remnants from the old theme.

Basically going from this:

Screenshot 2014-01-31 19.23.29.png616×1178 12.6 KB

to this (though this doesn’t include the green/yellow):

Screenshot 2014-01-31 19.19.13.png686×560 6.13 KB

Right now I’m working on matching Discourse.org’s blog to the rest of the new site design, but once that is done (this weekend is the plan). I’m going to get the styles cleaned up ASAP. Likely by the end of next weekend.

16 Likes
3

@awesomerobot, you’re my hero.

4

6 Likes
5

Hah, well keep in mind I’m also the reason things are slightly messy at the moment!

With this new theme I’ve been styling on-the-fly for the past 5 months or so… so I get busy fixing things (or with my day job) and don’t always have the time to go back and make sure everything is consistent. Luckily things have settled down a bit on that front, so I can go back and fine tune everything. Hopefully after I get the styles a bit more consistent I can do some revisiting with how things work with mobile too.

2 Likes
6

This would make me insanely happy!

7

Sounds geat! Basically like this right?

@awesomerobot that would be incredibly useful.

Maybe someone could also write a plugin for a simple “color overload checker” akin to colorcombos.com (that’s Meta’s colors as of today) that could tell you a little bit about your current “color standing” and help fix it if you went off the deep end already.

8

This suggestion came up after I spent a few hours restyling our forums into a dark theme. It was mostly painless - if I didn’t have Google Chrome’s “Inspect Element” CSS view it’d have taken me much much longer. I think something like this CSS generator would be pretty straightforward for you guys to implement, but would have saved me 3+ hours, and also would have allowed someone without web development background at my office to do 80% of it.

Thank you for the in-browser CSS editor and “preview” option. This was invaluable. I was able to edit and develop the style completely privately, able to move around the forum and check out different pages all in “preview” mode. NICE.

Great! When styling our forums I ran into a number of strange “#fefefe” slightly off-color-but-still-basically-the-same-color choices, cleaning that up would help a lot. Also, if it were at all possible to stick to one convention (lots of use of “color:white;”, mixed with everything else being “color:#XXX”). If we have an easier styling system like the proposed one here it wouldn’t matter as much, but it’d be one easier thing to find & replace.

One place where we would need “off-color” combinations is for link/active/hover/visited states.

One main oddity for me was that if you change the background color of the page to be any color but white, you’ll notice that in the topics list, half of the rows are the background color, while half are off-white. I was assuming while working on it that the half that are white would be specified as white instead of just defaulting to background, so that someone could change the background color on the sidebars without affecting the topic list whiteness.

To make our topic list dark I had to do the following:

#topic-list {
    background-color: #333;
}

#topic-list > tbody > tr:nth-child(even) {
    background-color: #363636;
}

TL;DR for last paragraph and a half: It’d be great for #topic-list to have background-color:#fff by default.

Another surprising thing to me was that I spent time re-styling the reply/post topic window that I’m typing into now, but then when I went to the Profile page and it had an in-line text editor of the same type, it was unaffected. Maybe I missed where they had common formatting, but being able to edit CSS classes that affect all text editor functions while retaining the ability to customize per-text editor would be great.

7 Likes
9

Oh, and please incorporate this somehow:

Simply put: “Smarter defaults for colors on the web.”

3 Likes
10

Excellent plan! But I’d like to see it go a step further, such as being able to easy switch/revert between themes. I, for example, prefer the older Discourse theme (rounded elements vs boxy), and that’s what I plan on using. I had trouble finding it in Github, so I found someone else’s instance and nabbed the code from there. Not ideal or convenient, but worked none-the-less :smile:

11

Just an update on this - the SCSS still needs some work, but I made progress this weekend. I simplified everything down to less than a dozen colors, and I took a first pass on making sure that all the colors application-wide are defined by variables.

The part that still needs work is my variable naming conventions. Right now I attempted to over-simplify things.

So I defined variables like:

$primary: #333; //black

then I took those variables and put them into modifyers

$primary_light: lighten($primary, 50%) //gray
$primary_medium: lighten($primary, 35%) //dark gray

and then used those to define colors through other variables:

$topic-list-border-color: $primary_light

The basic idea was that you could replace $primary and then it’d cascade down and replace $primary_light and $primary_medium and further cascade down to redefine the specific element variables like $topic-list-border-color.

It somewhat made sense logically when i set out to reorganize everything, but in practice it’s not really effective to be so broad on the color replacement. If I changed to $primary: #FF0000 for example, you just get a bunch of wonky shades of red because red is too fundamentally different from #333 to just replace it from the foundation - you just can’t modify it with lighten and darken the same way you would with #333 and get a desirable outcome (duh, logic failure on my end).

So instead, I’m going to just have two levels of variables:

$red: #FF0000

and then I’ll plug those in to element specific variables like

$base-link-color: $red

and then the template files will simply be color: $base-link-color

So ultimately on our backend editor I’m envisioning you’d be redefining variables like $base-link-color. Nice and simple.

8 Likes
12

Another update for those who are following along:

I’ve changed the variables so there’s a simple default list of colors, which fall into a core set of common variables (here are text colors, for example):

$primary_text_color: $black;
$secondary_text_color: lighten($black, 50%);
$tertiary_text_color: $white;
$warning_text_color: $red;
$success_text_color: $green;
$emphasis_text_color: $blue;
$highlight_text_color: $yellow;

The same schema is followed for border colors, background colors, shadow colors, etc…

These are generally semantic in that there’s no variable that a user will be redefining with a pre-defined physical descriptor… so there’s no $light_text_color or $red_text variable… which prevents weird nonsense like $light_text_color: black; or $red_text: green; from ever happening. That stuff gets confusing.

I still need to make another pass through everything just to make sure everything is somewhat logical and consistent. But it’s another step closer to something that’s really easy to theme overall.

11 Likes
13

If you can write a (short) tutorial on how this can be used we could help test this.

1 Like
14

I cannot wait.

Good idea.

15

We should allow people to plug this stuff in using site customisation. Will have a think about how to do it.

1 Like
16

How about adding another ‘type’ of stylesheet which is just a bunch of color pickers, instead of a text box?

I made a mock by copying the category color chooser over:

Pasted image885×484 16 KB

Obviously you wouldn’t want to use those colors for text, but I hope you get what the idea was.

3 Likes
17

I think that makes sense… though I hate hate hate all those redundant color boxes… would be nice to have a more robust color picker

Screenshot-2014-02-25-17.08.53.jpg658×544 34.2 KB

8 Likes
18

Yeah, that was my intention… the only real way the variables are useful at the moment is if someone edits the core SCSS (obviously not a good idea) because I believe everything gets compiled and then the customizations get added? Variable redefinitions would have to come before… are there any major hurdles with that?

2 Likes
19

What’s the current outlook on this feature?

I see there is a PR open on the inbound topic linked above from @radq. And then what comes next?

Basically, I’m trying to determine whether to put in any effort now on theming our discourse install, or just wait some of these improvements. I’m leaning toward the latter but it depends a bit how much work you guys think is left to do here, and when its likely to get done given the current priorities and sprint towards 1.0…

1 Like
20

It is on my list of things that need to be done before V1.0 releases.

3 Likes