community

Thinking of customizing your community's design? When mapping out a CSS strategy, you want to make choices that are broadly appealing and welcome the largest possible range of editors and readers. Here are a few best practices that will help.

Before you start, please also read our article Customization policy.

Guidelines

Start with the theme designer

The simplest way to customize your community is to use Fandom's theme designer. It lets you easily change your site's base color palette, wordmark, favicon and background. Anything that can be changed with theme designer should be changed with it. So start there before moving on to CSS.

Colors

Avoid low-contrast, clashing or lurid colors — especially in the content area. You want people to be able to easily read your articles so that they'll stick around longer. You can use websites such as the WCAG Contrast Checker to check whether you're using a good contrast.

Start with the before writing any CSS.

Start with the theme designer before writing any CSS.

Respect users' choice of light or dark themes. You can limit your styles to a specific theme by prepending them with body[data-theme="dark"] or body[data-theme="light"] for dark or light theme, respectively. The colors set in Theme Designer are also set as helpful CSS variables that you can use for simpler theme awareness in your design: 

/* This style will only apply if the user is using light theme */
body[data-theme="light"] .example { color: black; }

/* This style will only apply if the user is using dark theme */
body[data-theme="dark"] .example { color: white; }

/* This style will automatically use the value set for var(--theme-page-background-color) on each theme */
.example { background: var(--theme-page-background-color); }

Remember:

Fonts

Keep it simple

CSS offers you a cornucopia of possible effects to make a site really stand out. But you should not overdo it. The goal of CSS is to make the community broadly appealing, and too flashy design may be turning off new readers.

Responsive design

Fandom pages have fluid widths. That means they change a bit according to the size of the browser window. Make sure your design fully works by varying the width of your browser during testing. If you can, test your design on an actual tablet, as well.

Write readable code

Write code that can be read and understood easily. Since your CSS will almost certainly be read by others at some point:

Naming classes

Custom classes should preferably be given descriptive and consistent names, so that it's easy to e.g. associate a class in the CSS file with the template which uses the class, or vice versa.

It is also highly recommended to give every class created for the wiki a prefix associated with the wiki (e.g. "filk-" on the Filk Discography wiki). This is because all classes are global, and the classes used in the default skin and MediaWiki engine use names such as notice or toc. By using the prefix you signal that the class is declared on the local wiki, but you also make sure that you don't accidentally use a pre-defined class name.

Performance considerations

Images and fonts which are used through CSS are often used very frequently or widely. That can make even minor performance gains very noticable, and this is especially apparent when self-hosting such files (as opposed to e.g. load fonts through Google Fonts). There are fundamentally three different syntaxes to specify an URL in CSS to a file that lives on a wiki:

src:url('/wiki/Special:Redirect/file/NAME OF FILE')
This method is easy to maintain, but may cause the file to not be properly cached by the web browser since the web browser will be redirected to the actual file. For one-off files the redirect is likely not significant, but for font files or commonly used images, this might introduce noticable delays in rendering since the file cannot be cached. Recommended for files used on one page
src:url('/wiki/Special:FilePath/NAME OF FILE')
This method first causes a redirect to the above syntax, and then a second redirect to the actual file. It is thus not recommended. Not recommended
src:url('https://static.wikia.nocookie.net/NAMEOFWIKI/images/X/XY/NAME_OF_FILE')
This method requires the lookup of the raw URL where the file is stored, which can be found using the file link on the file page. It is thus far more labor intensive to find and is harder to maintain. However, it allows for caching by the web browser, and will thus reduce network loads and increase rendering speeds. Recommended for files used on many pages

In addition, it's important to keep in mind that adding different @import rules is affecting the page performance. A best practice is always having everything in one single page, and only importing this one.

Useful links

Further help and feedback