WordPress Theme Elements

A client asked us to put together a list of every design element required in a WordPress theme but it’s the sort of thing we think we should share.

When producing a theme, we try not to limit the website owner’s options within the WordPress Dashboard. The owner may wish to enable an option down the track and be disappointed if they can’t.

The downside for the designer and developer is they may put in work for elements that are never used. The upside is happy clients and return business.

Like most things web, the site’s purpose will dictate that some things just aren’t feasible. Consider this as a series of guidelines that you can adapt for your purposes.

Categorized as Code Tagged

Minimum Page, A CSS Base

We decided to release Soupgiant‘s CSS base to the world at large. You can find it at minimumpage.com.

Minimum Page comes from a frustration with CSS resets and bases. Ripping down the styling only to rebuild many of the same styles is unnecessary, especially for defaults common to all browsers.

To encourage people to consider the code they insert in their site, the styles aren’t provided in a minimised form. Developers should edit the original base to make generic, site wide changes.

It’s exactly what we use to start all of our CSS at Soupgiant. We think it’s important to share.

Categorized as Code Tagged

!important is Important

The !important declaration has really bad reputation, and deservedly so. As is often the way, this reputation results from abuse rather an inherent problem with the property itself. An example of its abuse might be:

#nav {
  float: none !important;
  /* where did I float this? */
/* ...jumble of code... */
ul#nav {
    float: left;

There are, however, instances where the !important declaration is the best tool for the job.

Big Red Framework

We’ve updated the base WordPress theme we use at Soupgiant for WordPress 3.1+ and to make more use of the WordPress API.

Along with the standard features you would expect in a WordPress framework, it includes

Never use the framework proper to set up a theme, set up a child theme instead.

  • Copy the files from the starter directory into the base folder of your child theme
  • Create the sub-directory assets in your child theme
  • Copy the framework’s assets/child/ directory into the assets directory of your child theme

See the WordPress codex page on child themes for more information.

More documentation to come!

HTML5: I couldn’t (quite) do it

For most of my career as a web developer I’ve produced websites that work without JavaScript. For the JavaScript impaired the sites may be missing a minor visual feature or be a little clunky in places, but they work and the meaning remains clear. It doesn’t bother me that, sometimes, the cost of allowing for sites to load without JavaScript can mean missing out on the latest web fashion. I’m not a big fan of fashion.

Currently, web development is undergoing some major transitions: the HTML5 spec is being developed and CSS3 is being implemented. The browser wars have returned, although this time around, it’s a battle to win developers’ hearts by implementing the newest standards.

Now is the time for developers to re-evaluate their past practices; moving on from the old and embracing the new. I kept that ethos in mind when upgrading the Soupgiant WordPress base theme recently. Among other things we were porting it to HTML5.

Selectivizr with CSS on a sub-domain

Updating a WordPress starter theme recently (among other things I was porting it to HTML5), I needed to decide which shims and/or polyfills to use. I starterd with Remy Sharp’s HTML5 enabling script but another to consider was Selectivizr to improve IE‘s support of CSS3 selectors.

One of the disadvantages of using Selectivizr is it rules out using a CDN for one’s style sheets. To quote their site:

Style sheets MUST be hosted on the same domain as the page due to browser security restrictions. Likewise, style sheets loaded using the file: protocol will not work.

After umming and ahhing for a couple of days, the following solution involving conditional comments, occurred to me:

<!--[if gte IE 9]><!-->
<link rel="stylesheet" href="http://cdn.example.com/styles.css" type="text/css">

<!--[if lte IE 8]>
<link rel="stylesheet" href="/styles.css" type="text/css">

With a few lines of conditional comments, browsers supporting the relevant selectors natively can take advantage of the performance boost from a CDN while developers can take advantage of the advanced selector support provided by Selectivizr for IE<9 users.

I’ve set up a quick demonstration in which three paragraphs have different ARIA roles – featured, unfeatured and neverfeatured – different styles are applied to each paragraph using [role=something]. The demo renders fully in: IE 6-9beta, Firefox (Win & Mac), Chrome (Mac), Safari (Mac), and Opera (Mac).