PFQ Banner

This is PokéFarm Q, a free online Pokémon collectables game.

Already a user? New to PFQ?

Legibility / Template Rules

Forum Index > PokéFarm > Guides >

Cele's AvatarCele
Cele's Avatar

Legibility / Template Rules

Last edited: 25 Jul 2022

The Rules

Rule 7: Legibility

PokéFarm allows players to modify their About Mes, forum posts, and forum signatures through the use of both BBCode and CSS. Any changes made to background colour, font colour, font type, or font size may not result in content that is unreadable, or difficult/painful to read. "Difficult to read" is subjective; if in doubt, report it for review by the Moderator Team.
Please keep in mind that text in an image must also be readable and thus follow the legibility rules on colour and sizing as well. If an artist's signature or watermark is not legible in the image, however, you may write a text version of the credits and that is fine.

Intro & Checklist

This thread is an in-depth review of what template legibility is, why it is important, and the Moderator Team's stance on what is and isn't okay. Here's a quick checklist of what you should be checking your template for in order to ensure good legibility:

Template Checklist

  1. Background colour
  2. Text colour
  3. Link colour
  4. A minimum colour contrast of 4.5:1
    • Anything over 4.5:1 but under 7:1 is still subject to Moderator discretion - 4.5:1 is just the bare minimum.
    • Any colour use that results in pain or discomfort to look at should be avoided. This is up to Moderator discretion.
  5. Text size is at least 10pt, but no more than 15pt
    • Don't use px for text sizes.
    • This also applies to all art and coding credits.
  6. Displays well in both full width and mobile width
  7. Does not have multiple "modes," such as changing based on time or the user's light or dark theme settings
    • This makes moderating for legibility multiple times more complex.
  8. Does not use a custom mouse cursor unless it is a private site skin
    • Custom mouse cursors may not be used elsewhere.
  9. Any and all extra elements have been properly defined
  10. All art in use is credited properly
    • The art crediting rules are here.
    • You must have permission to use any art, images, or code that you didn't make yourself.
    • If you did make it yourself, credit it anyway. Other people don't know you made it unless you tell them.

Defining Colours

Defining colours properly is perhaps the most important part of making a template. Your colour choices must result in completely and easily visible text to the person reading it regardless of what kind of site skin they are using. In most cases, having everything defined means you have a background colour, text colour, and link colour. Having accordions, display/hide boxes, tabbed layouts, pkmnpanels, etc. in your template mean that additional colour definitions will be required, but more on that later. Here is the code for a very basic defined template. .box1 { background-color: white; color: black; } a, a:visited { color: blue; }
You can see a new set of background, text, and link colours.

Keep in mind that some colour combinations are more readable than others. It is for this reason that we require a minimum contrast ratio of 4.5:1, which you can determine with the tool provided here. On the topic of hard to read colours, please avoid using colours that have maximum saturation. Notably bad examples of maximum saturation colours that can cause eye strain are red, cyan, and neon green.


Having red as a background colour with black text does have a contrast ratio of 5.25:1, but it can cause significant eye strain.


Cyan meets the standards with a contrast ratio of 16.74:1 when paired with black text, but it's a similarly strong colour that can easily hurt the reader's eyes.

Neon Green

Neon green carries many of the same issues, giving what we call an "eye-burning" effect. This has a 15.3:1 contrast ratio, but it is still painful to look at.
This is not a comprehensive list of "eye-burning" colours that can cause eye strain, so please use your discretion when choosing a background colour or ask a Moderator if it is okay. Additionally, if you have other elements such as tables, hide/display boxes, accordions, pkmnpanels, progress bars, or hover tips, then those need to be properly defined as well. If they are left undefined, then they may take colours from the rest of your template and become hard for someone to read. For a basic code that has these elements defined, see the next post.


There is another reason why colour contrast is so important. PokéFarm is host to a number of users with vision impairments and colourblindness, so all content should be kept accessible by following these guidelines. To demonstrate what is meant, here are some simulations of what different colour combinations look like to people with different types of colourblindness.

Colourblindness simulations

Original Red-blind (Protanopia) Green-blind (Deutanopia) Blue-blind (Tritanopia)
This is a good example of why one should always aim to use light elements on top of dark elements, and dark elements on top of light elements. Speaking of accessibility, custom mouse cursors are a fun way to customize your templates and site skins but they are not accessibility friendly. At this time here are the rules on custom mouse cursors: Site Skins: You may change the cursor for your own view as it does not affect other players gameplay or accessibility. You may NOT distribute a site skin with a custom mouse cursor. Templates: You may NOT change the mouse cursor to a custom cursor in templates of any form. This includes, but is not limited to, forum post templates, forum signatures, or About Me templates. The rule on custom mouse cursors may be updated at a later date upon review.

Text Sizes and Fonts

Text size is just as important for legibility as colours are. View the contents of the hidebox in order to see a comparison of various text sizes.

Text size examples

text at the size of 8pt <-- Too small text at the size of 9pt <-- Too small text at the size of 10pt <-- OK! text at the size of 13pt <-- OK! text at the size of 15pt <-- OK! text at the size of 16pt <-- Too large text at the size of 17pt <-- Too large
For this reason, it is mandatory that all text sizes be between 10pt minimum and 15pt maximum, with leeway being given for headers. Headers should not be used to increase the size of a large body of text. Also, pt is very different from px. Do not use px for text sizes. There are a lot of appealing fonts that you may want to use in your templates, such as a fancy one like this:
It's a nice looking font! It's kind of like cursive handwriting.
Keep in mind, though, there's a reasonable expectation for legibility even in the fonts you use. If the decoration of the font makes it hard to tell which letters are which or decrease readability, then you shouldn't use that font.

Template Size

When making a template, it must be easily viewable on all devices. These devices come in different sizes, so your templates must be able to scale on any of them and remain legible. Likewise, the header (top) and the footer (bottom) of the template should not cause an excessive amount of scrolling just to reach the content. For this reason, the header and footer of a template should add up to be no more than 400px tall. The forum is built to display at different sizes across different device types, so your template may not easily be readable to someone else. As an example, some templates may be much too wide to display on mobile, and depending on how they're coded they may refuse to scale down properly.

Some templates can be too wide

I am a wide template on a narrow screen. This text is going to be cut off by the edge of the screen before it reaches the end of the template, resulting in unreadable text and a big problem for mobile players. There are a lot of mobile players, so don't assume it'll be fine!
For this reason, we discourage you from defining a width for templates on the forum and would prefer if you allow the browser to handle it instead. You may set a width for About Me templates since they are static in size. However, please be mindful that nothing gets cut off. Using a scroll bar to solve this issue is not allowed, as this type of scroll bar doesn't work on all devices and browsers. As a note, there are only two permissible uses of a scroll bar. The first is when it contains code in plain text. This is allowed to reduce the visible space taken up by code since code is generally "gibberish" to a lot of people. Here's an example of a scrollbar in use in this acceptable way:
[style] .panel { background: black; border: solid 1px white; color: white; > h3 { > a { color: white; } border: solid 1px white; background: #6E6E6E; color: white; } > div { .page; color: white; a:link, a:visited { color: #d1d1d1; } } } [/style]

The second is if and only if a table would be made more legible to mobile users by the addition of a horizontal scroll bar. A vertical scroll bar is disallowed for this purpose. Here is a table with an acceptably used horizontal scroll bar.

A Note

While it's okay to dictate that users may or may not edit your code, there is one very important thing to keep in mind: A user's disallowance for edits cannot supersede the need for edits to be made for the sake of site rule or legibility compliance. That is to say, you may not stop someone from editing your code if your code breaks the rules in any way and their edits would fix it so they don't get in trouble for using that code. These edits should be restricted to adjusting only text colours or sizes, or adding art credits, but should not be significant template-redefining changes if changes are disallowed by the template creator. In the case that significant changes would have to be made in order to fix a template from a rules perspective, it should be removed rather than edited. Likewise, if you are pushing minor fixes on a template in order to fix the legibility of it, please report the original template so that moderators can ask the creator to fix it. This is so nobody else has or gets in trouble for those issues.

Advanced Features: Template Modes

Code exists to add multiple "modes" or variations to a single template, but please note that doing so is disallowed. A template must not change according to variables such as the site's current time, the viewer's light or dark theme settings, and so on. While this being done correctly would be a creative and interesting way to express oneself, it is more often than not extremely difficult to code a single fully legible template on the first try. Even veteran coders who have made many templates sometimes miss things. I've made a number of templates myself and missed things. Going through the legibility rules and correcting those issues takes lots of time, and so does working with users in order to correct their mistakes with their templates. It is one of the most time-consuming reports for a moderator to take because we have to allow the users a chance to fix their templates themselves, corresponding back and forth to tell them whether or not there are still issues, or if new issues have come up in the changed code. For the sake of preventing undue stress to the moderation team from time investment requirements of legibility reports, this kind of template may not be used.
sig code and sig bg image made by me
Cele's AvatarCele
Cele's Avatar

Other elements and ensuring they are defined

Here is a collection of codes which have certain elements completely defined in black, white and grey for easy reference and usage. Some of these codes will have duplicated things like link colours, but I have done this because if you haven't already defined those colours, you need to for these codes.

Accordions, Stackboxes, Hide Boxes and Display boxes

As you can see by this post, these boxes have all been define with very plain colours, but defined all the same.


[style] .panel { background: black; border: solid 1px white; color: white; > h3 { > a { color: white; } border: solid 1px white; background: #6E6E6E; color: white; } > div { color: white; a:link, a:visited { color: #d1d1d1; } } } [/style]

Progress Bars

Progress Bars are great for tracking items, hunts or any number of things. Since progress bars often take their colours from the rest of the template used, if you are going to use one, make sure you have defined everything in it as well
What a nice progress bar


[style] .expbar { background: black; color: white; border: solid 1px white; > div { background: #6E6E6E; border-right: solid 1px pink; } } [/style]

Tool Tips

Tool tips are those little boxes that pop up when you hover over something, these can be tricky but once again, they often take their colours from the rest of a template and will need to be defined as well. Also be aware that a tooltip at the bottom of a signature or post may be cut off, so check your codes before posting them. Hover here.
Everything is defined and easy to read


[style] div.tooltip_content { background: black; color: white; border: solid 1px white; } .bbcode_tooltip { border-bottom: 1px dotted #6E6E6E; } [/style]


Tables are great for organisation of hunts, shop stock, or any number of other things. They generally take their text colour from the rest of the template they are used in and will need to be defined as well. Completely defined table
Header 1 Header 2 Header 3
cell 1 cell 2 cell 3
cell 4 cell 5 cell 6


[style] table { border: solid 1px white; } table th { border: solid 1px white; color: white; background: #6E6E6E; border: solid 1px white; } table td { border: solid 1px white; background: black; color: white; } [/style]

PKMN Panels

PKMN Panels are fun little display codes for your special pokemon. This code includes some duplicate codes for tooltips and link colours as they are required by the boxes themselves.
Lv. 100 — +35,168,802
Aspear BerryAspear Berry
Aspear Berry (SOUR)
Cheri BerryAspear Berry
Cheri Berry (SPICY)
Chesto BerryCheri Berry
Chesto Berry (DRY)
Pecha BerryPecha Berry
Pecha Berry (SWEET)
Rawst BerryRawst Berry
Rawst Berry (BITTER)
Spicy food
Happiness 27%
Adamant nature


[style].party > div { background: black; color: white; border: 1px solid white; box-shadow: 3px 3px 3px pink; a:link, a:visited { color: pink; } .action > .berrybuttons[data-up='sour'] > [data-berry='aspear'], .action > .berrybuttons[data-up='spicy'] > [data-berry='cheri'], .action > .berrybuttons[data-up='dry'] > [data-berry='chesto'], .action > .berrybuttons[data-up='sweet'] > [data-berry='pecha'], .action > .berrybuttons[data-up='bitter'] > [data-berry='rawst'] { background: white; } .action > .berrybuttons[data-down='sour'] > [data-berry='aspear'], .action > .berrybuttons[data-down='spicy'] > [data-berry='cheri'], .action > .berrybuttons[data-down='dry'] > [data-berry='chesto'], .action > .berrybuttons[data-down='sweet'] > [data-berry='pecha'], .action > .berrybuttons[data-down='bitter'] > [data-berry='rawst'] { background: grey; } .action a[data-berry]:after { border: 2px solid white; } .pkmn:before { border: solid #6E6E6E; background-color: white; } .expbar { border: solid 1px white; color: white; background: black; >div { background: #6E6E6E; border-right: solid 1px pink; } } div.tooltip_content { background: black; color: white; border: solid 1px white; } .bbcode_tooltip { border-bottom: 1px dotted black; } }[/style]

Wide tables

The code used to make a wide table mobile-friendly is as follows:
[style]table { display: block; width: 100%; overflow-x: auto; }[/style] It is highly recommended to use CSS Grid instead, but that is not something that this guide will go into.

Cannot post: Please log in to post

© PokéFarm 2009-2022 (Full details)Contact | Rules | Privacy | WikiGet shortlink for this page