Typekit accepts work by contributing writers on the topics of typography, type design, designing for the web, CSS tips and tricks, and more. We wholeheartedly agree with the principle that ninety-five percent of web design is typography.

Where appropriate, contributors are encouraged to feature fonts available with Typekit. Experiments in web typography — showcasing how far we’ve come with web fonts, and what is possible with today’s technology — are especially welcome. Likewise, if you’ve made a tool that makes designing with type easier (such as Lettering.js), we’d love to hear all about it.

We don’t publish anything that’s already been published elsewhere.

Submissions may be sent to the editorial team at  support@typekit.com, and may take the form of short proposals or complete articles. Please submit articles as either rich text or HTML files, and review the style guide below before submitting.

If your article is accepted, Typekit will pay $250 after publication.

Voice and tone

The tone of the Typekit blog is informal and conversational, while also being clear and concise. Excessive slang or pop culture references are not appropriate, but neither is academic or stuffy language. Be yourself.

Be clear and concise

Articles should be short and need to get to the point quickly. Clearly state what you are going to discuss, and then address it precisely and efficiently.

Put readers first

Our audience includes designers and developers with a range of typographic skills, from beginners to experts; most are knowledgeable of web standards and interested in improving their craft. Articles should address them respectfully, neither dumbing things down nor assuming they are familiar with every possible prior art.

Show your methods

Our readers are interested in how things are done, and better ways to do them. Allow readers a peek at your process; include relevant code where appropriate.

Images

Images should be 800px wide and be saved in GIF, PNG, or JPG format. Image captions are optional, but should be consistently applied: either all of the images in an article should have captions, or none of them should.

Images should not have borders applied; screenshots should be submitted without drop shadows or browser chrome (unless the latter provides critical information, such as demonstrating a technique in a desktop — versus mobile — browser).

Images should include alt text that clearly describes the content of the image for those who are unable to see it.

Contributor bios and photos

Unless otherwise requested, the contributor’s Twitter avatar will be used, and the name will be linked to his or her Twitter account. Bios should be very short. Examples:

Jay Fanelli and Nathan Peretic are the co-founders of Full Stop, a web design and development shop in the City of Champions: Pittsburgh, Pennsylvania. They blog at http://www.fullstopinteractive.com/blog.

Frank Chimero designs and draws, writes and thinks. He makes pictures about words and words about pictures. He is working on a book entitled The Shape of Design.

Titles and headlines

Both article titles and headlines should be set in sentence case: only the first word and proper names should be capitalized. For example: “Navigation that stays with you” or “Diving into the markup.” Both titles and headlines take the serial comma and use “and” in place of an ampersand. Neither take terminal punctuation, unless the heading takes the form of a question, in which case a question mark may be used.

Both h2 and h3 level headings are permitted, but aim for only h2’s if possible. Headings should be short and snappy.

Code

Blocks of code should be wrapped with

 with a class of “code-block” applied. For example:

try {
   Typekit.load({
     loading: function() {
       // Javascript to execute when fonts start loading
     },
   })
 } catch(e) {}


An opening curly brace should be on the same line as the selector or command, while a closing brace should be set on its own line. Subsequent lines should be indented with two spaces each (no tabs, please). 
Groups of CSS selectors (separated by commas) should each be on their own line with no indentation. E.g.:
p,
blockquote {
  color: #333;
  font-style: normal;
}


There should be no space between the property and colon, one space between colon and value, and no spaces between value and semicolon.
Inline code should be wrapped with , like so:

Let’s look at the styles used to make the blockquote.
Punctuation and details
In general, we follow the Chicago Manual of Style. Exceptions and additions to Chicago are noted below. 
Em and en dashes
Em dashes are used to indicate a break in thought and should be set off with a space on either side — like so. This permits lines to break more evenly on the web. Do not substitute two hyphens for an em dash.
Use an en dash (without spaces) for numbered ranges, such as 12–14. 
Ellipses
Ellipses are used within quotations to indicate that some text has been omitted; they can also be used to indicate a pause, but do so sparingly. Often, an em dash will do instead. 
Capitalization, hyphens, and compound words
The words “internet” and “web” are not capitalized, unless they appear at the start of a sentence. The words “email,” “ecommerce,” and “ebook” do not take the hyphen. The words “web fonts” are always written separately, sans hyphen (never “webfonts” or “web-fonts”).
Company name
Typekit is spelled as shown here, without an intra-cap, space, or hyphen. Typekit should always be capitalized. 
Links
Compose link text that clearly indicates what the text is linking to, and keep it brief. Do not link terminal punctuation. Font names should be linked to the relevant page on Typekit (if applicable) or Typedia. Links should never be set to open in a new window.