Web Typesetting Basics

Web Typesetting Basics

A list of some good, basic, easy to implement practices.

Web Typesetting


  • Set body copy first, and make sure you set it relative to REM (so we can make other measures on our site relative too).
  • Acceptable sizes for body copy range from 12-21px. When in doubt, use 16px.
  • Pick a scale, and let that set the sizes for your headings.
  • Enforce line lengths of 75 characters, max. 45 is a good character count
  • Line heights for body copy will range between 1.2 and 1.55, if using acceptable line lengths.
  • on larger screens and for larger type (19-22px), line heights between 1.6-2 become useful.
  • The longer the line length, the taller the line height
  • Use the regular variation and regular weight of a font for body copy, unless there’s a compelling reason not to.


  • Establish distinct, clear, and consistent anchor styles
  • Unless there’s a compelling reason not to, design for your body copy to be dark gray as the base color.  If you want to use completely black text, try using an off-white background.
  • Avoid using light text on a dark background for body copy (though this is just fine for buttons, calls to action, and navigation elements where there’s less to compete with)
  • Always check to see that your color choices are WCAG compliant (AA is a 4.5:1 ratio).


  • Make sure there’s enough variation between your heading styles that a user can tell what is an H1, an h2, etc. at a glance
  • Reserve H1’s for page titles
  • Header sizes can get quite large but most H1s range from 30px to 72px.
  • Line heights for headers generally range from 1 to 1.4 – the bigger the Heading size, the smaller the line-height.
  • As screens get smaller, both the size of the headings and the line heights ought to shrink.


  • use the equation of (element size * line-height) + margin = multiple to establish a baseline grid height
  • When every element that you’d use in an article has a multiple that is divisible by the baseline grid height, you should have vertical rhythm for the majority of your content.


  • Keep your font kits to 5 total variations or less, or 100kb or less.
  • Use web fonts to ensure a consistent, attractive and meaningful design effect.
  • Even if you use a “system font” instead of web fonts, set type with care and be aware your design may vary from device, browser, and operating system.
  • Consider using a font loading strategy, and when I say to consider, I mean, implement a font loading strategy.
  • Use a fallback font. You don’t need to go overboard here, 2-3 fonts, max.

Complex WordPress IA part 3: WordPress Parent – Child Pages

This is part 3 of a 3 part series looking at how to achieve less straight forward relationships between data on WordPress.  Read Part 1 and Part 2 here.

For our last part we’re going to extend something that WordPress does have, namely, hierarchical pages.

In this example, we’ve got a Parent Page and each Parent has multiple Child Pages.  We want to do two things; first, use WP Query to display the children on the parent page, and when we’re on a child page,  to show a menu of the Child’s sibling pages (that is, other pages with the same parent).

List Child Pages

Before we actually write our query, we need to tell WordPress to use this page’s unique ID in order to only show this Parent’s children. We could just get the integer, but we’re going to create a variable so we can use this for other parent pages with out manually updating our code for each id.  This is also really important when you’re thinking about developing locally and pushing your changes up to a development environment (and from there, a production site).  Fortunately, this is really simple. The WordPress function get_the_id gets the ID, and we’ll store it in a variable $postid.

The next step should look familiar to you by now. In to our $args variable, we’re going to pass these options: 'post_type' => 'page', and 'post_parent' => $postid.  We pass args in to a new query like so: $query = new WP_Query( $args ); and then we’ll pass our $query in to the WordPress Loop, like so: if ( $query->have_posts() ) : while( $query->have_posts() ) : $query->the_post(); .

Don’t forget to close your loop with endwhile and endif,  and if you have other loops you need to account for, wp_reset_postdata never hurts. Inside your loop, write any markup that pleases you. Generally for this purpose, I prefer to use an unordered list and list items.  That’ll do for your parent template.

Sibling menu

But once we’re on a child page, it’s not a bad idea to show a user what else is on this heterarchical level. On the child template (or wrapped in a conditional on what ever template you plan on using for children), let’s define our $children variable.

We’ll use the WordPress function wp_list_pages and set the child_of option to post->post_parent.  When you’re done setting the rest of the options the way you’d like, we’ll pass that variable to echo in a separate unordered list.  Simple, right?  Here’s the full code:

if ($post->post_parent) { $children = wp_list_pages( array( 'title_li' => '', 'child_of' => $post >post_parent, 'echo' => 0, ));} else { $children = wp_list_pages( array( 'title_li' => '', 'child_of' => $post >ID, 'echo' => 0, ) ); }if($children) : ?><ul class="nav-list"><?php echo $children;?></ul><?php endif;?>

Styling the Sibling Menu

We’re going to base our styling around this responsive pattern. Although it has a small javascript dependency, it allows to keep our menu present in the flow of the content and allows a user to use the native tools on their smartphone.  For screens over your typical mobile device, we’ll just situate it inside of our container as a list like other navigation. Easy and robust!


Information Architecture is just making sense of your mess.  It’s a subtle craft and on good sites and applications, a user will never see the IA at work.  Unfortunately for you and me as Front End Designers, we have to understand the intent of the IA, be aware of the limitations of the platforms we use, and discern the best methods of building out the site based on both. Now, at least, you’re armed with a tool kit to tackle more complex information structures in WordPress.