Website Color Theming

Community
1

I've mentioned that my concept of being "showy" for Rebol is to try and really make it about the code, and to stick to a near-typewriter aesthetic. Here's a suggested starting theme modification for code samples:

pre .str, code .str { color: #000000; } /* string  - black */
pre .kwd, code .kwd { color: #000000; } /* keyword - black */
pre .typ, code .typ { color: #000000; } /* type - black */
pre .lit, code .lit { color: #000000; } /* literal - black */
pre .pun, code .pun { color: #000000; } /* punctuation - black */
pre .pln, code .pln { color: #000000; } /* plaintext - black */
pre .tag, code .tag { color: #000000; } /* html/xml tag - black */
pre .atn, code .atn { color: #000000; } /* html/xml attribute name - black */
pre .atv, code .atv { color: #000000; } /* html/xml attribute value - black */
pre .dec, code .dec {
    font-weight: bold; color: #000000; /* dec (declaration?) - black and bold */
}
pre .com, code .com {
    color: #707080; font-style: italic; /* comment - gray ok if still dark */
}

pre.prettyprint, code.prettyprint {
	background-color: #FFFEFE; /* white or real close to white */
	-moz-border-radius: 8px;
	-webkit-border-radius: 8px;
	-o-border-radius: 8px;
	-ms-border-radius: 8px;
	-khtml-border-radius: 8px;
	border-radius: 8px;
}

I've mentioned some of the reasons why I believe this is the way to go--beyond my personal dislike of making one's code look like it has circus colors:

  • In a language with no keywords, colorizing "keywords" does not make sense.

  • Sticking to black and white helps show off the work done to try and reduce visual noise. That message gets lost when you add...visual noise.

  • The stated goal of the language is to be readable and editable without an IDE--and be pleasant to look at and work with in that state. I think other principles (like sticking to 80 columns, however "archaic" that may sound) is a good guideline as well.

  • Matches the logo and the theme, lets color be used more strategically elsewhere on the site vs becoming something you have to "tune out".

The one most critical thing to highlight, IMO, is the bolding of the SET-WORD!s and SET-PATH!s to further call them out...separating definitions and references. I think that comments being a slightly-less-dark-shade, and maybe even italic, could be all right.

If this is generally accepted as the idea for the base theme (perhaps permitting a browser cookie or something to change themes if later ones are invented) then I think that helps when answering broad structure questions about contrast on the rest of the site, how to get balance of black and white regions, etc.

1 Like
2

I have made these updates to the theme now, so you can see what that looks like.

1 Like
3

Great! I think it looks much better already.

Note that the change to and+ has been made, so the operations are and+, or+, xor+.

We should make a topic to discuss code samples at some point (probably premature, should let the rest of the site settle first). I think one important aspect of the samples is that they shouldn't bring in any new elements up front that will trigger old-timers to fear there is "change for the sake of change". So if we can just avoid foreach and for-each in the front page examples, as well as and+ and or+, and only focus on big/cool totally new things, that would probably be ideal.