«
»

Demystifying Style Guides

When I mention style guides, or ask for a style guide from someone I’m about to work with, sometimes I get a confused look — like I’ve just spoken of some arcane thing. People ask to see one because until you start working with style guides, they seem like strange, otherworldly containers of knowledge. In truth, they’re just collections of rules you want to either remember for yourself, hand to an editor to make sure you’re consistent, or hand to other writers working with you or on your line.

What is a Style Guide?

A style guide is nothing more than an easy-to-reference list of rules for your publication. On the simple end, it’s how you do punctuation, capitalization, headers and body text styles, and a myriad of other decisions that you’ll want to note down so that you (a) remember them yourself and (b) can give it to someone else working with you.

They can range from a page with initial notes to multi-hundred page beasts, and in fact that’s how they grow. Style guides are living documents — at least, as long as the project or line you’re working on is alive. Style guides are constantly being revised, as new situations come up or as older rules get challenged and revised: Chicago Manual of Style is on its 16th edition, for instance. The one at my day job was I think 49 pages when I started (in September 2012), and is 60 pages at the time of this post.

Base Style Guide

To start, list your base style guides and dictionaries. I generally use the Chicago Manual of Style 16th Edition as my base style guide and Merriam-Webster.com as my base dictionary (which also specifies that I’m using American English, rather than Australian, British, Canadan), and then note either exceptions or points to underline in the guides for my projects.

Let me back up.

I use Chicago as a base because it’s suited for literary and technical writing. If what I was doing was more news-oriented, I might instead use the Associated Press style.[1] However, while I say “I use Chicago,” I have hardly memorized it. I can tell you, like, a third of the grammar styles in there. Maybe. I’m looking up stuff all the time, and that’s when I’m not sure — sometimes I am “sure,” but am also wrong. So don’t feel intimidated by having to absorb a 2500-page manual.[2]

Maybe you’ll start with what I call “Chicago-lite,” where you write down the rules you know you respect and use, like the serial comma, em-dashes without spaces around it, etc. Likely you don’t never know these are rules that people debate about and have different styles for (except for the serial comma, because that’s a heated debate for some reason), and you’re picking up styles from the books and periodicals that you like. That’s totally okay! If you get further down the publishing rabbit hole, you’ll do well to invest some time into understanding styles guides.[3]

From There

From there, I’ve found four sorts of things in style guides: rules for grammar and spelling, terms and language use, rules for formatting, and notes for layout. I will use examples from the Paizo style guide and the style guide for Mythender (though I never wrote down Mythender’s styles, apparently, if the inability to find them on my hard drive or email tells anything).

Rules for Grammar and Spelling

These sort of rules talk about either divergences from the base style guide or highlights that people need to remember.

Grammar examples: For instance, I will always remind people that the serial comma came from Heaven to save us from our sins. Even though that’s in Chicago, there are many writers who won’t bother familiarizing themselves with your base style.[4]

Spelling examples: This is mostly done as a glossary or list. At Paizo, we have in our style all of the nations in Golarion and their adjective, collective noun, name of country forms. For instance, in the Mummy’s Mask Adventure Path that’s going on right now, here are the rules for the nation of Osirion:

  • Place: Osirion
  • Noun (singular/plural): Osirian/Osirians
  • Adjective: Osirian
  • Language: Osiriani

(This also serves as our canon bible, at least to some degree.)

The variant of the spelling list is the capitalization list. Mythender Capitalized Many Things. Here are some:

  • Mythender (when as name of game, stylize; when as fictional concept, just capitalize)
  • Myth (only use this to mean a being from the Mythic World that you can punch in the face, not as a synonym for “old story.”)
  • Mythic (always, always, always)
  • Mythic World
  • Mythic Norden
  • End (as verb for killing a god in either mechanics or fiction)
  • Weapon (as the game mechanic, not the general concept)
  • Form (as the game mechanic, not the general concept)
  • Corruption (as the game mechanic, not the general concept)
  • Storm (but not the “die/dice” after Storm — “Storm dice” not “Storm Dice”)
  • Thunder (but not the “die/dice” after Thunder — “Thunder dice” not “Thunder Dice”, also do not capitalize “temporary” when prefixed)
  • Lightning (but not the “token/s” after Lightning — “Lightning token” not “Lightning Token”)
  • Might (but not the “token/s” after Might — “Might token” not “Might Token”)
  • Gift (as the game mechanic, not the general concept)

(Fun fact, I screwed up the the “die/token” rule a few times in the book. That’s because it was a much later decision, and I missed some.)

Terms and Language Use

Some of the grammar and spelling rules bleed into terms and language use, such as the Osirion and Mythender capitalization notes. I have an example directly in mind that I sent to the folks doing Mythender’s Russian translation:

I’ll have to drag from memory all of my weird quirks of language with Mythender, but the one that that I intentionally did that isn’t obvious is that I used three different verbs for “kill” that differ on context:

  • A Mythender Ends Myths.
  • A Mythender murders another Mythender.
  • A Mythender slaughters mortals.

The fourth that happens in the optional rules:

  • A Mythender culls aspects of reality.

To End something isn’t just to kill it, but to unmake it, possible erase it, or destroy it beyond hope. So these aren’t just synonyms I used to vary the language up, but intentional choices. It’s a subtle bit that I use to reinforce both the Myths’ and Mythenders’ status in the fiction.

Having a glossary of terms is useful in your style guide — glossaries show capitalization and spelling alongside context. Sometimes, that glossary even becomes part of the book, as it did with Mythender.

Rules for Formatting

At Paizo, when we have a term that follows a colon and that term is stylized (like bolded or italicized), we don’t also stylize the colon. At other places I freelance for, they do. I’m personally sliding toward not, because that’s what I do during my day job so it’s becoming second nature. You’ll see that I’m using this style on this blog post.

In Mythender, “Mythender” was in small caps when referring it it as the game’s name, and in normal title case when as the characters in the game. This was to distinguish quickly which I meant. When introducing new concepts or highlighting mechanics in the tutorial, I used an example format that was red and in small caps. Every Gift name was also in that same case.

The rules for headers, sidebars, tables, and other constructs also falls in this category. My basic ones include:

  • Acceptable headers: Chapter, header level 1, and header level 2. If I really have to, header level 3, but nothing lower. (Paizo has a no-H3 rule.)
  • There should always be some body text between one header and another. Don’t have headers run together (unless in something like a table)
  • Standard Chicago title case for headers
  • Sidebars shouldn’t be more than 350 words long, and will never flow from one to another like the old GURPS books did. (I kinda loved that about GURPS, but doesn’t mean I want to emulate that.)
  • The first paragraph after a section break isn’t indented, but the following are.

Notes for Layout

The final general thing I can think of that goes into a style guide is how to format your document for the art director. That could be what Word styles to apply to various text, any text flags for special formatting, or even to use manual styles for certain elements.

Paizo and Onyx Path have paragraph styles for headers, body copy, sidebars, and tables, but for inline styles we manually bold and italicize. Evil Hat’s process during Fate Core was to put XML-like tags around some things, such as <1>, <2>, <3> for header levels 1, 2, and 3. <aspect>This is how an aspect is tagged</aspect>, and so on.

Whatever your layout person needs, put it here. This is especially true for formatting complicated constructs like stat blocks.

How To Make Your Style Guide

Because style guides grow, it’s an iterative and ongoing process. But here’s how you start: open up a new document and write some things down that you think are important. At this stage, it’s not necessarily important to give the document structure. Then save the document. You now have a style guide!

Then, as you have to make either decisions or clarifications, open the style guide and add to it. Save it. You have an updated style guide!

If your style guide reaches five pages to so, it’s time to format it into something easy to reference. This is an opportunity to apply your styles to the guide itself; for instance, whatever header rules you proclaim in the guide should be how you actually use them in the guide.


Please feel free to comment with questions or your own style guide thoughts. Note that I can’t actually share the style guides I have with the public, as they aren’t mine to share. (I would share Mythender’s if I had actually made it. Next time, folks.)

– Ryan

[1] I am Team Chicago. My fiancée is Team AP. If we can bridge that to get married, the rest of the world can as well.

[2] Yes, two-thousand-five-hundred. Roughly.

[3] Especially if you deal with international contracts. The UK book styles I had to deal with on Achtung! Cthulhu were alien compared to my comfortable Chicago. Namely instead of em-dashes, UK standard is space-endash-space. Bizarre.

[3a] I also hate that WordPress doesn’t translate the double-dash as an em-dash except when surrounded by spaces.

[4] The other common thing I have to put in my style guide as reminders to writers: single space after periods. We live in an age of variable-width fonts, custom tracking and kerning, and other advances in text design that makes the double space an eyesore. Most publishing houses don’t use it. Flip open a book that isn’t indie-published, and tell me if you see double-spaces after periods. (If you do, pick up other books in that same category: technical manual, fiction, RPG, etc. and see if it’s consistent.)

Share
«
»

3 Responses to Demystifying Style Guides

  1. Sarah T. says:

    I love this post. I sort of already knew what a style guide was purely as used for formatting citations for reports during my academic efforts. But reading this post I realized I have one for my day job, for making maps. It includes things like which fonts to use for which types of features, which line widths and colors for roads versus rivers, what size to make the icons/boxes in the legend, how big the title should be and more and more and more…. Not nearly enough of it is written down. I am inspired to change that. :) Thanks!

  2. Jake G. says:

    Style guides are so very handy…when they make sense. At my previous job, we started with Chicago as a base, built our own on top of that, then incorporated any style guides individual customers might have had for us. Ferreting out exactly how a given document was supposed to look was a full-time job.

    I still cringe at the customer who wanted double dashes for everything. Parenthetical aside? Double dash! Repeated stuttering? Double dash! Quotes? You better believe we’re double dashing that, don’t even include quotation marks. And it was a Courier New document, so em-dashes were just de jure wrong.

    • Ryan Macklin says:

      The double-dash is atrocious, but the em-dash is my sin. I even have to cap myself on em-dashes per page and per paragraph.

      – Ryan