Help:CSS best practices

Contents

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.

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.

Be careful with 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.

Background images are cool, but not if you can't read the text on top of them. So don't go crazy with theme designer's transparency slider if you have a busy background.

Try not to make font sizes too small, especially in the main text area.

Keep it simple

There may be a temptation to cover your community with icons, animations, and other decorative elements — but these can be very distracting for someone visiting the community. Remember, the goal of CSS is to make the community broadly appealing, and your flashy custom cursor 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:

annotate it with comments like /* This code does x, y and z */

give your custom classes and IDs understandable names. If it makes a box around something, consider calling it .box, not .tlk328

add in spacing and indentation to your community's tastes — but pick one format and stick with it

organize the code logically, keeping code that affects the same part of the wiki together