WordPress Default CSS Styles

WordPress gives us full control over the presentation of our websites. We specify which classes and attributes to use in our template files, and then apply CSS using our theme’s custom stylesheet. Behind the scenes, WordPress generates its own classes and IDs, and applies them to specific HTML elements in theme files and database content. Having these default hooks available makes it super-easy to custom-style your theme’s blockquotes, post images, widget items, and much more.

In addition to generating default classes for your site’s “front-end” (public-facing) pages, WordPress also employs a default set of CSS attributes for the Admin, or “back-end” pages. If you’ve ever delved into the convoluted CSS stylings of the WordPress Admin, you will understand why we focus exclusively on front-end attributes in this article. The goal is to include all classes and IDs generated for database content, theme template files, and default widget items.

Fortunately, most (if not all) of your WP CSS work happens at the “theme” or “post” level. And when you do need to style the Admin, it’s usually easiest to just do it en bloc via plugin. You can also do it the old-fashioned way.

Different Types of Default WordPress Styles

In this DiW post, we assemble and dissect as many of the default front-end WordPress CSS attributes that we could find. It turns out there are many more automatically generated classes and IDs than you probably realize, including those for more commonly styled elements such as the following:

• Images included via WordPress’ WYSIWYG Post Editor
• Image captions and galleries included via the WYSIWYG Post Editor
• The body_class() and post_class() template tags
• WordPress’ automatic “smilies”
• WordPress’ default widgets

Some of these features are used quite frequently, while others not so much. It’s a good idea to cover your bases for these items, especially when producing publicly available themes. By including some basic styles for key CSS attributes, you ensure a more complete and rewarding experience for your theme’s users (and their users as well).

Fortunately, not all of WordPress’ default CSS attributes require explicit styling. Many default classes and IDs are generated and included as a matter of convenience. Conversely, there some core styles that are essential for public themes. So to organize things, we have two somewhat arbitrary types of default attributes, “essential” or “optional” — and here they are now:

Essential WordPress Styles

These are default WordPress attributes that should be styled with CSS:

• Default styles applied by WordPress’ WYSIWYG editor
• Default styles generated by WordPress’ default widgets
• Comment styles — threaded comments, specific comment styles, et al.
• Miscellaneous WordPress styles

Optional WordPress Styles

These are default WordPress attributes that should be styled only when needed:

• WordPress Page Listings
• CSS attributes generated by body_class()
• CSS attributes generated by post_class()
• Miscellaneous WordPress styles

For each of these sections, we’ll review the associated functionality and then present the default CSS styles generated and output by WordPress. It is ultimately up to you to decide the best approach for dealing with these default styles. If nothing else, it is wise to provide styles for WordPress’ WYSIWYG Editor items and perhaps widgets, if enabled. This is functionality that users typically employ while working with their site.

For all of these CSS attributes, we are merely presenting the selectors devoid of any preset styles. Only the styles for the WYSIWYG Editor are included, mostly because they are styled according to the WordPress Codex. Everything else is entirely up to you.

↑ WordPress CSS – WYSIWYG Editor Styles

When you are working with WordPress’ WYSIWYG Editor in the Edit Post screen, WordPress applies context-specific CSS attributes to certain elements when they are included in your post. For example, when inserting images, you can specify whether the images are floated left, right, or even centered. To do this, WordPress applies classes such as alignleft, alignright, or aligncenter. Without defining styles for WordPress’ default hooks, images and other elements may not display as intended.

Thus, at a bare minimum, if you are building a theme that will be used by the general public, it is wise to include the following basic styles for the items attributed via the WYSIWYG Editor:

/* == WordPress WYSIWYG Editor Styles == */

.entry-content img {
	margin: 0 0 1.5em 0;
	}
.alignleft, img.alignleft {
	margin-right: 1.5em;
	display: inline;
	float: left;
	}
.alignright, img.alignright {
	margin-left: 1.5em;
	display: inline;
	float: right;
	}
.aligncenter, img.aligncenter {
	margin-right: auto;
	margin-left: auto;
	display: block;
	clear: both;
	}
.alignnone, img.alignnone {
	/* not sure about this one */
	}
.wp-caption {
	margin-bottom: 1.5em;
	text-align: center;
	padding-top: 5px;
	}
.wp-caption img {
	border: 0 none;
	padding: 0;
	margin: 0;
	}
.wp-caption p.wp-caption-text {
	line-height: 1.5;
	font-size: 10px;
	margin: 0;
	}
.wp-smiley {
	margin: 0 !important;
	max-height: 1em;
	}
blockquote.left {
	margin-right: 20px;
	text-align: right;
	margin-left: 0;
	width: 33%;
	float: left;
	}
blockquote.right {
	margin-left: 20px;
	text-align: left;
	margin-right: 0;
	width: 33%;
	float: right;
	}
.gallery dl {}
.gallery dt {}
.gallery dd {}
.gallery dl a {}
.gallery dl img {}
.gallery-caption {}

.size-full {}
.size-large {}
.size-medium {}
.size-thumbnail {}

Lots of good stuff there, but no predefined styles for some of the Gallery items, such as .gallery dl and .size-thumbnail, as seen near the end of the list. Also, if you are using reset styles for margins and padding, you can strip out quite a few rules from this default set.

Quick Tip: an easy way to ensure that everything is looking great is to simply create a test post in which you include each of the WYSIWYG items. Then include this set of default styles and fine-tune as desired.

As with most everything else WordPress-related, for more information on these default WordPress styles, check out the Codex. The default selectors above basically define CSS styles for images, captions, galleries, blockquotes, and smilies &ndash: in other words, all of the items that you can include using WordPress’ built-in WYSIWYG Editor.

↑ WordPress CSS – Miscellaneous Styles

After styling the essentials, you may also want to keep an eye out for these miscellaneous WordPress classes:

/* == WordPress CSS - Miscellaneous Styles == */

/* category links */
 li.categories {}  
 li.cat-item {}
 li.cat-item-{id} {}
 li.current-cat {}
 li.current-cat-parent {}
 ul.children {}

/* blogroll links */
.linkcat {}
.blogroll {}

/* read-more links */
.more-link {}

Not all of them are going to be used in every theme, but they are used quite commonly, especially the .read-more class, which is frequently used for archive, category and tag pages. It may be wise to anticipate their presence to ensure that nothing is going to break your theme’s design. Also, for more information on the category-links template tag, visit the WP Codex: wp_list_categories.

↑ WP CSS – Page Listings

If you are using WordPress’ built-in page-listing functionality provided by the wp_list_pages() and wp_page_menu() template tags, there are a variety of items that should be styled. These may look like a lot of work, but once you get the pattern down, it goes pretty quickly. Hopefully the following list will prove a useful reference during your next page-list styling session:

/* == WP CSS - Page Listings == */

.pagenav {}               /* outermost list item */
.page_item {}             /* any page item */
.page-item-{id} {}        /* specific page id */
.current_page_item {}     /* current page */
.current_page_parent {}   /* parent of current page */
.current_page_ancestor {} /* any ancestor of current page */

.pagenav ul,
.pagenav .current_page_item ul,
.pagenav .current_page_ancestor ul,
.pagenav .current_page_ancestor .current_page_item ul,
.pagenav .current_page_ancestor .current_page_ancestor ul,
.pagenav .current_page_ancestor .current_page_ancestor .current_page_item ul,
.pagenav .current_page_ancestor .current_page_ancestor .current_page_ancestor ul {}

.pagenav  ul ul,
.pagenav .current_page_item ul ul,
.pagenav .current_page_ancestor ul ul,
.pagenav .current_page_ancestor .current_page_item ul ul,
.pagenav .current_page_ancestor .current_page_ancestor ul ul {}
.pagenav .current_page_ancestor .current_page_ancestor .current_page_item ul ul, 
.pagenav .current_page_ancestor .current_page_ancestor .current_page_ancestor ul ul {}

Again, the easiest way to understand this spaghetti is to create a list by including wp_list_pages() in a theme template file, and define a big red border (or whatever) for each declaration block. Check the results and you should quickly recognize the pattern. For more information on the template tags used to generate these rules, go to Codex:

• wp_list_pages()
• wp_page_menu()

You may also want to check out some delicious recipes for WordPress page navigation, which provide everything you need to create the perfect page navigation menus for your website. </hype>

↑ WordPress CSS – Default WordPress Widgets

There are literally thousands of widgets available to WordPress users, but there is a handful of very common widgets that are frequently used with widgetized themes. If you are planning on widgetizing your theme, you should include some styles for some of the more popular widgets. Many of the widgets included with the retiring Kubrick theme have become very common, if not expected:

As the theme designer, you will decide which (if any) widgets to include in your theme, so you will know exactly which styles to apply. Here are the generic rules for some of the more common WordPress widgets:

/* == WordPress CSS - Default WordPress Widgets == */

.widget {}

/* links widget */
.widget_links {}
.widget_links ul {}
.widget_links ul li {}
.widget_links ul li a {}

/* meta widget */
.widget_meta {}
.widget_meta ul {}
.widget_meta ul li {}
.widget_meta ul li a {}

/* pages widget */
.widget_pages {}
.widget_pages ul {}
.widget_pages ul li {}
.widget_pages ul li a {}

/* recent-posts widget */
.widget_recent_entries {}
.widget_recent_entries ul {}
.widget_recent_entries ul li {}
.widget_recent_entries ul li a {}

/* archives widget */
.widget_archive {}
.widget_archive ul {}
.widget_archive ul li {} 
.widget_archive ul li a {}
.widget_archive select {}
.widget_archive option {}

/* tag-cloud widget */
.widget_links {}
.widget_links li:after {}
.widget_links li:before {}
.widget_tag_cloud {}
.widget_tag_cloud a {}
.widget_tag_cloud a:after {}
.widget_tag_cloud a:before {}

/* calendar widget */
.widget_calendar {}
#calendar_wrap {}
#calendar_wrap th {}
#calendar_wrap td {}
#wp-calendar tr td {}
#wp-calendar caption {}
#wp-calendar a {}
#wp-calendar #today {}
#wp-calendar #prev {}
#wp-calendar #next {}
#wp-calendar #next a {}
#wp-calendar #prev a {}

/* category widget */
.widget_categories {}
.widget_categories ul {}
.widget_categories ul li {} 
.widget_categories ul ul.children {}
.widget_categories a {}
.widget_categories select{}
.widget_categories select#cat {}
.widget_categories select.postform {}
.widget_categories option {}
.widget_categories .level-0 {}
.widget_categories .level-1 {}
.widget_categories .level-2 {}
.widget_categories .level-3 {}

/* recent-comments widget */
.recentcomments {}
#recentcomments {}
#recentcomments li {}
#recentcomments li a {}
.widget_recent_comments {}

/* search widget */
#searchform {}
.widget_search {}
.screen-reader-text {}

/* text widget */
.textwidget {}
.widget_text {}
.textwidget p {}

That’s obviously a lot of work for any designer, but there are many similar elements that would probably look best with matching styles. For example, instead of multiple declarations for list elements such as .widget_archive ul li, .widget_pages ul li, and .widget_recent_entries ul li, we can simplify by combining them into a single declaration, for example:

.widget_pages ul li,
.widget_archive ul li,
.widget_recent_entries ul li {}

In other words, when it comes to styling widgets, there’s a lot of repetition that may be consolidated and streamlined in your stylesheet. As you apply styles for WordPress’ default widgets, keep an eye out for exploitable selector patterns and similar styles that may be combined to save time and effort.

↑ WordPress CSS – Comment Styles

Styling comments is the bane of WordPress theme designers, especially when threaded/nested comments are enabled. The deeper they go, the more time you’re going to spend with them, but thankfully WordPress makes things a little easier by providing plenty of precise CSS hooks. Of course, if threaded comments are disabled, there is no need to bother with most of these classes. But when they are used, many of the following selectors should define style:

/* == WP CSS - Comment Styles == */

.commentlist .reply {}
.commentlist .reply a {}

.commentlist .alt {}
.commentlist .odd {}
.commentlist .even {}
.commentlist .thread-alt {}
.commentlist .thread-odd {}
.commentlist .thread-even {}
.commentlist li ul.children .alt {}
.commentlist li ul.children .odd {}
.commentlist li ul.children .even {}

.commentlist .vcard {}
.commentlist .vcard cite.fn {}
.commentlist .vcard span.says {}
.commentlist .vcard img.photo {}
.commentlist .vcard img.avatar {}
.commentlist .vcard cite.fn a.url {}

.commentlist .comment-meta {} 
.commentlist .comment-meta a {}
.commentlist .commentmetadata {}
.commentlist .commentmetadata a {}

.commentlist .parent {}
.commentlist .comment {}
.commentlist .children {}
.commentlist .pingback {}
.commentlist .bypostauthor {}
.commentlist .comment-author {}
.commentlist .comment-author-admin {}

.commentlist {}
.commentlist li {}
.commentlist li p {}
.commentlist li ul {}
.commentlist li ul.children li {}
.commentlist li ul.children li.alt {}
.commentlist li ul.children li.byuser {}
.commentlist li ul.children li.comment {}
.commentlist li ul.children li.depth-{id} {}
.commentlist li ul.children li.bypostauthor {}
.commentlist li ul.children li.comment-author-admin {}

#cancel-comment-reply {}
#cancel-comment-reply a {}

These are all of the classes and IDs that I could find, and they all seem to be pretty self-explanatory, especially after using them a few times. Even so, consider the collection a work in progress. As new information is discovered, the list will continue to improve (hypothetically speaking). Many of these selectors target markup elements generated via WordPress’ built-in wp_list_comments() template tag. Even when using a custom callback function for your comments loop, many of these CSS classes will be available for your styling convenience.

↑ WordPress CSS – body_class()

As of version 2.5, WordPress provides the body_class() template tag, which is included in the <body> element of your theme’s markup. When included, this tag outputs a variety of context-dependent class names that facilitate styling different types of page views. We talk more about body_class() here and here, but for now, let’s look at the different classes WordPress generates for this powerful tag:

/* == WP CSS - body_class() == */

.rtl {}
.home {}
.blog {}
.archive {}
.date {}
.search {}
.paged {}
.attachment {}
.error404 {}
.single postid-(id) {}
.attachmentid-(id) {}
.attachment-(mime-type) {}
.author {}
.author-(user_nicename) {}
.category {}
.category-(slug) {}
.tag {}
.tag-(slug) {}
.page-parent {}
.page-child parent-pageid-(id) {}
.page-template page-template-(template file name) {}
.search-results {}
.search-no-results {}
.logged-in {}
.paged-(page number) {}
.single-paged-(page number) {}
.page-paged-(page number) {}
.category-paged-(page number) {}
.tag-paged-(page number) {}
.date-paged-(page number) {}
.author-paged-(page number) {}
.search-paged-(page number) {}

As you can see, these classes enable us to easily target elements on any specific type of page. For example, if you want to customize the presentation of your search results, you could define your styles using the .search-results class. This flexibility offers greater control over the granular construction of your WordPress theme. For more information on the body_class() tag, check out the WordPress Codex.

↑ WordPress CSS – post_class()

As with body_class(), the post_class() template tag outputs a variety of context-dependent class names for your posts. The post_class() tag makes it easy to target and style specific posts and post-types, as well as posts from specific categories or tags. Here are the different class names automatically generated by post_class():

/* == WP CSS - post_class() == */

.post-id {}
.post {}
.page {}
.attachment {}
.sticky {}
.hentry {}
.category-misc {}
.category-example {}
.tag-news {}
.tag-wordpress {}
.tag-markup {}

Again, these classes seem pretty self-explanatory, but if anyone happens to know the definition of the .hentry class, it would be nice to know — I couldn’t find anything, and sadly didn’t take time to test. Basically, these classes enable you to define styles for specific types of posts, attachments, stickies, categories and tags. You can also include your own classes to post_class(), and even include current category IDs. For more information on the post_class() tag, check out the WordPress Codex.

Call for updates

So what’s missing? Notice any errors? I did my best to research everything and organize everything as accurately as possible, but this turned out to be a bit more insane than I had planned, and so there is definitely room for improvement. If you see anything that is inaccurate or incomplete, please advise in the comments. It would be great to fine-tune a complete reference for all of WordPress’ default CSS styles and hooks all in one place.