Back to Basics With WordPress CSS: Understanding the Native Classes

Avatar of Chris Coyier
Chris Coyier on (Updated on )

The following is a guest post by Karol K. Karol is writing on behalf of ThemeIsle.com, a WordPress theme seller. He pitched me this post and I was into the idea. I’m the kind of front end developer that likes to do things my way and force whatever tool I’m using into it. There is something to be said for that, but only to a point. Burning hours on a philosophical difference on naming typically isn’t worth it. In WordPress, you can force it to do just about anything, but the default are typically pretty good, and just going along with the system will make things easier. That’s what Karol is suggesting here with CSS and WordPress.

Building a site on WordPress is a unique experience. On one hand, you get a ton of functionality right off the gate. On the other, WordPress often expects you to use certain structures when displaying content to take advantage of that functionality.

Some of those structures WordPress are used automatically, no matter how you’ve built your design (e.g. all menus are <ul> whether you like it or not), while others are more within your control thanks to custom PHP, WordPress actions hooks and other tricks you can use. Although it’s a fact that the platform doesn’t impose a lot of restrictions, you still need to be mindful of the most basic traits if you want your content to be displayed properly.

In this guide, we’re going to have a quick look at the absolute minimal set of CSS you need to take care of when building a WordPress site.

Here’s what I mean by that. We all have our favorite HTML and CSS structures and ways of coding things in general. I’m not here to tell you what’s right and what isn’t. What I want to do instead is list the classes that WordPress will be spitting out regardless of what you might do on your own. In short, feel free to use whatever structure you wish when it comes to the scaffolding of your site. However, also take care of the default WordPress classes, to make sure that your CSS is as WordPress-optimized as possible.

An advanced WordPress developer may note that WordPress is extremely customizable and it’s possible to alter these default classes, but we aren’t going to go into that here.

It’s a lot easier to explain what I mean if we take a look at the first example – talking about the very native element in WordPress:

It will be easier to see what I mean when we look at an example, so let’s look at the ever-popular widget.

Styling Widgets

It would be hard to imagine a WordPress site that doesn’t use any widgets at all. Ever since their introduction, widgets have been popular on a huge variety of sites. Their purpose is generally to display secondary content alongside posts and pages, often in sidebars.

WordPress comes with a handful of widgets right out the box, and many plugins add their own. At the time of writing, the default set includes: Archives, Calendar, Categories, Custom Menu, Meta, Pages, Recent Comments, Recent Posts, RSS, Search, Tag Cloud, Text.

Each of these widgets comes with its own range of CSS classes that are included whenever a specific widget is used.

The classes that WordPress assigns to all widget elements (regardless of the widget type) are:

.widget {} /* top level class for every widget */
.widget-title {} /* usually on the inner header element */

Then, based on the widget type, any of these classes can be used:

/* Archives */
.widget_archive {} /* used next to .widget (on the same tag) */

/* Calendar */
.widget_calendar {} /* used next to .widget (on the same tag) */
#calendar_wrap {} /* on &lt;div&gt; wrapping the calendar */
#wp-calendar {} /* on &lt;table&gt; building the calendar */

/* Categories */
.widget_categories {} /* used next to .widget (on the same tag) */
.cat-item {} /* on each item in the &lt;ul&gt; list */

/* Custom Menu */
.widget_nav_menu {} /* used next to .widget (on the same tag) */
.menu-item {}

/* Meta */
.widget_meta {} /* used next to .widget (on the same tag) */

/* Pages */
.widget_pages {} /* used next to .widget (on the same tag) */
.page_item {}

/* Recent Comments */
.widget_recent_comments {} /* used next to .widget (on the same tag) */
.recentcomments {} /* on each item in the &lt;ul&gt; list */

/* Recent Posts */
.widget_recent_entries {} /* used next to .widget (on the same tag) */

/* RSS */
.widget_rss {} /* used next to .widget (on the same tag) */
.rsswidget {} /* on each RSS link */

/* Search */
.widget_search {} /* used next to .widget (on the same tag) */
.search-form {} /* used with the actual &lt;form&gt; element */

/* Tag Cloud */
.widget_tag_cloud {} /* used next to .widget (on the same tag) */
.tagcloud {} /* on the <div> wrapping the cloud */

/* Text */
.widget_text {} /* used next to .widget (on the same tag) */
.textwidget {} /* on the actual text content of the widget */

The best starting point here would be to first style the .widget class itself and make sure that the main widget block is always displayed properly. The move on to styling the individual classes as needed. That’s how we always do it.

Working with these defaults can be a quicker way of building a design, in comparison to coming up with your own way of wrapping certain elements. As a byproduct, you will also make sure that the site admin won’t see anything weird if they try using any of these native widgets.

To check what the actual HTML document structure looks like, I encourage you to set up a test WordPress site using the default theme, place all widgets in the sidebar and examine the HTML source.

Styling the <body>

WordPress is really generous when it comes to adding various classes to the <body> tag. They all have different purposes and are displayed on different sub-pages of the site. This allows you to easily introduce custom styling for different pages and different types of pages. For instance: category archives, posts, and author pages, just to name a few.

Let’s take it from the top:

.home {} /* if it's the homepage */
.page {} /* if it's any page */
.postid-XX {} /* if it's a post - XX is the post's ID */
.rtl {} /* when dealing with right-to-left content */
.blog {} /* if it's the custom blog listing */
.archive {} /* if it's any sort of archive page */
.category {} /* if it's a categories listing page */
.tag {} /* if it's a tags listing page */
.search .search-results {} /* if it's a search results page */
.author {} /* if it's an authors page */
.author-XX {} /* if it's an individual author's archive - XX is the author's nickname */
.date {} /* if it's a date-based archives page */
.error404 {} /* if it's a 404 page */

The above isn’t the complete list of classes, but it should be enough to get you going and cover all the basics.

Styling posts and pages

Even though posts and pages have different purposes depending on the site, WordPress itself treats them very similarly. Both the posts and the pages are kept in the same table in the database, and they also share the same general structure when it comes to displaying them on the site.

So depending on whether you’re dealing with a post or a page, WordPress will assign the following classes to the main content tag (which in HTML5 is usually <article>).

.post-XX {} /* the ID of the element being displayed; used for both the posts and the pages */
.post {} /* if it's a post */
.page {} /* if it's a page */
.attachment {} /* if it's an attachment; on most sites this is not used */
.sticky {} /* if it's a sticky post */
.format-YY {} /* assigned to custom content types - YY is the name of the content type, e.g. "audio" */

The important part here is classes like .post-XX and .format-YY. They let you introduce custom styling for any post or page in the database, and also differentiate between various types of content used by the site admin. CSS can do a lot. Sometimes it’s tempting to make entirely new templates when you need pages that will look differently, but that can get out of hand, so just remember to lean on CSS and these custom classes when you can.

Styling menus

The way WordPress handles all menus is very straightforward. Every menu is displayed inside a standard unordered list (<ul>). The only thing you can do without doing some advanced filtering stuff is to style those lists and their elements individually.

When it comes to the elements wrapping the list itself, they are entirely up to you and the way you register the menu areas. Therefore, there’s not really any default classes that WordPress uses here.

In a nutshell, it’s up to you what outer structure you use. Then, WordPress will step in and display the menu as a list inside that structure.

Styling content

WordPress provides a WYSIWYG (TinyMCE) editor for users to create their content with. So in order to make sure that everything is styled nicely, you just need to take care of every class that TinyMCE outputs.

The advisable way to go about this is to start by creating a test post and put every possible type of content in it. Then take a look at the HTML source of the post and include those classes in your CSS.

Here’s a quick cheat sheet, here’s where you can get started:

/* the main classes used for alignment */
.alignnone {}
.alignleft {}
.alignright {}
.aligncenter {}
img.alignnone {}
img.alignleft {}
img.alignright {}
img.aligncenter {}

.wp-caption {} /* img caption */
.gallery {}
.gallery-caption {}

/* styles for img sizes */
img.size-full {}
img.size-large {}
img.size-medium {}
img.size-thumbnail {}

/* not classes, but surely something you should take care of */
blockquote {}
code {}
pre {}
hr {}
del {}

By far, the most important thing on the list above are the image styles. Once the site is live, the admin will be using them on a regular basis, so you need to make sure that your CSS is able to handle even the strangest combinations of images.

For instance, what happens when someone puts two images next to each other, one .alignleft and the other .aligncenter? What if there’s a third image nearby? And so on.

Always start by resetting

Starting your CSS work by resetting all the default tags is a good practice regardless of the project you’re working on, and WordPress is no different here.

For example, the current default theme for WordPress – Twenty Fourteen – uses a modified version of the reset style sheet by Eric Meyer.

When working on your own style sheet, you can begin with Meyer’s reset as well. But if you want a shortcut then just download whatever the default theme for WordPress is at the moment, get its stylesheet, and copy-and-paste the reset part to yours. The current default theme’s reset is more than 400 lines long, so building something similar yourself would surely take a while.


There you have it! A list of CSS classes to get you on your way to building a stylesheet for a WordPress theme. What’s your opinion about how WordPress utilizes CSS? Do you think that perhaps there’s too much bloat and that things could be a bit more minimalist? Or aren’t there enough?