In late December, after posting an earlier version of this post, I realized I was going about this aspect of Project Grace all wrong, so I pulled that original version, a post about “Basic CSS page layout.” There was nothing wrong with the post, but I realized I was drifting toward just repeating myself, essentially a “remastered” series of articles I wrote, quite demonstrably with less knowledge about Pika than I have now, when building Project Claire.

But there were some deeper problems and challenges for me. As I moved ahead with the challenge of doing another CSS makeover of Pika, I was forced to realize (again) that there are really, really severe limits to what one can do with the CSS “presentational” characteristics of Pika because it still labors under a near-decade of seriously dated legacy markup. (In fairness, when we looked at competing CMS options a few years back, all the other developers suffered from this same shortcoming.) While Pika Software did make a serious effort in version 3.06 to clean out embedded and inline styles, with something like a 40-50% uptick in external CSS coding (a good thing), a huge amount of inline styles remain (a bad thing). Pika still relies predominantly on “tables” to control layout and positioning of page elements, which is a good thing for backward browser compatibility and therefore brings a level of presentational predictability in production software. I totally get that. But otherwise it totally sucks.

This is a two-fisted combo that seriously prevents doing much of anything creative with Pika presentational characteristics. Why? Well, inline styles always trump the external style sheet. That’s how CSS works, so your stuck with whatever styles Pika Software embeds inline. And reliance on tables severely constricts the positioning of page elements. Basically, you’re stuck with the Pika default page layouts unless you are prepared to go in and rebuild your templates to conform to more current web standards, something we did with Project Claire, as best as we could at the time.

The other factor that triggered the change in how to approach Project Grace was a meeting Mark Sawyer and I had with some folks from East Bay Community Law Center, who soon will adopt their first CMS ever, namely, Pika 3.06. And I think it is fair to say they’re feeling overwhelmed. (Whew, way understandable to anyone who’s ever been through the process.)

It was during that meeting I got the idea to take the current version of Pika and do simply what I talk about above, i.e., quite literally rebuilding all the Pika templates and subtemplates, regrettably but of necessity still relying on the deeply embedded tables-based layout structures, while removing all the inline styles that remain in the markup. And then modifying minimally the PHP files essential to dynamically generating other specific Pika page markup, principally markup generated dynamically by pika_cms.php and pikaMisc.php. And then creating a totally custom CSS style sheet, all of which works with a default Pika installation. No changes in how Pika works out of the box. No changes in Pika default workflow. Just better, more flexible markup in the templates, some essential tweaks to a few PHP files to get other markup to display correctly, and a fresh coat of paint for the whole shebang via a custom CSS style sheet. And something one could simply upload to the /pika-custom and /css subfolders in one or two fell swoops.

The goal would be to conjure up a simple, clean, low-contrast, uncluttered design refresh. That’s the theory, anyway. So, with Aaron’s recent announcement that Pika 3.07 will be released in another week or so (and Pika 4.0 put off to later this year, at the earliest), the Project Grace approach has changed: Once version 3.07 hits the street, LSNC will set up three Pika 3.07 test beds: first, a virgin reference install; second, an “East Bay” install to build a new set of default templates with a custom CSS style sheet, as described above; and third, a long-form install where we can work on a more radical rebuild to incorporate all latest, way cool Pika Software modifications into all the existing LSNC customizations, something that may take us the better part of six months or so to complete.

What I will be doing here at Webdogs 2.0 is reporting on progress of the second and third installs. Rather than do long-form tutorials, as I have been doing, what I will do is post the rebuilt templates and the custom “East Bay” CSS to PikaDocs in the California Customizations section. These two installs will most definitely be works in progress. The files posted to Pikadocs will inevitably be added, edited, supplemented, and/or deleted depending on what’s happening as the work goes forward. Most likely, I will post select additions to the Project Grace series here to detail distinctive elements of the templates or CSS designs.

Want an early taste? Take a look at the initial set of 21 screenshots of the “East Bay” design now posted to PikaDocs.

But I am mindful of the broader implications of using a global reset, i.e., there are any number of other web browsers or viewers that may be used with your public web content, which is why I referred to Eric Meyer’s au courant article, Reset Reloaded. My current practice for building out CSS on newer public web projects here is to use a modestly trimmed-down version of Eric Meyer’s code, consistent with those structural elements we actually would use in an XHTML 1.0 Strict build, combined with certain “Webdogs” global style defaults.

So, for the record, here are the more nuanced CSS global reset and initial global styles we currently use on all new website builds, with notations:

/*
global resets based on Eric Meyer's "Reset Reload" at
http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/
 */

html, body, div, span,
h1, h2, h3, h4, h5, h6, p, pre,
a, code, em, font, img, strong, sub, sup,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
    margin: 0;
    padding: 0;
    border: 0;
    outline: 0;
    font-weight: inherit;
    font-style: inherit;
    font-size: 100%;
    font-family: inherit;
    vertical-align: baseline;
    }
/* remember to define focus styles! */
:focus {
    outline: 0;
    }
body {
    line-height: 1;
    color: black;
    background: white;
    }
ol, ul {
    list-style: none;
    }
/* tables still need 'cellspacing="0"' in the markup */
table {
    border-collapse: collapse;
    border-spacing: 0;
    }
caption, th, td {
    text-align: left;
    font-weight: normal;
    }

/*
global resets per Webdogs defaults;
font-size set per Clagnut's "How to size text using ems" at
http://clagnut.com/blog/348
*/

body {
    color: #333333; /* reduced contrast black */
    font-family: verdana, arial, sans-serif;
    font-size: 62.50%; /* resets 1.0em = 10px */
    line-height: 1.50; /* reset leading for readability */
    }
a:link,
a:visited {
    background: transparent;
    color: #333333; /* reduced contrast black */
    font-weight: bold;
    text-decoration: none;
    }
a:hover,
a:active {
    color: #0000FF; /* blue */
    }

/* prevents inherited shrinkage in Firefox per Clagnut at:
http://clagnut.com/blog/348/ */
li li,
li p,
td p {
    font-size: 1.0em
    }

/* for Firefox where page content < viewport height,
per Zoe Gillenwater's "Create Pages that Fill the Browser with CSS" at
http://www.communitymx.com/content/article.cfm?cid=BAD95
 */
html,
body {
    margin-bottom: 1px;
    min-height: 100%;
    }

Since this is the type of CSS code one is likely to use over and over, consider putting it into a separate style sheet and then use an import rule to pull it into your overall styles for the site. Just a thought.

The first two articles in the Project Grace: Pika Reloaded series were an introduction to several common basic web design development tools, most notably the Firebug extension for Firefox. In practice Firebug has largely supplanted most of the other web design diagnostic tools I had long relied upon, such as the Web Developer Toolbar and the View Source Chart extension.

For example, in the past I often used the View Source Chart extension to generate a wonderfully useful visual display of the underlying HTML page structure. For a Pika-specific example of how View Source Chart works, take a look this visual chart of the Pika Home Page. This type of visual chart is especially helpful in building CSS code since it provides a handy-dandy visual list of all the page elements, their specific id and class attributes, and an easily understood structural hierarchy revealing where the page elements are relative to each other, i.e., which are structural parents, children or siblings. But the ease and convenience of Firebug has changed my web design work habits a lot. Now what I more often do is simply activate the inspection window in Firebug, click on the particular page element I am curious about and go from there, as needed, to diagnose what ails me about the web page design. Which is how I will proceed for the most part as I rebuild the Pika CSS from scratch for Project Grace.

In this article I will briefly explain three things:

• where the default CSS code in Pika 3.06 is located and how it is organized;
• how to edit the head tag in the default.html template to remove the default link tags that call the Pika default style sheets and substitute new ones, so you can start from scratch and rebuild the CSS from the ground up with your own custom style sheets that will work in both Firefox and Internet Explorer; and
• add the first bit of CSS to your style sheets by doing a a “global reset” so that your new CSS code will behave more predictably in both Firefox and Internet Explorer.

How the default Pika CSS code is organized

In a standard web page, one or more external style sheets in the form of CSS files are linked to the web page by using a link tag embedded in the head element of the page. Pika 3.06 accomplishes this by linking the default styles via the screen.css.php file located in the /pika/css subdirectory. View the source code for any Pika page and you’ll see it linked in the head tag at the top:

<link href="/pika/css/screen.css.php" rel="stylesheet" type="text/css" />

The screen.css.php file contains 500+ lines of CSS code. If motivated, you can view the default Pika CSS code. If you do take a quick look-see at the default Pika CSS, you’ll notice that is ordered this way:

• Basic structural markup elements (e.g., a ... body ... div, etc.) listed in alphabetical order, followed by …
• id selectors and their descendants (e.g., #auth_label ... #auth_label a ... #bottom_searchbox, etc.) listed in alphabetical order, followed by …
• class selectors and their descendants (e.g., .de select ... .de input, etc.) clustered into the following 10 categories:
  1. “size” of data entry fields
  2. “specialized” data entry fields
  3. “size” of sidebar fields
  4. “eligibility” fields
  5. “settings” fields
  6. “case list” fields
  7. “alternating table rows”
  8. “masked form” fields
  9. “calendar rows”
  10. “case notes” text format

As we step through the rebuilding of the CSS code, I am going to suggest a different approach for organizing the CSS code. But for now, let’s do some damage.

Creating a custom set of Pika style sheets

The first step I suggest for creating your own custom styles for Pika from scratch is to summarily drop-kick the screen.css.php file out of the mix entirely. To do so, edit the head tag at the top of the default.html template to substitute a new set of link tags that pull in your new styles from three core sources: a “custom” CSS file for your new default Pika styles; one or more IE conditional comments so you can create CSS code that targets only Internet Explorer (for this exercise, I will include one global IE conditional comment; you could add others as suit your needs); and a separate “print” styles sheet that controls how Pika pages print out from within your web browser.

For this stage of Project Grace, here’s what the new head tag looks like with all the new link tags added:

<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<title>Pika: %%[page_title]%%</title>
<link rel="icon" href="%%[base_url]%%/favicon.ico" />
<link rel="shortcut icon" href="%%[base_url]%%/favicon.ico" />
<link rel="stylesheet" type="text/css" href="%%[base_url]%%/css/hub.css" />
<!--[if IE]>
<link rel="stylesheet" type="text/css" href="%%[base_url]%%/css/ie.css" />
<![endif]-->
<link rel="stylesheet" type="text/css" media="print" href="%%[base_url]%%/css/print.css" />
</head>

Since these newly linked style sheets have not even been created yet, with these changes made to the default.html template what you will see is a Pika Home page (and other pages) stark naked, i.e., a completely unstyled page.

Create the three new (albeit empty) style sheet files — custom.css, ie.css and print.css and put them into your /pika/css/ subdirectory.

Now you’re ready to dive in with your first Pika custom CSS by performing a hold-on-to-your-butt CSS “global reset.” What’s that you, say? Read on!

Creating a “global reset” for the Pika CSS

Before re-applying any real “styles” to this newly naked Pika page, I want to do a CSS “global reset.” That phrase originates with Andrew Krespanis’ 2004 article Global White Space Reset, the basic theory of which has been famously regranulated by Eric Meyer, the godfather of all things CSS, in his more recent article Reset Reloaded (May 1, 2007). You can review those articles to go deep on the theory.

In an earlier version of this article I suggested doing a blunt-force “reset” by using the asterisk universal selector to reset all margins and padding for all HTML elements to zero. That works, and it is a very common web design approach, but upon further reflection I have decided to rewrite this subsection of the article to promote using a more nuanced global reset, based on Eric Meyer’s model and one that with minor changes I actually use in practice.

The global reset proposed here is essentially the same used here (with some variations) at Webdogs 2.0, as are the added set of initial global styles to control the default appearance of the body, anchor and list item tags. I also am adding a initial global style for image tags to get rid of the border that appears by default in some browsers (including Firefox).

Here’s the whole, initial chunk of CSS code being added to the custom.css. file, with annotations highlighted in yellow:

/*
global resets based on Eric Meyer's "Reset Reload" at
http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/
 */

html, body, div, span,
h1, h2, h3, h4, h5, h6, p, pre,
a, code, em, font, strong, sub, sup,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
    margin: 0;
    padding: 0;
    border: 0;
    outline: 0;
    font-weight: inherit;
    font-style: inherit;
    font-size: 100%;
    font-family: inherit;
    vertical-align: baseline;
    }
/* remember to define focus styles! */
:focus {
    outline: 0;
    }
body {
    line-height: 1;
    color: black;
    background: white;
    }
ol, ul {
    list-style: none;
    }
/* tables still need 'cellspacing="0"' in the markup */
table {
    border-collapse: collapse;
    border-spacing: 0;
    }
caption, th, td {
    text-align: left;
    font-weight: normal;
    }

/*
global resets per Webdogs defaults;
font-size set per Clagnut's "How to size text using ems" at
http://clagnut.com/blog/348
*/

body {
    color: #333333; /* reduced contrast black */
    font-family: verdana, arial, sans-serif;
    font-size: 62.50%; /* resets 1.0em = 10px */
    line-height: 1.50; /* reset leading for readability */
    }
a:link,
a:visited {
    background: transparent;
    color: #333333; /* reduced contrast black */
    font-weight: bold;
    text-decoration: none;
    }
a:hover,
a:active {
    color: #0000FF; /* blue */
    }

/* prevents inherited shrinkage in Firefox per Clagnut at:
http://clagnut.com/blog/348/ */
li li,
li p,
td p {
    font-size: 1.0em
    }

/* use PRN on DIVs for clearing floated elements,
per Position Is Everthing at
http://www.positioniseverything.net/easyclearing.html */
.clear-fix:after {
    content: ".";
    clear: both;
    display: block;
    height: 0;
    visibility: hidden;
    }

/* for Firefox where page content < viewport height,
per Zoe Gillenwater's "Create Pages that Fill the Browser with CSS" at
http://www.communitymx.com/content/article.cfm?cid=BAD95
 */
html,
body {
    margin-bottom: 1px;
    min-height: 100%;
    }

With this CSS code added, the Pika Home Page still looks pretty naked but now has a few visually distinct characteristics wrought by the new CSS, although the basic positioning or layout of the page elements remains the same. Let’s break it down.

Explaining the first chunk of the Project Grace CSS code

The global reset has already been explained, above. Here’s a brief explanation of how the other new CSS code affects the Project Grace styles at this stage, starting with the initial presentational characteristics for the body element:

body {
    background: #FFFFFF;
    color: #333333;
    font-family: verdana, arial, sans-serif;
    font-size: 62.50%;
    line-height: 1.50;
    }

The body element is reset this way so that the background is white (#FFFFFF), the color of text is set to a lower contrast black (#333333) to enhance readability, and the basic font-family style is declared (verdana, etc.). The font-size is set to 62.5% to make it easier down the road to set alternate font sizes for other page elements that inherit this value from the body element. (For those who want a preview of the explanation for resetting the font-size this way, take a look at Richard Rutter’s highly influential article How to size text using ems. And for even more on this topic, you may want to read Richard Rutter’s more recent article published at A List Apart in which he updates his take on other approaches to assure cross-browser consistency in how text size displays. Here, I’m going to go with what I know until I can digest his latest musings on this subject.)

The line-height value is set to 1.50 to make the text, again, more readable. (Typographers refer to this as leading or line spacing). If you’re wondering what’s up with the “unitless” value for line-height, I refer you to Eric Meyer for the explanation. Me, I just do what Eric Meyer tells me to do. You would be wise to do so also.

Here is how the anchor tags are styled at this early step in Project Grace:

a:link,
a:visited {
    background: transparent;
    color: #333333;
    font-weight: bold;
    text-decoration: none;
    }
a:hover,
a:active {
    color: #0000FF;
    }

The anchor or “link” tags are set exactly as they are here at Webdogs 2.0. The declared values for the CSS properties override any browser defaults for displaying linked text by establishing their default color as the same used in the body tag, but in bold so that they stand out against a transparent background (assuring that the background of any other page element shows through), without any text-decoration to get rid of the “underline” displayed by default for anchor tags in all browsers, and a “hover” state that changes the linked text to blue (#0000FF).

Why do it this way? In my judgement it is a mixture of both design and readability issues, the thought being that removing text-decoration makes actual reading of page text with links easier. We have been doing this for years at both LSNC.net and, of course, here at Webdogs 2.0 without any complaints or apparent confusion by users. None. Experience tells us it works and is actually more user friendly. (Needless to say, others would beg to differ.)

Because list item tags are the semantically correct way to build not only actual lists of things on web pages but also itemized horizontal and vertical elements, such as horizontal navigation and sidebar menus, the default for ordered and unordered list items is reset to not display any list-style, such as a bullet or disc:

ul, ol {
    list-style: none;
    }

To get rid of the blue border that appears by default around image tags in some browsers, you do so by globally nukin’ it with a none value:

img {
    border: none;
    }

Finally, one common problem associated with different browsers is how they deal (or do not deal) with inheritance of font-size from some parent elements to some embedded child elements. This is a problem of inherited shrinkage triggered by the cascade effect of CSS that occurs inconsistently among browsers. Anyone who has had to tweak font-size to address inconsistencies in the text size of a sublist of item children embedded within a parent list knows of which I speak. Aaaaargh! To deal with that problem not only with list items but also paragraphs that are the children of parent list items and table data cells, the following CSS code is used:

 /* prevents inherited shrinkage */

li li,
li p,
td p {
    font-size: 1.0em
    }

Alrighty, now! True, the Pika Home Page doesn’t look like much at this early stage of CSS tweakery. But a solid “reset” foundation is in place as we stage for more visible changes to come. Reason enough to return for Project Grace 04, wouldn’t you say?

The Whole Enchilada: Project Grace: Pika Reloaded

The first sacrificial lamb in support of Project Grace is, predictably, the Pika Home Page. Out of the box here is what that page looks like:

Understanding the underlying structure of the Home Page

Let’s do some basic deconstruction. Using the Web Developer Toolbar, select CSS > Disable Styles > All Styles. Now the Pika Home Page displays stripped of all its custom CSS presentational characteristics. What you see is how your browser by default displays the page’s HTML structural markup in the same order as the markup appears in the “flow” of the underlying web page:

Looking at this page “naked,” even without looking at the actual markup behind the page display, those familiar with basic web page design will notice that the underlying structure of the page relies on tables, rather than CSS, to control the basic layout of the page. The three apparent columns in the middle (“Frequent Tasks,” “Message Board” and “Learn to Use Pika”) are dead give-aways. Again using the Web Developer Toolbar, to confirm this observation select Outline > Outline Tables > Tables, revealing that the page uses a table at the top for the “header” area, below which is a second table for the “middle-content” area:

To see the table cells that control the three columns in that middle-content area, select Outline > Outline Tables > Table Cells:

Since this stage of Project Grace is an attempt at a benign CSS makeover of the default Pika 3.06 presentational design, I will refrain from my usual rant about the misuse of tables to control page layout this way. At the very least it is not optimal. It’s OK and it works and, admittedly, it assures backward compatibility with now generations-old web browsers. But with the advent of increasingly CSS-standards compliant browsers, including IE7 (much improved) and Firefox 2.0 (way better), such design approaches are increasingly harder to defend. But I digress.

The final structural piece is the page “footer” at the bottom. To see what that’s all about, let me show you three ways to Sunday using three different tools to figure out that bit of markup.

First, make sure you have refreshed the Pika Home Page to get rid of the any earlier selections you made using the Web Developer Toolbar and you can see the default Pika page design again. Good to go? Now select CSS > View Style Information. Then scroll down to the bottom of the page where the “footer” is located and hover — but don’t click — your mouse (which changes into a cross-hair) over that area so that it is highlighted with a thin red border:

If you look up at the Web Developer Toolbar, it has opened a new information box immediately below the toolbar itself, revealing the underlying structural hierarchy for the highlighted page element, including the name of any id or class attributes:

(I will explain below what else happens when you click on the page element using this feature.)

Second, try using the XRAY bookmarklet. Click on it and then click on the footer area at the bottom of the page. (You may need to experiment with where you click to get results for the entire footer element, rather than other elements embedded within it.) The XRAY box displays basic information about that page element: It’s a div with an id attribute named “footer” and the inheritance hierarchy is html > body > div, all essential and useful information for working with CSS:

Third, let’s give Firebug a shot at this. Activate Firebug and in the Inspection window pane select “HTML” and then “Inspect.” Hover your mouse over the footer area to assure you have selected the whole footer area (you will see the blue border change so you can see which area is active within the Firebug inspection window), and then click the area to select it:

In the left pane you will see the “footer” div highlighted, as well as the structural hierarchy of that page element revealed, i.e., html > body > div.

Locating the CSS code

Here are a few ways to figure out where the CSS code is for any Pika page:

Be sure to close out Firebug and refresh your browser window. You should be back to the default Pika Home Page design. Using the Web Developer Toolbar, select CSS > View CSS. This triggers a new page listing all embedded CSS styles followed by the file location and contents of all external CSS styles affecting the presentational characteristics of the page. (As far as I can tell, this feature in the Web Developer Toolbar does not reveal inline CSS styles.)

When you invoke this feature, you’ll see that all the basic CSS code is located in the Pika CSS subdirectory at /pika/css/screen.css.php. Conveniently, the CSS file location is linked so you can open up the CSS code into a separate web page for review. For locating the CSS code specific to a particular page element, select CSS > View Style Information and then click on a page element. For example, if you click on the footer element discussed above, you will see the CSS code illustrated to the left.

Another way to go is to use Firebug to locate the CSS file location and the CSS code that relates to any selected page element. I am not going to repeat so much how that works, detailed here in the prior article. Suffice it to say that if you invoke Firebug and from the inspection window select HTML and Inspect, and then click anywhere on the page, you will see in the right pane the corresponding CSS code and where the file is located containing the code, illustrated here to the right and highlighted in yellow. The CSS file location is clickable, so if you want to get the whole CSS enchilada, not just the code for a particular element, go ahead and click it and Firebug opens up the whole CSS file in the Firebug window. Nice.

The effort here has been to suggest several different ways to deconstruct Pika pages to give you the basic information you need to restyle its pages elements. On balance, I prefer using Firebug for both the HTML and CSS excavation processes described above. But that’s me. There is more than one route to the mountain top and you now know where several of those paths are to your innner HTML and CSS geek.

You’re oriented. You’ve got a handle on the basic structural markup of a Pika page. You know where the CSS code is located. You know how to zone in on the CSS code for any particular page element using various web developer tools to extract that information. Time now to do some Pika CSS style rebuilding, the whole point of this first stage of Project Grace. Onward to Project Grace 03: Rebuilding the CSS from scratch!

The Whole Enchilada: Project Grace: Pika Reloaded