SPF Table Formatting Guide
Contents
1. Introduction
2. Glossary
3. Background information
3.1 Sizes of text boxes
3.2 Stages of a post
3.3 Behaviour of some tags
3.4 Rich tags
4. Common Problems3.2 Stages of a post
3.3 Behaviour of some tags
3.4 Rich tags
4.1 Font is not monospaced
4.2 Text is not aligned / Text is jagged
4.3 Text wrapping
4.4 Tags inside a table break alignment
5. Solutions4.2 Text is not aligned / Text is jagged
4.3 Text wrapping
4.4 Tags inside a table break alignment
5.1 Using a monospaced font
5.2 Aligining text
5.3 Text wrapping
5.4 Tags inside tables
6. General Best Practice5.2 Aligining text
5.3 Text wrapping
5.4 Tags inside tables
6.1 Table headers
6.2 Splitting tables
6.3 Table standards
6.4 Table width
6.5 Field data types
7. Templates6.2 Splitting tables
6.3 Table standards
6.4 Table width
6.5 Field data types
7.1 Tournaments
7.2 Grail
8. Summary7.2 Grail
1. Introduction
A common issue, on the SPF, is that users find it difficult to work with the various tables we have on the forum. The aim of this guide is to provide some helpful templates along with tips, tricks and background information so that the integrity of tables is maintained from post to post.
2. Glossary
For clarity, I've included a glossary of terms that are either global standard names for well-known things or terms I've created to refer to parts of the forum.
Monospaced font
A font where each letter/character is the same width.
Proportional font
A font with variable letter/character widths (letters like 't' and 'i' are much narrower than 'w' and 'm').
Message Editor
The various text boxes that you type into to make a post.
Quick Reply box (978 pixels wide)
The text box at the bottom of each thread and is the widest text box on the forum (part of the MessageEditor class).
Long Reply box (738 pixels wide)
The text box you get when click 'More Options' on the Quick Reply box or when you create a new thread and is narrower than the Quick Reply box (also part of the MessageEditor class).
Edit Post box (648 pixels wide)
The floating text box that appears when you edit a post, this is quite narrow and causing word wrapping (also part of the MessageEditor class).
BB Code Editor
This has a pale yellow background and offers limited options. Altough we will want to use BB codes, we can actually use them in the Rich Text Editor.
Rich Text Editor
The option in your preferences that provides more options when creating and editing posts (a much better experience in my opinion, there's no good reason not to use it!).
Here is the setting in preferences:
Tags
This forum uses BB Codes which are similar to HTML tags and enable users to format their posts or use spoiler tags etc. Whenever you bold some text, that is actually a tag at work.
Fields
Another name for column headers.
3. Background information
3.1 Sizes of text boxes
Click here for a screenshot showing the relative sizes of the various text boxes.
3.2 Stages of a post
To understand this thread better, we need to know what 'stage' a post is in:
- Creation - this when you use either of the Quick Reply or Long Reply boxes.
- Editing - only you or a mod/admin can edit your post.
- Quoting - be aware that quoting can be lossy with respect to other tags within specific tags.
- Posting - once a post is submitted, it is visible to everyone and any tags are applied.
This next part is a bit tricky to wrap your head around:
We are mostly interested in maintaining integrity of quoted tables. Certain tags may still be visible to you if you edit your post that already had them in, but that same post, when quoted, may lose tag information on content that was wrapped in the bog standard [CODE]...[/CODE] tags. We're going to focus on the effect tags have on quoting and ignore the fact that sometimes you can see more information in your own edited post.
When you make a post with the normal [CODE]...[/CODE] tags, the content inside the tag on the final post is displayed as a monospaced font called Courier New. However, when that post is quoted, it reverts to the default forum font, size and weight in the Message Editor window. This distinction between what is displayed and what is inside the Message Editor is important for later. You can see this in effect by trying it yourself, when you quote a table and try to edit it, the text doesn't actually appear as Courier New in the Message Editor, instead, it is the forum default.
Additionally, during the Posting process, [CODE]...[/CODE] tags actually strips away things like colours, hyperlinks and other formatting tags from the content inside the tags, which means all that information is lost for anyone who subsequently quotes your post. Which leads us neatly onto...
3.4 Rich tags
Rich tags allow Rich Text Editing and [CODE=Rich]...[/CODE] tags respect other tags that are nested inside them, like different fonts, colours and hyperlinks. This is the main tag we will use to make our tables easier to quote and maintain. We'll see more examples of this throughout the rest of the thread.
4. Common Problems
There are various reasons that users experience problems with tables, I've tried to capture them all below, so that they can find this thread.
4.1 Font is not monospaced
This is the problem people have, without even realising it is a problem and it is often the underlying source of some of the other common problems, particularly alignment.
4.2 Text is not aligned / Text is jagged
Depending on the data type present in each of the different fields (text, numerical & date) certain fields have variable-width content, like character names and this makes it difficult to tell which column the data is in.
4.3 Text wrapping
A single row in the table may wrap around to 2 rows and this problem is exacerbated by the variable widths of the text boxes.
4.4 Tags inside a table break alignment
Sometimes, we want to use tags inside a table but this pushes the content all over the place.
5. Solutions
[CODE=Rich]...[/CODE] tags to the rescue, almost all of the problems are easily solved with the strategic use of these tags. Better still, these changes are carried over when quoting, so everyone else can benefit.
5.1 Using a monospaced font
If we wrap our table in a monospaced font, like so [FONT=Courier New][CODE=Rich]...[/CODE][/FONT], the tables also respect the monospaced font.
5.2 Aligining text
Using the monospaced font from section 5.1, we also resolve our alignment issues. We can now easily spot which column our data is in and alter the spacing accordingly, all from the comfort of the edit window.
5.3 Text wrapping
Unfortunately, monospaced fonts may increase text wrapping in the narrower Mesasage Editor boxes. My recommendation is to try to accomplish as much as possible in the Quick Reply box.
5.4 Tags inside tables
I recommend limiting tags inside table to only hyperlinks in the 'Hall of Fame' type tables. Please note that some combinations of tags do cause weird spaces to appear, so less is more.
6. General Best Practice
6.1 Table headers
I've listed a bunch of fields/column headers that ought to be in almost every table:
Forumite
This is less ambiguous than 'Player' which is used for the /players command and 'Name' which could be misconstrued as the name of the character.
Character
Again, here 'Name' is a bit vague, whereas 'Character' is in keeping with already established conventions.
Class
Useful to include, especially if the build is not included in the table.
Build
SC/HC
Option of using a column or some symbols like:
* = Untwinked
† = Hardcore
Level
Experience
This one is only important when people are running for level 99
Date
I'm a strong advocate for the 'Date' column because it enables us to review when the table was last updated for all characters/forumites and allows us to tidy up old inactive records. We can also track when achievements were made. The international date format defined by ISO, YYYY-MM-DD, is the best format to use as it is unambiguous since we have forumites from lots of different countries.
Patch/Version
This is mostly for aggregate stuff like the various Grails and often includes your FAM status
E/S
This stands for Extended Stash and only requires a 'Yes'/'No' or 'Y'/'N' response.
6.2 Splitting tables
It is often beneficial to split tables for certain tournaments, because some people will play hardcore and die, so we will want to remember them but not clutter up the active tables. People will also join and then abandon characters and tournaments, so we need an inactive table so we again, remove clutter but retain the data for future use. We'll also want to properly celebrate the winners and so we'll want to give these prominence. Therefore, splitting tables based on the 4 main states...:
- Winners
- Active
- Inactive
- Dead
6.3 Table standards
Headers
You'll want to separate your table headers from the content of the table itself. Most people use hyphens ('------') or equal signs ('=====') to pseudo-underline their headers. This can be an unbroken line or it can be as wide as the column with at least 2 clear spaces between adjacent columns for readability.
I try not to truncate forum names, but we can shorten header names. So use 'Exp' and not 'Experience' or use 'Lvl' and not 'Level' or use the following abbreivated Class names:
Code:
Class Variable 3 Letters
----------- -------- ---------
Amazon Ama Ama
Assassin Sin Sin
Barbarian Barb Bar
Druid Druid Dru
Necromancer Necro Nec
Paladin Pala Pal
Sorceress Sorc SorBlanks
For any blank fields, it's helpful to include a single hyphen ('-') so that it's clear that something could go there, but it is currently empty.
Unknown
Different to 'Blank', unknown is where something has happened but the exact value is not known. I use a question mark ('?') symbol.
Table Title
Its best to give your table a title wrapped in highlight tags like so: [HIGHLIGHT]Title[/HIGHLIGHT].
Text Alignment
Text should be aligned to the left, while numerical data should can be aligned to the left, right or even centre depending on the nature of the data (fixed width data like dates can be left aligned, while anything numerical >100 can be right aligned)
6.4 Table width
The Quick Reply box is the same width as the final post, so if the text for a single row is being wrapped, your table is probably too wide. .
6.5 Field data types
You want the data in each field to be consistent, so I generally advise against putting free text in a field where people are expecting a number or a fixed width response like 'Y/N'. People often put things like 'I don't wanna know' or 'Too many to count' or 'Lots' which are obviously many more characters than the table was set up for and can just add to the maintenance of tables and general alignment woes.
That's it for the wall of text, the next post will contain template tables that you can use!
Last edited:
